Shorewall users - Jan 2005 - Problem starting Shorewall using Bridge configuration

Hi

I have recently reconfigured my system to a Bridge based architecture on the 
basis that I have an ADSL Modem/Router with a Public address on the Wan side 
and a Private address on the Lan side.

I am running a Debian based system kernel 2.6.7 and the Bridging software is 
installed and working correctly, including startup etc.

The problem that I have is in "shorewall start"

The output form "shorewall debug start 2> /home/stewart/trace"
reveals an
error

" + iptables -A OUTPUT -o br0 -m physdev --physdev-out eth0 -j fw2net
iptables: No chain/target/match by that name
+ ''['' -z '''' '']''
+ stop_firewall"

It looks to me that the Chain "fw2net" isn''t being
recognised. Am I making a
mistake here in assuming that the default zone "fw" exists as in the
case of
the 2 interface example?

I include the following data for completeness :-

1) shorewall version  2.0.14


2) ip addr show
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 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc pfifo_fast qlen
1000
    link/ether 00:0d:61:73:66:60 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::20d:61ff:fe73:6660/64 scope link
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc pfifo_fast qlen
1000
    link/ether 00:04:5a:8c:67:6a brd ff:ff:ff:ff:ff:ff
    inet6 fe80::204:5aff:fe8c:676a/64 scope link
       valid_lft forever preferred_lft forever
4: br0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue
    link/ether 00:04:5a:8c:67:6a brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.4/24 brd 192.168.0.255 scope global br0
    inet6 fe80::204:5aff:fe8c:676a/64 scope link
       valid_lft forever preferred_lft forever
5: sit0: <NOARP> mtu 1480 qdisc noop
    link/sit 0.0.0.0 brd 0.0.0.0

3) ip route show
192.168.0.0/24 dev br0  proto kernel  scope link  src 192.168.0.4
default via 192.168.0.1 dev br0


I have attached the output from shorewall status and the trace file.

PS Also in the Bridge HowTo the last comment says to add "br0  
192.168.0.0/24
routeback" to the routestopped file.  Is this correct as there
doesn''t
appear to be any comments in the file about adding options to this file. 
Should this have been added to either the interfaces or hosts file instead?


Regards


Stewart


-- 
Stewart Outram
UK

stewart wrote:
> Hi
> 
> I have recently reconfigured my system to a Bridge based architecture on
the
> basis that I have an ADSL Modem/Router with a Public address on the Wan
side
> and a Private address on the Lan side.
> 
> I am running a Debian based system kernel 2.6.7 and the Bridging software
is
> installed and working correctly, including startup etc.
> 
> The problem that I have is in "shorewall start"
> 
> The output form "shorewall debug start 2> /home/stewart/trace"
reveals an
> error
> 
> " + iptables -A OUTPUT -o br0 -m physdev --physdev-out eth0 -j fw2net
> iptables: No chain/target/match by that name
> + ''['' -z '''' '']''
> + stop_firewall"
> 
> It looks to me that the Chain "fw2net" isn''t being
recognised. Am I making a
> mistake here in assuming that the default zone "fw" exists as in
the case of
> the 2 interface example?
My guess is that your kernel and/or iptables don''t support
''physdev''
match. Try this:

	iptables -N foo
	iptables -A foo -m physdev --physdev-out eth0 -j ACCEPT

Does it work?

-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

stewart wrote:
> PS Also in the Bridge HowTo the last comment says to add "br0  
192.168.0.0/24
> routeback" to the routestopped file.  Is this correct as there
doesn''t
> appear to be any comments in the file about adding options to this file. 
> Should this have been added to either the interfaces or hosts file instead?
>
It is the routestopped file -- the two-interface sample apparently
hasn''t been updated to include the OPTIONS column.

-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

stewart wrote:
> Hi Tom
> 
> Sadly looks like you are correct.
> 
> Using iptables v1.2.11
> 
> and Kernel 2.6.7
> 
> iptables -N foo
> root@31[stewart]#  iptables -A foo -m physdev --physdev-out eth0 -j ACCEPT
> iptables: No chain/target/match by that name
> 
> I thought the phys_dev was included in 1.2.11?
> 
It is. You can tell if iptables has the match by:

	iptables -m physdev -h

At the bottom of the output, you should see:

physdev v1.2.11 options:
 --physdev-in [!] input name[+]         bridge port name ([+] for wildcard)
 --physdev-out [!] output name[+]       bridge port name ([+] for wildcard)
 [!] --physdev-is-in                    arrived on a bridge device
 [!] --physdev-is-out                   will leave on a bridge device
 [!] --physdev-is-bridged               it''s a bridged packet

Did you rebuild your kernel and omit that option?

-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

PLEASE KEEP THIS ON THE LIST.

stewart wrote:
>   
> No I haven''t touched the Kernel. I am using ProMepis a Debian
Distro Kernel as
> supplied.
> 
> There does seem some evidence of a physdev lib on my system :
> 
> locate ipt_physdev
> /lib/iptables/libipt_physdev.so
> /usr/include/linux/netfilter_ipv4/ipt_physdev.h
> 
But no /lib/modules/$(uname -r)/kernel/net/ipv4/ipt_physdev.*
> 
> Its a pity because this looked like a neat solution for my network. I was 
> Natting twice before, once at the Firewall and again in the Router and that
> just didn''t feel right.
> 
Yep -- it''s a much cleaner solution all right -- I don''t know
why
distros decide to simply omit functionality when it is nicely modularized.

-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

>>
>>But no /lib/modules/$(uname -r)/kernel/net/ipv4/ipt_physdev.*
>>
In case anyone follows this thread -- the above should have been:

/lib/modules/$(uname -r)/kernel/net/ipv4/netfilter/ipt_physdev.*


teastep@ursa:~> ls /lib/modules/\
$(uname -r)/kernel/net/ipv4/netfilter/ipt_physdev.*
/lib/modules/2.6.8-24.10-default/kernel/net/ipv4/netfilter/ipt_physdev.ko
teastep@ursa:~>

-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