Hi. My system contains a single real NIC, eth0, and one virtual NIC, tun0. They are bridged together with vde, in bridge br0. (This is for using QEMU.) I have configured shorewall (3.0.5) according to the instructions in the "Shorewall and Bridged Firewalls" documentation. The bridge is working properly, because if I set the default policy to "all all ACCEPT", all traffic flows. When I set the default policy: fw net ACCEPT I find all packets from the firewall to the net are in fact dropped. I cannot get packets routed from fw to net via specific rules either. The only way I can get packets to travel from fw to net, is to set the default policy to fw all ACCEPT or all all ACCEPT I''ve been using shorewall in a single interface application for quite a while, controlling traffic in both directions, and in that application, fw2net rules do work. As suggested in the documentation, I''m including the output of "shorewall dump". The default policy for this rule are: fw net ACCEPT brloc net ACCEPT net all DROP all all DROP Is there something special that I''m missing about using the bridge? Any suggestions about how to debug this? Thank You. - Philip DeVries
On Monday 20 March 2006 08:50, Phil DeVries wrote:> > Is there something special that I''m missing about using the bridge? Any > suggestions about how to debug this? >Mar 20 11:27:56 OUTPUT:ACCEPT:IN= OUT=br0 SRC=192.168.1.123 DST=81.174.30.13 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=1837 DF PROTO=TCP SPT=36149 DPT=80 WINDOW=9424 RES=0x00 ACK URGP=0 The above shows that your kernel is broken somehow -- do you see CONFIG_BRIDGE_NETFILTER=y in your kernel .config file? -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
Thank for your response. 1. I do have CONFIG_BRIDGE_NETFILTER=y in my kernel .config file (and in my running kernel.) 2. I probably provided a confusing dump file. I think the log records did not match the running shorewall. To try to figure this out, I''ve been switching between two default policies: fw net ACCEPT info and fw all ACCEPT info both of which are logging ACCEPT events. I ran "shorewall dump" just after a "shorewall restart" with the first policy, and I think the log data is from the previous shorewall configuration. The attached output was taken after running shorewall for a while with the "fw net ACCEPT info" policy. Also, I''ve attached the configuration file data for this run of shorewall. In shorewall.conf I have set "Bridging="yes"" too. Once I figure this out, I finally want is a default DROP policy, with specific "fw net ACCEPT" rules for permissible outgoing traffic. Regards, Phil On Mon, 20 Mar 2006 10:11:22 -0800 Tom Eastep <teastep@shorewall.net> wrote:> On Monday 20 March 2006 08:50, Phil DeVries wrote: > > > > > Is there something special that I''m missing about using the bridge? Any > > suggestions about how to debug this? > > > > Mar 20 11:27:56 OUTPUT:ACCEPT:IN= OUT=br0 SRC=192.168.1.123 DST=81.174.30.13 > LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=1837 DF PROTO=TCP SPT=36149 DPT=80 > WINDOW=9424 RES=0x00 ACK URGP=0 > > The above shows that your kernel is broken somehow -- do you see > CONFIG_BRIDGE_NETFILTER=y in your kernel .config file? > > -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
On Monday 20 March 2006 11:30, Phil DeVries wrote:> Thank for your response. > > 1. I do have CONFIG_BRIDGE_NETFILTER=y in my kernel .config file (and in my > running kernel.) >That doesn''t change the fact that it is broken. The packets that are being logged don''t include physdev-in and physdev-out and hence don''t match either the ''net'' or the ''loc'' zones. This is *not* a Shorewall configuration issue. -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
On Monday 20 March 2006 11:30, Phil DeVries wrote:> Thank for your response. > > 1. I do have CONFIG_BRIDGE_NETFILTER=y in my kernel .config file (and in my > running kernel.) >I should add that bridge/netfilter was totally broken for a while -- I don''t recall which kernel versions were involved but a search of the archives should turn up the relevant information. -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
On Monday 20 March 2006 11:46, Tom Eastep wrote:> On Monday 20 March 2006 11:30, Phil DeVries wrote: > > Thank for your response. > > > > 1. I do have CONFIG_BRIDGE_NETFILTER=y in my kernel .config file (and in > > my running kernel.) > > I should add that bridge/netfilter was totally broken for a while -- I > don''t recall which kernel versions were involved but a search of the > archives should turn up the relevant information. >Here is what a bridge packet log message should look like: Feb 16 15:42:10 ursa kernel: Shorewall:FORWARD:REJECT:IN=xenbr1 OUT=xenbr1 PHYSIN=vif15.0 PHYSOUT=vif14.1 SRC=206.124.146.177 DST=192.58.128.30 LEN=65 TOS=0x00 PREC=0x00 TTL=64 ID=298 DF PROTO=UDP SPT=32769 DPT=53 LEN=45 Note the PHYSIN and PHYSOUT part. -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
On Monday 20 March 2006 11:59, Tom Eastep wrote:> On Monday 20 March 2006 11:46, Tom Eastep wrote: > > On Monday 20 March 2006 11:30, Phil DeVries wrote: > > > Thank for your response. > > > > > > 1. I do have CONFIG_BRIDGE_NETFILTER=y in my kernel .config file (and > > > in my running kernel.) > > > > I should add that bridge/netfilter was totally broken for a while -- I > > don''t recall which kernel versions were involved but a search of the > > archives should turn up the relevant information. > > Here is what a bridge packet log message should look like: > > Feb 16 15:42:10 ursa kernel: Shorewall:FORWARD:REJECT:IN=xenbr1 OUT=xenbr1 > PHYSIN=vif15.0 PHYSOUT=vif14.1 SRC=206.124.146.177 DST=192.58.128.30 LEN=65 > TOS=0x00 PREC=0x00 TTL=64 ID=298 DF PROTO=UDP SPT=32769 DPT=53 LEN=45 > > Note the PHYSIN and PHYSOUT part. >Note how the behavior on input seems to be correct: Chain br0_in (1 references) pkts bytes target prot opt in out source destination 18 2298 dynamic all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID,NEW 0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpts:67:68 18 2298 net2all all -- * * 0.0.0.0/0 0.0.0.0/0 PHYSDEV match --physdev-in eth0 0 0 all2all all -- * * 0.0.0.0/0 0.0.0.0/0 PHYSDEV match --physdev-in tun0 18 packets matched --physdev-in eth0 The log messages being generated suggest that the same cannot be said for OUTPUT where packets are not matching either --physdev-out rule (Neither of the dumps that you have supplied have had any output traffic so I have to rely on log messages generated before the last "shorewall [re]start"). -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
Thank you for your help. I built a newer kernel and checked to make sure that the appropriate physical device and bridging modules were built too. Shorewall is now doing what I wanted it to. I appreciate the quick help Tom. Regards, Philip DeVries, Happy Shorewall user. On Mon, 20 Mar 2006 15:35:43 -0800 Tom Eastep <teastep@shorewall.net> wrote:> On Monday 20 March 2006 11:59, Tom Eastep wrote: > > On Monday 20 March 2006 11:46, Tom Eastep wrote: > > > On Monday 20 March 2006 11:30, Phil DeVries wrote: > > > > Thank for your response. > > > > > > > > 1. I do have CONFIG_BRIDGE_NETFILTER=y in my kernel .config file (and > > > > in my running kernel.) > > > > > > I should add that bridge/netfilter was totally broken for a while -- I > > > don''t recall which kernel versions were involved but a search of the > > > archives should turn up the relevant information. > > > > Here is what a bridge packet log message should look like: > > > > Feb 16 15:42:10 ursa kernel: Shorewall:FORWARD:REJECT:IN=xenbr1 OUT=xenbr1 > > PHYSIN=vif15.0 PHYSOUT=vif14.1 SRC=206.124.146.177 DST=192.58.128.30 LEN=65 > > TOS=0x00 PREC=0x00 TTL=64 ID=298 DF PROTO=UDP SPT=32769 DPT=53 LEN=45 > > > > Note the PHYSIN and PHYSOUT part. > > > > Note how the behavior on input seems to be correct: > > Chain br0_in (1 references) > pkts bytes target prot opt in out source > destination > 18 2298 dynamic all -- * * 0.0.0.0/0 0.0.0.0/0 > state INVALID,NEW > 0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 > udp dpts:67:68 > 18 2298 net2all all -- * * 0.0.0.0/0 0.0.0.0/0 > PHYSDEV match --physdev-in eth0 > 0 0 all2all all -- * * 0.0.0.0/0 0.0.0.0/0 > PHYSDEV match --physdev-in tun0 > > 18 packets matched --physdev-in eth0 > > The log messages being generated suggest that the same cannot be said for > OUTPUT where packets are not matching either --physdev-out rule (Neither of > the dumps that you have supplied have had any output traffic so I have to > rely on log messages generated before the last "shorewall [re]start"). > > -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 xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642