This is some ramblings on why using proxy ARP (on a host in a DMZ)
is a good or bad thing.
The good is that a computer X retains a public IP address which makes
it easy to connect it directly to the net if the firewall has to
be taken down for extended periods. Thus, if computer X is a mail
server for example, it can still function in a reduced capacity
until the firewall is restored.
The bad happens when computer X is dead for whatever reason.
1. The firewall responds to pings instead of X so if you are
in the habit of pinging a computer to see if it''s alive,
watch out.
2. The firewall also seems to respond to other connections.
For example, if computer X is alive, I can ssh to it normally.
However, if computer X is dead, the ssh login prompt comes
from the firewall.
I am puzzled as to why this is happening - it does not seem right.
--
caesar 17 <<-salad
cjbx jc vdwwjar jc xi jc jd
salad
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Taso Hatzi wrote:> > This is some ramblings on why using proxy ARP (on a host in a DMZ) > is a good or bad thing. > > The good is that a computer X retains a public IP address which makes > it easy to connect it directly to the net if the firewall has to > be taken down for extended periods. Thus, if computer X is a mail > server for example, it can still function in a reduced capacity > until the firewall is restored. > > The bad happens when computer X is dead for whatever reason. > > 1. The firewall responds to pings instead of X so if you are > in the habit of pinging a computer to see if it''s alive, > watch out. > > 2. The firewall also seems to respond to other connections. > For example, if computer X is alive, I can ssh to it normally. > However, if computer X is dead, the ssh login prompt comes > from the firewall. > > I am puzzled as to why this is happening - it does not seem right. >It isn''t right -- you are doing something wrong. - -Tom - -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBhlWdO/MAbZfjDLIRAr8zAJ0THb1V1wsEYkMN4qHxQOqEsGGBnACff1lt N5toArCbOxyCyRl2Klr2Sxs=HhBI -----END PGP SIGNATURE-----
Tom Eastep wrote:>> >>I am puzzled as to why this is happening - it does not seem right. >> > > > It isn''t right -- you are doing something wrong. >I guess that''s a reassuring statement in one way. Have you heard of any issues with proxy ARP operation on Mandrake 9.2 Linux 2.4.22-37mdk? Alternatively, are there any specific features or patches that are required for the proper working of proxy ARP? The RPM install of shorewall has never been clean but I have just put that down to Mandrake''s unique naming of iproute2.
On Tue, 2004-11-02 at 03:34, Taso Hatzi wrote:> Tom Eastep wrote: > >> > >>I am puzzled as to why this is happening - it does not seem right. > >> > > > > > > It isn''t right -- you are doing something wrong. > > > > I guess that''s a reassuring statement in one way. Have you heard of any > issues with proxy ARP operation on Mandrake 9.2 Linux 2.4.22-37mdk? > Alternatively, are there any specific features or patches that are > required for the proper working of proxy ARP? The RPM install of shorewall > has never been clean but I have just put that down to Mandrake''s unique > naming of iproute2.If you will send the usual problem report information (http://shorewall.net/support.htm), we can try to see what you are doing wrong. I''m not aware of any Mandrake-specific problems although I don''t run Mandrake myself. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
Tom Eastep wrote:> > If you will send the usual problem report information > (http://shorewall.net/support.htm), we can try to see what you are doing > wrong. I''m not aware of any Mandrake-specific problems although I don''t > run Mandrake myself. >1. The original weird problem I reported about the fw responding to pings and other connections when the proxied host was dead has disappeared. I have no idea why, but it may be related to (2). 2. Depending on what you change in the Shorewall config files, a shorewall restart is not equivalent to restarting the firewall computer. It''s probably best to init 1 and maybe even remove relevant modules. 3. Squid runs as a transparent web proxy in LOC. There is a web server (WS) in the DMZ. It was not possible to access the WS from LOC. This was fixed by bypassing the Squid for hosts in LOC accessing the WS. The Shorewall doc covers how to set up a transparent web proxy in LOC. One part of the set up entails putting something like "iptables -t mangle -A PREROUTING -i eth1 -s ! 172.16.0.3 -p tcp --dport 80 -j MARK --set-mark 202" in /etc/shorewall/start. Where eth1 leads to LOC and 172.16.0.3 is the IP address of the computer running Squid. The bypass is done by changing the above to "iptables -t mangle -A PREROUTING -i eth1 -s ! 172.16.0.3 -d ! W.X.Y.Z -p tcp --dport 80 -j MARK --set-mark 202 Where W.X.Y.Z is the IP address of the proxied WS in the DMZ. Without the bypass, the FW sends ARP requests for W.X.Y.Z on the NET interface. To illustrate: eth0 leads to NET, eth1 leads to LOC, and eth3 leads to DMZ where W.X.Y.Z lives. When a computer in LOC looked up the WS there was an ARP request on eth0 for W.X.Y.Z. It went unanswered. This doesn''t make sense because if I ssh''ed to W.X.Y.Z from LOC the ARP request went out on eth1. Any explanation of this behaviour is welcome. In case it may be significant, I should mention that the FW has two interfaces that lead to NET. There are rules which ensure that packets are replied to back through the interface whence they came & rules that mark web and ftp packets so that they can be chanelled out through a specific interface. -- caesar 17 <<-salad cjbx jc vdwwjar jc xi jc jd salad
On Wed, 2004-11-03 at 07:22, Taso Hatzi wrote:> > 1. The original weird problem I reported about the fw responding to > pings and other connections when the proxied host was dead has > disappeared. I have no idea why, but it may be related to (2). > > 2. Depending on what you change in the Shorewall config files, > a shorewall restart is not equivalent to restarting the firewall > computer. It''s probably best to init 1 and maybe even remove > relevant modules."shorewall restart" doesn''t purge the Netfilter connection tracking table; there is no way to do that short of removing the ip_conntrack module and that generally isn''t possible because dependent modules can''t be removed.> > 3. Squid runs as a transparent web proxy in LOC. There is a web server > (WS) in the DMZ. It was not possible to access the WS from LOC. This > was fixed by bypassing the Squid for hosts in LOC accessing the WS. > The Shorewall doc covers how to set up a transparent web proxy in > LOC. One part of the set up entails putting something like > > "iptables -t mangle -A PREROUTING -i eth1 -s ! 172.16.0.3 -p tcp --dport 80 -j MARK --set-mark 202" > > in /etc/shorewall/start. Where eth1 leads to LOC and 172.16.0.3 is the > IP address of the computer running Squid. The bypass is done by changing > the above to > > "iptables -t mangle -A PREROUTING -i eth1 -s ! 172.16.0.3 -d ! W.X.Y.Z -p tcp --dport 80 -j MARK --set-mark 202 > > Where W.X.Y.Z is the IP address of the proxied WS in the DMZ.Shouldn''t have been necessary but on the other hand, it is silly to proxy a local server.> > > Without the bypass, the FW sends ARP requests for W.X.Y.Z on the NET > interface. To illustrate: eth0 leads to NET, eth1 leads to LOC, and > eth3 leads to DMZ where W.X.Y.Z lives. When a computer in LOC looked > up the WS there was an ARP request on eth0 for W.X.Y.Z. It went unanswered. > This doesn''t make sense because if I ssh''ed to W.X.Y.Z from LOC > the ARP request went out on eth1. Any explanation of this behaviour > is welcome.I haven''t a clue.> > In case it may be significant, I should mention that the FW has two > interfaces that lead to NET. There are rules which ensure that packets > are replied to back through the interface whence they came & rules that > mark web and ftp packets so that they can be chanelled out through > a specific interface.That might be relevant but since I can''t reproduce the configuration here (only one internet connection), I have no idea why that was happening. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
Tom Eastep wrote:> > Shouldn''t have been necessary but on the other hand, it is silly to > proxy a local server. >Expediency and silliness go hand in hand. :)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Taso Hatzi wrote: | Tom Eastep wrote: | |> |> Shouldn''t have been necessary but on the other hand, it is silly to |> proxy a local server. |> | | Expediency and silliness go hand in hand. :) | True, but in this case expediency avoids silliness :-) - -Tom - -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBiZemO/MAbZfjDLIRAiS/AKCQrZdT0OY/tQY5mPFixp2wVTw4GwCeM8IT c0m9cwiT6hdthlwe8UchxWU=6f+a -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Taso Hatzi wrote: | Tom Eastep wrote: | |> |> Shouldn''t have been necessary but on the other hand, it is silly to |> proxy a local server. |> | | Expediency and silliness go hand in hand. :) | True, but in this case expediency avoids silliness :-) - -Tom - -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBiZemO/MAbZfjDLIRAiS/AKCQrZdT0OY/tQY5mPFixp2wVTw4GwCeM8IT c0m9cwiT6hdthlwe8UchxWU=6f+a -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Taso Hatzi wrote: | Tom Eastep wrote: | |> |> Shouldn''t have been necessary but on the other hand, it is silly to |> proxy a local server. |> | | Expediency and silliness go hand in hand. :) | True, but in this case expediency avoids silliness :-) - -Tom - -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBiZemO/MAbZfjDLIRAiS/AKCQrZdT0OY/tQY5mPFixp2wVTw4GwCeM8IT c0m9cwiT6hdthlwe8UchxWU=6f+a -----END PGP SIGNATURE-----