Hi all... my first post so please be gentle ;)
I believe I''ve found a bug in the latest Shorewall (2.0.3c). In a
nutshell (full nut follows, don''t worry):
The following rule works:
DNAT:info loc vm:10.0.0.127:80 tcp 83
But this one causes ``shorewall start'''' to fail with an
iptables
error:
DNAT:info fw vm:10.0.0.127:80 tcp 83
When I start shorewall with the ``debug'''' parameter, I can
see that
somehow with the second rule, shorewall doesn''t add the
"-t" switch
before the "nat" table argument:
++ printf Shorewall:%s:%s: DNAT
+ prefix=Shorewall:DNAT::-t
+ ''['' 19 -gt 29 '']''
+ iptables -A DNAT nat -p tcp -d 0.0.0.0/0 --dport 83 -j LOG --log-level info
--log-prefix ''Shorewall:DNAT::-t ''
Try `iptables -h'' or ''iptables --help'' for more
information.
</nutshell>
Here are all of the relevant files in /etc/shorewall:
[16:06:51][root@bugs shorewall]# grep -v ''^#'' zones
net Net Internet
loc Local Local networks
dmz DMZ Demilitarized zone
vm Virtual VMware virtual network
[16:07:34][root@bugs shorewall]# grep -v ''^#'' interfaces
loc eth0 detect dhcp,nobogons,routefilter,tcpflags,arp_filter,nosmurfs
net eth1 detect norfc1918,nobogons,routefilter,tcpflags,arp_filter,nosmurfs
vm vmnet detect nobogons,routefilter,tcpflags,arp_filter,nosmurfs
[16:08:36][root@bugs shorewall]# grep -v ''^#'' policy
fw all ACCEPT
loc net DROP info
loc vm DROP info
loc all DROP info
net loc DROP info
net vm DROP info
net all DROP
vm fw ACCEPT info
vm all DROP info
all all REJECT info
[16:09:16][root@bugs shorewall]# grep -v ''^#'' rules
AllowSSH all fw
AllowPing all fw
# RULE_A
DNAT loc vm:10.0.0.10:80 tcp 82
# RULE_B
DNAT fw vm:10.0.0.10:80 tcp 82
Note above that there are two rules marked RULE_A and RULE_B. These
are what we''ll play with to see the bug.
And here''s the obligatory system configuration listing:
[16:11:51][root@bugs shorewall]# uname -a
Linux bugs.md.com.my 2.6.6-1.435.2.3smp #1 SMP Thu Jul 1 08:36:21 EDT 2004
i686 i686 i386 GNU/Linux
[16:11:53][root@bugs shorewall]# shorewall version
2.0.3c
[16:12:04][root@bugs shorewall]# 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: sit0: <NOARP> mtu 1480 qdisc noop
link/sit 0.0.0.0 brd 0.0.0.0
5: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:02:b3:26:f2:90 brd ff:ff:ff:ff:ff:ff
inet 192.168.34.16/24 brd 192.168.34.255 scope global eth0
inet6 fe80::202:b3ff:fe26:f290/64 scope link
valid_lft forever preferred_lft forever
6: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:00:1c:d7:34:d8 brd ff:ff:ff:ff:ff:ff
inet 203.106.89.111/24 brd 203.106.89.255 scope global eth1
inet6 fe80::200:1cff:fed7:34d8/64 scope link
valid_lft forever preferred_lft forever
9: vmnet1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:50:56:c0:00:01 brd ff:ff:ff:ff:ff:ff
inet 10.0.0.1/24 brd 10.0.0.255 scope global vmnet1
inet6 fe80::250:56ff:fec0:1/64 scope link
valid_lft forever preferred_lft forever
[16:12:50][root@bugs shorewall]# ip route show
203.121.72.3 via 192.168.34.254 dev eth0
202.187.247.9 via 192.168.34.254 dev eth0
202.71.104.49 via 192.168.34.254 dev eth0
218.111.105.170 via 192.168.34.254 dev eth0
10.0.0.0/24 dev vmnet1 proto kernel scope link src 10.0.0.1
192.168.34.0/24 dev eth0 scope link
203.106.89.0/24 dev eth1 scope link
169.254.0.0/16 dev eth1 scope link
127.0.0.0/8 dev lo scope link
default via 203.106.89.97 dev eth1
Now the debug. This is *large*, so I''ve gzipped the outupt and
attached it. Apologies to anybody using MS products, but the
attachment uses UNIX line endings >:)
With RULE_A included but not RULE_B, shorewall starts nicely and
performs as expected.
With RULE_B included but not RULE_A, ``shorewall
start'''' and
``shorewall debug start'''' produce std(out|err) as
captured in
rule_b_bad.log.gz, and shorewall does not start.
As I noted in the teaser at the start of this (seemingly interminable)
email, you should see at the end of the "bad" output that iptables
complains because it''s started without the ``-t''''
option to the
``nat'''' parameter. Now if I''m right and this is a
bug and not some
boneheadedness on my part, somebody gets to dive into the C and search
for a bizarre bug in the parser where two 99% identical rules generate
different output...
Hope this is all coherent... let me know if more info is required.
Thanks!
--
~ You are in a maze of twisty passages, all alike.
Christopher DeMarco
Product Research and Development
My Directory Sdn Bhd (www.md.com.my)
cdemarco@md.com.my
+6013 389 5658
Christopher DeMarco wrote:> Hi all... my first post so please be gentle ;) > > I believe I''ve found a bug in the latest Shorewall (2.0.3c). In a > nutshell (full nut follows, don''t worry): > > The following rule works: > > DNAT:info loc vm:10.0.0.127:80 tcp 83 > > But this one causes ``shorewall start'''' to fail with an iptables > error: > > DNAT:info fw vm:10.0.0.127:80 tcp 83 > > When I start shorewall with the ``debug'''' parameter, I can see that > somehow with the second rule, shorewall doesn''t add the "-t" switch > before the "nat" table argument: > > ++ printf Shorewall:%s:%s: DNAT > + prefix=Shorewall:DNAT::-t > + ''['' 19 -gt 29 '']'' > + iptables -A DNAT nat -p tcp -d 0.0.0.0/0 --dport 83 -j LOG --log-level info --log-prefix ''Shorewall:DNAT::-t '' > Try `iptables -h'' or ''iptables --help'' for more information. >In line 3071 of /usr/share/shorewall/firewall, change $OUTPUT to OUTPUT and report if that fixes the problem. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
Tom Eastep wrote:> > In line 3071 of /usr/share/shorewall/firewall, change $OUTPUT to OUTPUT > and report if that fixes the problem. >Gee -- that was blunt; my manners seem to be asleep yet. I''ve placed an updated script in ftp://shorewall.net/pub/shorewall/errata/2.0.3/firewall. Please give it a try and let me know if it works for you. I found another similar bug which is also corrected in that code. If the code works OK for you, I''ll release it as 2.0.4 in the next few days. Thanks, -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
Christopher DeMarco wrote:> As I noted in the teaser at the start of this (seemingly interminable) > email, you should see at the end of the "bad" output that iptables > complains because it''s started without the ``-t'''' option to the > ``nat'''' parameter. Now if I''m right and this is a bug and not some > boneheadedness on my part, somebody gets to dive into the C and search > for a bizarre bug in the parser where two 99% identical rules generate > different output...Just so you''ll know, Shorewall is written %100 in Bourne Shell -- it contains no C code. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
Tom Eastep wrote:> Christopher DeMarco wrote: > >> As I noted in the teaser at the start of this (seemingly interminable) >> email, you should see at the end of the "bad" output that iptables >> complains because it''s started without the ``-t'''' option to the >> ``nat'''' parameter. Now if I''m right and this is a bug and not some >> boneheadedness on my part, somebody gets to dive into the C and search >> for a bizarre bug in the parser where two 99% identical rules generate >> different output... > > > Just so you''ll know, Shorewall is written %100 in Bourne Shell -- it > contains no C code. >And the reason that one case succeeds where a very similar one fails is that the failing case has ''fw'' as the source zone. Netfilter/iptables treats traffic to/from the local system quite differently from traffic that is being forwarded through the box. While Shorewall hides these differences for the most part, there is a lot of separate logic to handle the two different traffic types. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
On Tue, Jul 06, 2004 at 06:26:26AM -0700, Tom Eastep wrote:> In line 3071 of /usr/share/shorewall/firewall, change $OUTPUT to > OUTPUT and report if that fixes the problem.It does indeed. Quick reply, and no it wasn''t too blunt ;) -- ~ You are in a maze of twisty passages, all alike. Christopher DeMarco Product Research and Development My Directory Sdn Bhd (www.md.com.my) cdemarco@md.com.my +6013 389 5658
Christopher DeMarco wrote:> On Tue, Jul 06, 2004 at 06:26:26AM -0700, Tom Eastep wrote: > > >>In line 3071 of /usr/share/shorewall/firewall, change $OUTPUT to >>OUTPUT and report if that fixes the problem. > > > It does indeed. > > Quick reply, and no it wasn''t too blunt ;) > >Thanks! -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net