Hi Tom and Shorewall, I have a two node setup, each running an identical shorewall config of course. Each node is a virtual machine host running libvirt and I''ve created the network manually. This network is a br0 device that bridges to the vnet0, vnet1 of each guest machine locally. I do all the masquerading in shorewall. Additionally, I''ve created a tap0 device on each machine with openvpn and then bridged each one to it''s respective br0, thus bridging the two br0 networks at layer 2. Currently, the br0 on node one is a gateway with ip address 192.168.123.253. I''m trying to get a machine on node2 to route it''s traffic through the tap0 <--> tap0 bridge, and out the node1 gateway. It works, except it gets blocked by shorewall. If I set the shorewall policy to: all all ACCEPT, then it works perfectly. Attached are the logs of me pinging 8.8.8.8 (google''s public dns server): Mar 25 11:13:44 iron2 kernel: Shorewall:FORWARD:REJECT:IN=br0 OUT=br0 PHYSIN=vnet0 PHYSOUT=tap0 SRC=192.168.123.6 DST=8.8.8.8 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=62215 SEQ=1 and now with the all all ACCEPT: Mar 25 11:19:23 iron2 kernel: Shorewall:FORWARD:ACCEPT:IN=br0 OUT=br0 PHYSIN=tap0 PHYSOUT=vnet0 SRC=192.168.123.5 DST=192.168.123.6 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=6408 SEQ=1 here is a host on node1 trying to ping the machine on node2, again blocked, and with the policy change: Mar 25 11:17:06 iron1 kernel: Shorewall:FORWARD:REJECT:IN=br0 OUT=br0 PHYSIN=vnet0 PHYSOUT=tap0 SRC=192.168.123.5 DST=192.168.123.6 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=5128 SEQ=1 and Mar 25 11:19:23 iron1 kernel: Shorewall:FORWARD:ACCEPT:IN=br0 OUT=br0 PHYSIN=vnet0 PHYSOUT=tap0 SRC=192.168.123.5 DST=192.168.123.6 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=6408 SEQ=1 /etc/shorewall/masq: eth4 br0 # masquerade the dmz out to the net /etc/shorewall/interfaces: net eth4 detect tcpflags,routefilter,nosmurfs,logmartians dmz br0 detect bridge,optional /etc/shorewall/zones: net ipv4 dmz ipv4 /etc/shorewall/policy: $FW dmz ACCEPT dmz net ACCEPT (Excerpts from some configs, some lines excluded...) Please could you point me in the right direction as to the correct rules/and or policies I need to add. I was guessing perhaps ''routeback'' on the br0 in interfaces, is this right? What else for the policy, zones and rules? Thank you once again! This wouldn''t all be possible without shorewall. James ------------------------------------------------------------------------------ Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar
On 3/25/11 8:42 AM, James wrote:> > Mar 25 11:13:44 iron2 kernel: Shorewall:FORWARD:REJECT:IN=br0 OUT=br0 > PHYSIN=vnet0 PHYSOUT=tap0 SRC=192.168.123.6 DST=8.8.8.8 LEN=84 TOS=0x00 > PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=62215 SEQ=1 >> > /etc/shorewall/masq: > eth4 br0 # masquerade the dmz out to the netYou really should replace ''br0'' with the corresponding subnet address.> > /etc/shorewall/interfaces: > net eth4 detect tcpflags,routefilter,nosmurfs,logmartians > dmz br0 detect bridge,optional> > Please could you point me in the right direction as to the correct > rules/and or policies I need to add. I was guessing perhaps ''routeback'' > on the br0 in interfaces, is this right?Yes -- please see Shorewall FAQs 17 and 35. Also, which Shorewall version are you running. In the later versions, the *bridge* option should automatically imply *routeback* and your /etc/shorewall/masq entry elicits a WARNING. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar
On Fri, 2011-03-25 at 08:57 -0700, Tom Eastep wrote:> On 3/25/11 8:42 AM, James wrote: > > > > > > > /etc/shorewall/masq: > > eth4 br0 # masquerade the dmz out to the net > > You really should replace ''br0'' with the corresponding subnet address.Done, I put: 192.168.123.0/24 Thanks for pointing this out, I re-read the masq docs.> > > > > /etc/shorewall/interfaces: > > net eth4 detect tcpflags,routefilter,nosmurfs,logmartians > > dmz br0 detect bridge,optional > > > > > Please could you point me in the right direction as to the correct > > rules/and or policies I need to add. I was guessing perhaps ''routeback'' > > on the br0 in interfaces, is this right? > > Yes -- please see Shorewall FAQs 17 and 35. Also, which Shorewall > version are you running. In the later versions, the *bridge* option > should automatically imply *routeback* and your /etc/shorewall/masq > entry elicits a WARNING.Unfortunately, not the latest... Using the centos5 version which is 4.0.15... My bad! Should I be mentioning the tap0 devices in shorewall at all? Thanks! James> > -Tom > ------------------------------------------------------------------------------ > Enable your software for Intel(R) Active Management Technology to meet the > growing manageability and security demands of your customers. Businesses > are taking advantage of Intel(R) vPro (TM) technology - will your software > be a part of the solution? Download the Intel(R) Manageability Checker > today! http://p.sf.net/sfu/intel-dev2devmar > _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users------------------------------------------------------------------------------ Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar
On 3/25/11 11:19 AM, James wrote:> On Fri, 2011-03-25 at 08:57 -0700, Tom Eastep wrote: >> On 3/25/11 8:42 AM, James wrote: >> >> >> >>> >>> /etc/shorewall/masq: >>> eth4 br0 # masquerade the dmz out to the net >> >> You really should replace ''br0'' with the corresponding subnet address. > Done, I put: 192.168.123.0/24 Thanks for pointing this out, I re-read > the masq docs. >> >>> >>> /etc/shorewall/interfaces: >>> net eth4 detect tcpflags,routefilter,nosmurfs,logmartians >>> dmz br0 detect bridge,optional >> >>> >>> Please could you point me in the right direction as to the correct >>> rules/and or policies I need to add. I was guessing perhaps ''routeback'' >>> on the br0 in interfaces, is this right? >> >> Yes -- please see Shorewall FAQs 17 and 35. Also, which Shorewall >> version are you running. In the later versions, the *bridge* option >> should automatically imply *routeback* and your /etc/shorewall/masq >> entry elicits a WARNING. > Unfortunately, not the latest... Using the centos5 version which is > 4.0.15... My bad! >Simon Matter maintains current versions for Fedora/Redhat/CentOS. See the Shorewall download page.> Should I be mentioning the tap0 devices in shorewall at all?No. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar