Hi everybody. I am trying to set up a Proxy ARPed dmz using Mandrake MNF, but it seems I am missing something. I have 3 networks: eth0 lan 192.168.0.254 255.255.255.0 eth1 wan 80.23.252.58 255.255.255.248 eth2 dmz 192.168.10.1 255.255.255.0 I set up a working lan masquerading with #interface subnet address eth1:0.0.0.0/0 192.168.0.0/24 and then I tried to use this configuration for Proxy Arp: #address interface external haveroute 80.23.252.59 eth2 eth1 No The server in the DMZ has the same default gateway of the firewall. But even if the rules from dmz to wan and vice versa are open, no connection is possible from the two zones (while I can connect from the ''lan'' network to the server in the dmz). Moreover, if I try do do a connection from the server to a random ftp server I see a packet passing trough the firewall ----- Jun 7 15:18:31 gw kernel: Shorewall:dmz2all:ACCEPT:IN=eth2 OUT=eth1 SRC=80.23.2 52.59 DST=193.166.3.2 LEN=60 TOS=0x10 PREC=0x00 TTL=63 ID=50581 DF PROTO=TCP SPT =1037 DPT=21 WINDOW=5840 RES=0x00 SYN URGP=0 ------ but there is no answer. I guess there is some routing problem from the eth1 interface to eth2 or that the firewall did not answer correctly to arp requests coming from the outside. In any case here is the firewall routing table. Test connections to/from the firewall and the server in the dmz were successful. Destination Gateway Genmask Flags Metric Ref Use Iface 80.23.252.59 0.0.0.0 255.255.255.255 UH 0 0 0 eth2 80.23.252.56 0.0.0.0 255.255.255.248 U 0 0 0 eth1 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 192.168.10.0 0.0.0.0 255.255.255.0 U 0 0 0 eth2 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 80.23.252.57 0.0.0.0 UG 0 0 0 eth1 I hope this can be a sufficiently shorewall generic answer even if I use MNF. Thank you in advance for any advice. -- Ciao Nico
Nico Alberti wrote:> > > I hope this can be a sufficiently shorewall generic answer even if I use > MNF. Thank you in advance for any advice.Have you verified that the problem is not a stale ARP cache in the upstream router? http://shorewall.net/ProxyARP.htm describes how to test for that problem and how to solve it (see "ARP cache") in that article. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
> Have you verified that the problem is not a stale ARP cache in the> upstream router? http://shorewall.net/ProxyARP.htm describes how to > test for that problem and how to solve it (see "ARP cache") in that > article. I tried but I got this error: # arping -U -I eth1 80.23.252.59 bind: Cannot assign requested address Probably because of the tight security on MNF. Probably another source of troubles comes from the fact that I keep on receiving martian packets from the network address gw kernel: martian source 80.23.252.59 from 80.23.252.56, on dev eth1 gw kernel: martian source 80.23.252.61 from 80.23.252.56, on dev eth1 as you probably understood I am not a routing expert but I guess that that can poison the arp table of the router and the firewal. -- Ciao Nico
Nico Alberti wrote:> > Have you verified that the problem is not a stale ARP cache in the > > upstream router? http://shorewall.net/ProxyARP.htm describes how to > > test for that problem and how to solve it (see "ARP cache") in that > > article. > > I tried but I got this error: > > # arping -U -I eth1 80.23.252.59 > bind: Cannot assign requested address > > Probably because of the tight security on MNF. > > Probably another source of troubles comes from the fact that I keep on > receiving martian packets from the network address > > gw kernel: martian source 80.23.252.59 from 80.23.252.56, on dev > eth1 > gw kernel: martian source 80.23.252.61 from 80.23.252.56, on dev > eth1 > > as you probably understood I am not a routing expert but I guess that > that can poison the arp table of the router and the firewal. >What is the output of: a) ip route ls b) arp -na -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
Tom Eastep wrote:> a) ip route ls80.23.252.59 dev eth2 scope link 80.23.252.56/29 dev eth1 scope link 80.23.252.56/29 dev ipsec0 proto kernel scope link src 80.23.252.58 192.168.0.0/24 dev eth0 scope link 192.168.10.0/24 dev eth2 scope link 10.0.0.0/8 via 80.23.252.57 dev ipsec0 127.0.0.0/8 dev lo scope link default via 80.23.252.57 dev eth1> b) arp -na? (192.168.0.220) at 00:50:BA:53:27:DD [ether] on eth0 ? (192.168.0.1) at 00:50:BA:54:DB:4D [ether] on eth0 ? (80.23.252.57) at 00:08:27:1B:98:3F [ether] on eth1 ? (80.23.252.59) at 00:40:05:64:60:46 [ether] on eth2 ? (192.168.0.171) at 00:0F:20:22:A1:A7 [ether] on eth0 ? (192.168.0.175) at 00:0C:6E:04:C2:A3 [ether] on eth0 ? (80.23.252.59) at * PERM PUP on eth1 -- Ciao Nico
Tom Eastep wrote:> > What is the output of: > > a) ip route ls > b) arp -na >Also, please include the output of "ip addr ls". Thanks, -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
Tom Eastep wrote:> Also, please include the output of "ip addr ls". >With pleasure. Meanwhile I switched off the ipsec interface just to make things simpler # ip addr ls 1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 brd 127.255.255.255 scope host lo 2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100 link/ether 00:01:03:bd:c2:3b brd ff:ff:ff:ff:ff:ff inet 192.168.0.254/24 brd 192.168.0.255 scope global eth0 3: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100 link/ether 00:50:da:d7:7f:ef brd ff:ff:ff:ff:ff:ff inet 80.23.252.58/29 brd 80.23.252.63 scope global eth1 4: eth2: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100 link/ether 00:a0:c9:d4:32:81 brd ff:ff:ff:ff:ff:ff inet 192.168.10.1/24 brd 192.168.10.255 scope global eth2 -- Ciao Nico
Nico Alberti wrote:> Tom Eastep wrote: > >> Also, please include the output of "ip addr ls". >> > With pleasure. Meanwhile I switched off the ipsec interface just to make > things simpler > > # ip addr ls > 1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 > inet 127.0.0.1/8 brd 127.255.255.255 scope host lo > 2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100 > link/ether 00:01:03:bd:c2:3b brd ff:ff:ff:ff:ff:ff > inet 192.168.0.254/24 brd 192.168.0.255 scope global eth0 > 3: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100 > link/ether 00:50:da:d7:7f:ef brd ff:ff:ff:ff:ff:ff > inet 80.23.252.58/29 brd 80.23.252.63 scope global eth1 > 4: eth2: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100 > link/ether 00:a0:c9:d4:32:81 brd ff:ff:ff:ff:ff:ff > inet 192.168.10.1/24 brd 192.168.10.255 scope global eth2 > >Nothing jumps out at me -- time to go to work now but I''ll look at this as time permits. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
Tom Eastep wrote:> Nothing jumps out at me -- time to go to work now but I''ll look at this > as time permits. >Thank you all the same, Tom. I will go home, instead :-) -- Ciao Nico
Nico Alberti wrote:> Tom Eastep wrote: > > >> Nothing jumps out at me -- time to go to work now but I''ll look at >> this as time permits. >> > Thank you all the same, Tom. I will go home, instead :-) >My only suggestion is: a) On the firewall, enter this command -- tcpdump -nei eth1 host 80.23.252.59. b) From the DMZ server, try to establish an FTP session to an internet server. What does the tcpdump show? -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net