The bridging documentation (http://shorewall.net/2.0/bridge.html) has been expanded and there is a refresh of the bridging code (ftp://shorewall.net/pub/shorewall/Bridging and http://shorewall.net/pub/shorewall/Bridging). -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
Tom;
Just a short note to let you know where I am up to with the Bridging
testing.
So far I have only tested a 2.4.25 kernel. The testing has gone very well. The
only problem that I have come across is with REJECT. I only stumbled across
the problem this evening. At this stage I don''t know if the problem is
with
my Shorewall config, the kernel or Shorewall. It''s after midnight here
in the
UK so I am going to have leave it until tomorrow. I will keep you informed of
my findings.
I can confirm that Shorewall and bridging does work if the bridge does not
have an IP address. I haven''t tried REJECT in this environment yet. I
am not
sure if REJECT should work if the bridge doesn''t have an IP address,
will
Netfilter be able to issue the ICMP packet?
As Physical Device support is implemented differently in 2.6 kernels, I cannot
guarantee that any of the above applies to that environment. I hope to start
testing Shorewall/bridging against 2.6.4 this weekend.
Regards Steven.
On Saturday 06 March 2004 22:46, Tom Eastep wrote:> The bridging documentation (http://shorewall.net/2.0/bridge.html) has been
> expanded and there is a refresh of the bridging code
> (ftp://shorewall.net/pub/shorewall/Bridging and
> http://shorewall.net/pub/shorewall/Bridging).
>
> -Tom
> --
> Tom Eastep \ Nothing is foolproof to a sufficiently talented fool
> Shoreline, \ http://shorewall.net
> Washington USA \ teastep@shorewall.net
> _______________________________________________
> Shorewall-users mailing list
> Post: Shorewall-users@lists.shorewall.net
> Subscribe/Unsubscribe:
> https://lists.shorewall.net/mailman/listinfo/shorewall-users Support:
> http://www.shorewall.net/support.htm
> FAQ: http://www.shorewall.net/FAQ.htm
Steven Jan Springl wrote:> So far I have only tested a 2.4.25 kernel. The testing has gone very well. The > only problem that I have come across is with REJECT.Thanks for the update Steven. Please keep me informed of your progress. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
Tom;
I have solved the problem I had with REJECT.
When the REJECT is issued, the following messages are generated:
Mar 17 19:28:58 f2 kernel: Shorewall:wan2lan:REJECT:IN=br0 OUT=br0 PHYSIN=eth1
PHYSOUT=eth0 SRC=192.168.0.1 DST=192.168.0.3 LEN=52 TOS=0x10 PREC=0x00 TTL=64
ID=14326 DF PROTO=TCP SPT=32907 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0
Mar 17 19:28:58 f2 kernel: Shorewall:FORWARD:DROP:IN=br0 OUT=br0 PHYSIN=eth1
PHYSOUT=eth1 SRC=192.168.0.3 DST=192.168.0.1 LEN=40 TOS=0x10 PREC=0x00
TTL=255 ID=0 DF PROTO=TCP SPT=22 DPT=32907 WINDOW=0 RES=0x00 ACK RST UR
In the second message, both PHYSIN and PHYSOUT are set to eth1. Not having a
chain to deal with this, the " all to all " policy of DROP was used.
Setting routeback on the interfaces in /etc/shorewall/hosts cured the problem.
That concludes the testing I intend to do on the basic Shorewall features.
I shall now turn my attention to DNAT, SNAT and masquerading.
If you can think of scenario in which proxyarp would be used with bridging or
any other aspects of Shorewall that you think need testing, I will try to
setup configs. to test.
Steven.
On Tuesday 16 March 2004 01:54, Tom Eastep wrote:> Steven Jan Springl wrote:
> > So far I have only tested a 2.4.25 kernel. The testing has gone very
> > well. The only problem that I have come across is with REJECT.
>
> Thanks for the update Steven. Please keep me informed of your progress.
>
> -Tom
On Wednesday 17 March 2004 12:50 pm, Steven Jan Springl wrote:> > Mar 17 19:28:58 f2 kernel: Shorewall:FORWARD:DROP:IN=br0 OUT=br0 > PHYSIN=eth1 PHYSOUT=eth1 SRC=192.168.0.3 DST=192.168.0.1 LEN=40 TOS=0x10 > PREC=0x00 TTL=255 ID=0 DF PROTO=TCP SPT=22 DPT=32907 WINDOW=0 RES=0x00 ACK > RST UR > > In the second message, both PHYSIN and PHYSOUT are set to eth1. Not having > a chain to deal with this, the " all to all " policy of DROP was used. > Setting routeback on the interfaces in /etc/shorewall/hosts cured the > problem.Ok -- I''ll set routeback unconditionally on bridge entries in /etc/shorewall/hosts.> > That concludes the testing I intend to do on the basic Shorewall features. > I shall now turn my attention to DNAT, SNAT and masquerading. > If you can think of scenario in which proxyarp would be used with bridging > or any other aspects of Shorewall that you think need testing, I will try > to setup configs. to test.I''ve tested REDIRECT. Other than that, I think that the other scenarios involving SNAT, DNAT, etc. will likely only be used with a bridge/router. Those *should* work fine because there is nothing unique about a bridge interface in those cases. Thanks so much for your help, -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
On Wednesday 17 March 2004 21:02, Tom Eastep wrote:> I''ve tested REDIRECT. Other than that, I think that the other scenarios > involving SNAT, DNAT, etc. will likely only be used with a bridge/router. > Those *should* work fine because there is nothing unique about a bridge > interface in those cases. > > Thanks so much for your help, > -TomYou are very welcome. I will start testing with kernel 2.6.4 in the next day or so. Steven.
Tom/Steven, I have Bridging firewall working on a 2.4.25 kernel with Shorewall 2.0.1Beta 1. I have ACCEPT, DROP, REJECT, REDIRECT, DNAT working fine on that machine. The bridge has an IP assigned to it. I also have Squid proxy and an apache intranet server running on the same machine without any problem. Just thought will let you know since it is on the same subject. Tom, Thanks for Shorewall and your ultra quick response for all the questions regarding shorewall. Sakthi -----Original Message----- From: shorewall-users-bounces+sakthi=altair.com@lists.shorewall.net [mailto:shorewall-users-bounces+sakthi=altair.com@lists.shorewall.net] On Behalf Of Tom Eastep Sent: Wednesday, March 17, 2004 4:03 PM To: shorewall@springl.fsnet.co.uk; Mailing List for Shorewall Users Subject: Re: [Shorewall-users] Bridging Update On Wednesday 17 March 2004 12:50 pm, Steven Jan Springl wrote:> > Mar 17 19:28:58 f2 kernel: Shorewall:FORWARD:DROP:IN=br0 OUT=br0 > PHYSIN=eth1 PHYSOUT=eth1 SRC=192.168.0.3 DST=192.168.0.1 LEN=40 > TOS=0x10 PREC=0x00 TTL=255 ID=0 DF PROTO=TCP SPT=22 DPT=32907 WINDOW=0 > RES=0x00 ACK RST UR > > In the second message, both PHYSIN and PHYSOUT are set to eth1. Not > having a chain to deal with this, the " all to all " policy of DROP > was used. Setting routeback on the interfaces in /etc/shorewall/hosts > cured the problem.Ok -- I''ll set routeback unconditionally on bridge entries in /etc/shorewall/hosts.> > That concludes the testing I intend to do on the basic Shorewall > features. I shall now turn my attention to DNAT, SNAT and > masquerading. If you can think of scenario in which proxyarp would be > used with bridging or any other aspects of Shorewall that you think > need testing, I will try to setup configs. to test.I''ve tested REDIRECT. Other than that, I think that the other scenarios involving SNAT, DNAT, etc. will likely only be used with a bridge/router. Those *should* work fine because there is nothing unique about a bridge interface in those cases. Thanks so much for your help, -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net _______________________________________________ Shorewall-users mailing list Post: Shorewall-users@lists.shorewall.net Subscribe/Unsubscribe: https://lists.shorewall.net/mailman/listinfo/shorewall-users Support: http://www.shorewall.net/support.htm FAQ: http://www.shorewall.net/FAQ.htm
On Thursday 18 March 2004 09:21 am, Sakthivel Subramanian wrote:> Tom/Steven, > > I have Bridging firewall working on a 2.4.25 kernel with Shorewall > 2.0.1Beta 1. > > I have ACCEPT, DROP, REJECT, REDIRECT, DNAT working fine on that machine. > The bridge has an IP assigned to it. I also have Squid proxy and an apache > intranet server running on the same machine without any problem. > > Just thought will let you know since it is on the same subject. >Thanks for the update. I''m running pretty much the same setup without Apache.> > Thanks for Shorewall and your ultra quick response for all the questions > regarding shorewall. >-Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
Tom;
I have been testing bridging in a kernel 2.6.4 environment. I
didn''t
encounter any problems. However I did find one peculiarity. Unlike kernel
2.4.25, REJECT works without the "routeback" option on the interfaces
in
/etc/shorewall/hosts.
Steven.
Steven Jan Springl wrote:> Tom; > I have been testing bridging in a kernel 2.6.4 environment. I didn''t > encounter any problems. However I did find one peculiarity. Unlike kernel > 2.4.25, REJECT works without the "routeback" option on the interfaces in > /etc/shorewall/hosts. >Thanks, Steven. Shorewall 2.0.1 Beta 2 includes code that will make it unnecessary to specify ''routeback'' on 2.4 kernels as well. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
Tom;
One piece of information I forgot to include in my last email:
REJECT does not work if the bridge does not have an IP address. That is
REJECT functions as if DROP had been specified. In an attempt to discover
what was happening, I added the iptables rules below to those generated by
Shorewall.
All I saw was a packet comming into the firewall on the FORWARD chain and then
the packet been rejected, but no packets were sent back to the source.
This applies to both kernels 2.4.25 and 2.6.4. ACCEPT and DROP both function
correctly.
iptables -I FORWARD 1 -j LOG --log-prefix "Shorewall:FORWARD:TRACE:"
iptables -I OUTPUT 1 -j LOG --log-prefix "Shorewall:OUTPUT:TRACE:"
iptables -I INPUT 1 -j LOG --log-prefix "Shorewall:INPUT:TRACE:"
Steven.
Steven Jan Springl wrote:> Tom; > One piece of information I forgot to include in my last email: > REJECT does not work if the bridge does not have an IP address. That is > REJECT functions as if DROP had been specified. In an attempt to discover > what was happening, I added the iptables rules below to those generated by > Shorewall. > All I saw was a packet comming into the firewall on the FORWARD chain and then > the packet been rejected, but no packets were sent back to the source. > This applies to both kernels 2.4.25 and 2.6.4. ACCEPT and DROP both function > correctly. > > iptables -I FORWARD 1 -j LOG --log-prefix "Shorewall:FORWARD:TRACE:" > iptables -I OUTPUT 1 -j LOG --log-prefix "Shorewall:OUTPUT:TRACE:" > iptables -I INPUT 1 -j LOG --log-prefix "Shorewall:INPUT:TRACE:" >Thanks, steven I don''t find that particularly surprising since REJECT must create a packet to return to the packet source. If the bridge doesn''t have an address then what IP address should be used for the source IP in this manufactured packet? -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
On Sat Mar 03/20/04, 2004 at 07:23:39PM -0800, Tom Eastep wrote:> Steven Jan Springl wrote: > > > Tom; > > One piece of information I forgot to include in my last email: > > REJECT does not work if the bridge does not have an IP address. That is > > REJECT functions as if DROP had been specified. In an attempt to discover[elided]> I don''t find that particularly surprising since REJECT must create a > packet to return to the packet source. If the bridge doesn''t have an > address then what IP address should be used for the source IP in this > manufactured packet?Anyone feel free to jump in here and correct me, but should the firewall host not use the destination address to generate the REJECT, regardless of its own address? I realize this may be hard to code, or even impossible, but it would be the Right Thing To Do (tm), unless you intend on announcing the presence of a firewall... I know that a true "router"''s job would be to send the REJECT with its own source address, but firewalls are a different breed, or they should be. Just my $0.05CDN adjusted.... -- Greg White
Greg White wrote:> >>I don''t find that particularly surprising since REJECT must create a >>packet to return to the packet source. If the bridge doesn''t have an >>address then what IP address should be used for the source IP in this >>manufactured packet? > > > Anyone feel free to jump in here and correct me, but should the firewall > host not use the destination address to generate the REJECT, regardless > of its own address? I realize this may be hard to code, or even > impossible, but it would be the Right Thing To Do (tm), unless you > intend on announcing the presence of a firewall... > > I know that a true "router"''s job would be to send the REJECT with its > own source address, but firewalls are a different breed, or they should > be. Just my $0.05CDN adjusted.... >I realized after I posted is that the real reason the REJECT doesn''t work is that the Netfilter code to generate a REJECT packet relies on the routing table; a bridge with no IP address has no visibility in the table. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
Tom Eastep wrote:> Steven Jan Springl wrote: > >> Tom; >> One piece of information I forgot to include in my last email: >> REJECT does not work if the bridge does not have an IP address. That is >> REJECT functions as if DROP had been specified. In an attempt to >> discover what was happening, I added the iptables rules below to those >> generated by Shorewall. All I saw was a packet comming into the >> firewall on the FORWARD chain and then the packet been rejected, but >> no packets were sent back to the source. This applies to both kernels >> 2.4.25 and 2.6.4. ACCEPT and DROP both function correctly. >> >> iptables -I FORWARD 1 -j LOG --log-prefix "Shorewall:FORWARD:TRACE:" >> iptables -I OUTPUT 1 -j LOG --log-prefix "Shorewall:OUTPUT:TRACE:" >> iptables -I INPUT 1 -j LOG --log-prefix "Shorewall:INPUT:TRACE:" >> > > Thanks, steven > > I don''t find that particularly surprising since REJECT must create a > packet to return to the packet source. If the bridge doesn''t have an > address then what IP address should be used for the source IP in this > manufactured packet? > > -TomWow! Now here''s a topic for debate. In its purest form (OSI model), a bridge is a layer 2 device that deals with frames of data. A REJECT packet requires layer 3 IP data to be added into the layer 2 frame. But yet netfilter/shorewall has the capability of REJECT''ing a packet at layer 2 or 3. Now comes the interesting part - if a "frame" of data is rejected at layer 2, could (or even should) a REJECT packet be sent back to the sending system, which BTW, would be expecting to process this REJECT at layer 3? Am I missing anything here? BTW: I don''t believe my WAP sends a REJECT even though I have MAC address filtering enabled. Should we expect netfilter/shorewall to do the same? I don''t even know if its possible. Brushing the dust off his Cisco books. :-) Steve Cowles
Tom Eastep wrote:> > I realized after I posted is that the real reason the REJECT doesn''t > work is that the Netfilter code to generate a REJECT packet relies on > the routing table; a bridge with no IP address has no > visibility in the > table. > > -TomDamn! I knew I should have checked before I hit the send button. Steve
Cowles, Steve wrote:> Tom Eastep wrote: > >>I realized after I posted is that the real reason the REJECT doesn''t >>work is that the Netfilter code to generate a REJECT packet relies on >>the routing table; a bridge with no IP address has no >>visibility in the >>table. > > Damn! I knew I should have checked before I hit the send button. >I should have thought more before posting as well -- the patch I conconcted to make REJECT work again on RH Kernels circa 2.4.20-9 (see http://shorewall.net/errata.htm) corrected the order of arguments to a route lookup call. If I would have thought about that before posting, I would have avoided this teapot tempest. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net