Hello list I''m trying to get Proxy ARP to work on a virtual xen network using shorewall-perl 4.0.2. I have 1 dom0 with 4 physical NICs. On each dom0 NIC I''ve made a bridge (except for eth1, which is used for AoE storage). Shorewall is running in a domU where: DomU eth0 is created on xenbr0 DomU eth1 is created on xenbr2 I''ve installed a domU, a DMZ server, where: DomU eth0 is created on xenbr2 The DMZ server should be able to access the Internet through the Shorewall domU. I have followed http://www.shorewall.net/ProxyARP.htm, but I get this in the log: dcm-firewall kernel: Shorewall:FORWARD:DROP:IN=eth1 OUT=eth1 SRC=192.168.1.20 DST=89.150.129.4 LEN=77 TOS=0x00 PREC=0x00 TTL=63 ID=63169 DF PROTO=UDP SPT=32768 DPT=53 LEN=57 Is there something basic I''m missing here? (attached a shorewall dump also) Thanks Lars ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Lars E. D. Jensen wrote:> Hello list > > I''m trying to get Proxy ARP to work on a virtual xen network using > shorewall-perl 4.0.2. > > I have 1 dom0 with 4 physical NICs. > > On each dom0 NIC I''ve made a bridge (except for eth1, which is used for AoE > storage). > > Shorewall is running in a domU where: > DomU eth0 is created on xenbr0 > DomU eth1 is created on xenbr2 > > I''ve installed a domU, a DMZ server, where: > DomU eth0 is created on xenbr2 > > The DMZ server should be able to access the Internet through the Shorewall > domU. I have followed http://www.shorewall.net/ProxyARP.htm, but I get this > in the log: > > dcm-firewall kernel: Shorewall:FORWARD:DROP:IN=eth1 OUT=eth1 > SRC=192.168.1.20 DST=89.150.129.4 LEN=77 TOS=0x00 PREC=0x00 TTL=63 ID=63169 > DF PROTO=UDP SPT=32768 DPT=53 LEN=57 > > Is there something basic I''m missing here? (attached a shorewall dump also) >A check of Shorewall FAQ 17 (http://www.shorewall.net/FAQ.htm#faq17) would have told you that when the IN= interface is equal to the OUTinterface and traffic is being dropped/rejected in the FORWARD chain that you need the ''routeback'' option on the interface (eth1). Adding that option will get rid of the message but it begs the question why 192.168.1.20 is routing traffic to 89.150.129.4 through the Shorewall box in the first place given that 192.168.1.20 is on the same LAN as the firewall''s default gateway. -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 ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
On 27/08/07 1:07, "Tom Eastep" <teastep@shorewall.net> wrote:> Lars E. D. Jensen wrote: >> Hello list >> >> I''m trying to get Proxy ARP to work on a virtual xen network using >> shorewall-perl 4.0.2. >> >> I have 1 dom0 with 4 physical NICs. >> >> On each dom0 NIC I''ve made a bridge (except for eth1, which is used for AoE >> storage). >> >> Shorewall is running in a domU where: >> DomU eth0 is created on xenbr0 >> DomU eth1 is created on xenbr2 >> >> I''ve installed a domU, a DMZ server, where: >> DomU eth0 is created on xenbr2 >> >> The DMZ server should be able to access the Internet through the Shorewall >> domU. I have followed http://www.shorewall.net/ProxyARP.htm, but I get this >> in the log: >> >> dcm-firewall kernel: Shorewall:FORWARD:DROP:IN=eth1 OUT=eth1 >> SRC=192.168.1.20 DST=89.150.129.4 LEN=77 TOS=0x00 PREC=0x00 TTL=63 ID=63169 >> DF PROTO=UDP SPT=32768 DPT=53 LEN=57 >> >> Is there something basic I''m missing here? (attached a shorewall dump also) >> > > A check of Shorewall FAQ 17 (http://www.shorewall.net/FAQ.htm#faq17) > would have told you that when the IN= interface is equal to the OUT> interface and traffic is being dropped/rejected in the FORWARD chain > that you need the ''routeback'' option on the interface (eth1).Now that''s gone...> Adding that option will get rid of the message but it begs the question > why 192.168.1.20 is routing traffic to 89.150.129.4 through the > Shorewall box in the first place given that 192.168.1.20 is on the same > LAN as the firewall''s default gateway.I''ve followed this from ProxyARP.htm: The lower systems (130.252.100.18 and 130.252.100.19) should have their subnet mask and default gateway configured exactly the same way that the Firewall system''s eth0 is configured. In other words, they should be configured just like they would be if they were parallel to the firewall rather than behind it. The DMZ server 192.168.1.20 is setup with the same network config as the firewalls eth0/192.168.1.15 that is with gateway 192.168.1.1. Thanks. Lars ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Lars E. D. Jensen wrote:> On 27/08/07 1:07, "Tom Eastep" <teastep@shorewall.net> wrote: > >> Lars E. D. Jensen wrote: >>> Hello list >>> >>> I''m trying to get Proxy ARP to work on a virtual xen network using >>> shorewall-perl 4.0.2. >>> >>> I have 1 dom0 with 4 physical NICs. >>> >>> On each dom0 NIC I''ve made a bridge (except for eth1, which is used for AoE >>> storage). >>> >>> Shorewall is running in a domU where: >>> DomU eth0 is created on xenbr0 >>> DomU eth1 is created on xenbr2 >>> >>> I''ve installed a domU, a DMZ server, where: >>> DomU eth0 is created on xenbr2 >>> >>> The DMZ server should be able to access the Internet through the Shorewall >>> domU. I have followed http://www.shorewall.net/ProxyARP.htm, but I get this >>> in the log: >>> >>> dcm-firewall kernel: Shorewall:FORWARD:DROP:IN=eth1 OUT=eth1 >>> SRC=192.168.1.20 DST=89.150.129.4 LEN=77 TOS=0x00 PREC=0x00 TTL=63 ID=63169 >>> DF PROTO=UDP SPT=32768 DPT=53 LEN=57 >>> >>> Is there something basic I''m missing here? (attached a shorewall dump also) >>> >> A check of Shorewall FAQ 17 (http://www.shorewall.net/FAQ.htm#faq17) >> would have told you that when the IN= interface is equal to the OUT>> interface and traffic is being dropped/rejected in the FORWARD chain >> that you need the ''routeback'' option on the interface (eth1). > > Now that''s gone... > >> Adding that option will get rid of the message but it begs the question >> why 192.168.1.20 is routing traffic to 89.150.129.4 through the >> Shorewall box in the first place given that 192.168.1.20 is on the same >> LAN as the firewall''s default gateway. > > I''ve followed this from ProxyARP.htm: > The lower systems (130.252.100.18 and 130.252.100.19) should have their > subnet mask and default gateway configured exactly the same way that the > Firewall system''s eth0 is configured. In other words, they should be > configured just like they would be if they were parallel to the firewall > rather than behind it. > > The DMZ server 192.168.1.20 is setup with the same network config as the > firewalls eth0/192.168.1.15 that is with gateway 192.168.1.1. >192.168.1.20 is connected to eth1 which is also where the firewall''s default gateway is connected. That is NOT the configuration shown in ProxyARP.htm. -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 ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
On 27/08/07 1:48, "Tom Eastep" <teastep@shorewall.net> wrote:>> I''ve followed this from ProxyARP.htm: >> The lower systems (130.252.100.18 and 130.252.100.19) should have their >> subnet mask and default gateway configured exactly the same way that the >> Firewall system''s eth0 is configured. In other words, they should be >> configured just like they would be if they were parallel to the firewall >> rather than behind it. >> >> The DMZ server 192.168.1.20 is setup with the same network config as the >> firewalls eth0/192.168.1.15 that is with gateway 192.168.1.1. >> > > 192.168.1.20 is connected to eth1 which is also where the firewall''s > default gateway is connected. That is NOT the configuration shown in > ProxyARP.htm. > > -TomOk, then I''m missing something :) eth1 in the firewall is configured with 192.168.2.15 and gateway 192.168.2.1 (I''ve also tried to remove the gateway definition from eth1). How do you see that the default gateway is connected to eth1? Thanks. Lars ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Lars E. D. Jensen wrote:> > > On 27/08/07 1:48, "Tom Eastep" <teastep@shorewall.net> wrote: >>> I''ve followed this from ProxyARP.htm: >>> The lower systems (130.252.100.18 and 130.252.100.19) should have their >>> subnet mask and default gateway configured exactly the same way that the >>> Firewall system''s eth0 is configured. In other words, they should be >>> configured just like they would be if they were parallel to the firewall >>> rather than behind it. >>> >>> The DMZ server 192.168.1.20 is setup with the same network config as the >>> firewalls eth0/192.168.1.15 that is with gateway 192.168.1.1. >>> >> 192.168.1.20 is connected to eth1 which is also where the firewall''s >> default gateway is connected. That is NOT the configuration shown in >> ProxyARP.htm. >> >> -Tom > > Ok, then I''m missing something :) > > eth1 in the firewall is configured with 192.168.2.15 and gateway 192.168.2.1 > (I''ve also tried to remove the gateway definition from eth1). > > How do you see that the default gateway is connected to eth1? >From the main routing table: 192.168.1.20 dev eth1 scope link 192.168.2.0/24 dev eth1 proto kernel scope link src 192.168.2.15 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.15 169.254.0.0/16 dev eth1 scope link default via 192.168.2.1 dev eth1 <===================================== -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 ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
On 27/08/07 2:28, "Tom Eastep" <teastep@shorewall.net> wrote:> Lars E. D. Jensen wrote: >> >> >> On 27/08/07 1:48, "Tom Eastep" <teastep@shorewall.net> wrote: >>>> I''ve followed this from ProxyARP.htm: >>>> The lower systems (130.252.100.18 and 130.252.100.19) should have their >>>> subnet mask and default gateway configured exactly the same way that the >>>> Firewall system''s eth0 is configured. In other words, they should be >>>> configured just like they would be if they were parallel to the firewall >>>> rather than behind it. >>>> >>>> The DMZ server 192.168.1.20 is setup with the same network config as the >>>> firewalls eth0/192.168.1.15 that is with gateway 192.168.1.1. >>>> >>> 192.168.1.20 is connected to eth1 which is also where the firewall''s >>> default gateway is connected. That is NOT the configuration shown in >>> ProxyARP.htm. >>> >>> -Tom >> >> Ok, then I''m missing something :) >> >> eth1 in the firewall is configured with 192.168.2.15 and gateway 192.168.2.1 >> (I''ve also tried to remove the gateway definition from eth1). >> >> How do you see that the default gateway is connected to eth1? >> > > From the main routing table: > > 192.168.1.20 dev eth1 scope link > 192.168.2.0/24 dev eth1 proto kernel scope link src 192.168.2.15 > 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.15 > 169.254.0.0/16 dev eth1 scope link > default via 192.168.2.1 dev eth1 <=====================================Ok, I removed the gateway definition for eth1 on the firewall and now have: default via 192.168.1.1 dev eth0 Still having problems with Internet access from domU with 192.168.1.20 (the dmz server). I have a policy that should allow it to access the Internet. Trying this on the firewall when the dmz server tries to access the Internet gives: tcpdump -n -i eth1 host 192.168.1.20 12:13:38.062457 arp who-has 192.168.1.1 tell 192.168.1.20 12:13:41.062621 arp who-has 192.168.1.1 tell 192.168.1.20 12:13:42.062697 arp who-has 192.168.1.1 tell 192.168.1.20 12:13:43.062731 arp who-has 192.168.1.1 tell 192.168.1.20 12:13:46.062923 arp who-has 192.168.1.1 tell 192.168.1.20 203 packets captured 406 packets received by filter 0 packets dropped by kernel Is there something special I need to do i dom0, configure the bridges in the right way? Or is it because I''m using local IP addresses (192.168.X.X) ? Thanks. Lars ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Lars E. D. Jensen wrote:> On 27/08/07 2:28, "Tom Eastep" <teastep@shorewall.net> wrote: > >> Lars E. D. Jensen wrote: >>> >>> On 27/08/07 1:48, "Tom Eastep" <teastep@shorewall.net> wrote: >>>>> I''ve followed this from ProxyARP.htm: >>>>> The lower systems (130.252.100.18 and 130.252.100.19) should have their >>>>> subnet mask and default gateway configured exactly the same way that the >>>>> Firewall system''s eth0 is configured. In other words, they should be >>>>> configured just like they would be if they were parallel to the firewall >>>>> rather than behind it. >>>>> >>>>> The DMZ server 192.168.1.20 is setup with the same network config as the >>>>> firewalls eth0/192.168.1.15 that is with gateway 192.168.1.1. >>>>> >>>> 192.168.1.20 is connected to eth1 which is also where the firewall''s >>>> default gateway is connected. That is NOT the configuration shown in >>>> ProxyARP.htm. >>>> >>>> -Tom >>> Ok, then I''m missing something :) >>> >>> eth1 in the firewall is configured with 192.168.2.15 and gateway 192.168.2.1 >>> (I''ve also tried to remove the gateway definition from eth1). >>> >>> How do you see that the default gateway is connected to eth1? >>> >> From the main routing table: >> >> 192.168.1.20 dev eth1 scope link >> 192.168.2.0/24 dev eth1 proto kernel scope link src 192.168.2.15 >> 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.15 >> 169.254.0.0/16 dev eth1 scope link >> default via 192.168.2.1 dev eth1 <=====================================> > Ok, I removed the gateway definition for eth1 on the firewall and now have: > default via 192.168.1.1 dev eth0 > > Still having problems with Internet access from domU with 192.168.1.20 (the > dmz server). I have a policy that should allow it to access the Internet. > > Trying this on the firewall when the dmz server tries to access the Internet > gives: > > tcpdump -n -i eth1 host 192.168.1.20 > > 12:13:38.062457 arp who-has 192.168.1.1 tell 192.168.1.20 > 12:13:41.062621 arp who-has 192.168.1.1 tell 192.168.1.20 > 12:13:42.062697 arp who-has 192.168.1.1 tell 192.168.1.20 > 12:13:43.062731 arp who-has 192.168.1.1 tell 192.168.1.20 > 12:13:46.062923 arp who-has 192.168.1.1 tell 192.168.1.20 > 203 packets captured > 406 packets received by filter > 0 packets dropped by kernelDid you restart Shorewall after the IP reconfiguration? If /proc/sys/net/ipv4/conf/eth1/proxy_arp = 1, then your firewall should respond to this ''who-has'' request since it has a route to 192.168.1.1.> > Is there something special I need to do i dom0, configure the bridges in the > right way? >No.> Or is it because I''m using local IP addresses (192.168.X.X) ? >No. -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 ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
On 27/08/07 16:20, "Tom Eastep" <teastep@shorewall.net> wrote:> Did you restart Shorewall after the IP reconfiguration? If > /proc/sys/net/ipv4/conf/eth1/proxy_arp = 1, then your firewall should > respond to this ''who-has'' request since it has a route to 192.168.1.1.This did it! echo 1 > /proc/sys/net/ipv4/conf/eth1/proxy_arp This seems to be done automatically by shorewall configuration, but really, maybe some magic just made it work (doubt that). Thanks. Lars ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/