-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi all!
This morning we upgraded one of our firewalls, moving from an old
shorewall 4.0.6 to a more current 4.5.4 (CentOS 6.6 RPM -
shorewall-4.5.4-1.el6.noarch).
Everything went OK, with the exception of some DNAT rules. In short:
- - we're running a three-interfaces firewall, with:
- "em1" and "em3" bridged into "br0"
- "em2" used as an 802.1q trunk with several VLANs associated to various
zones/interfaces:
[.......zones.........]
fw firewall
brdg ipv4
net:brdg bport4
dmz:brdg bport4
loc ipv4
mngmt ipv4
...
[^^^^^^^^^^^^^^^^^^^^^^]
[..... interfaces ......]
brdg br0 detect bridge,[...]
net br0:em1
dmz br0:em3
loc em2.51
voser em2.20 # voip server
ibver em2.21 # ibrida verde
...
[^^^^^^^^^^^^^^^^^^^^^^^^]
- - among a quite long series of "rules", we have this one:
[...... rules ......]
DNAT brdg loc:172.18.10.10 tcp 22,25,110,143 - 129.176.15.10
[^^^^^^^^^^^^^^^^^^^]
that, unfortunatly, was not working properly.
After some investigation, we saw that even though shorewall properly
compiled the underlying iptables/netfilter DNAT rules, such rule *IS
NEVER REACHED*. In detail, we saw that:
- - in the PREROUTING chain there were a single JUMP to the "dnat" chain;
- - our DNAT-rule were correctly placed in the "brdg_dnat" chain;
- - along the "dnat" chain, a jump to the "brdg_dnat" chain were *NOT*
reached, due to a couple of RETURN, handling 100% of the bridge-incoming
traffic.
In short:
[----- shorewall show -t nat -------]
Counters reset Thu Mar 26 01:06:22 CET 2015
Chain PREROUTING (policy ACCEPT 2729 packets, 212K bytes)
pkts bytes target prot opt in out source
destination
2730 212K dnat all -- * * 0.0.0.0/0
0.0.0.0/0
[...]
Chain dnat (1 references)
pkts bytes target prot opt in out source
destination
1123 83892 RETURN all -- br0 * 0.0.0.0/0
0.0.0.0/0 PHYSDEV match --physdev-in em1
126 13770 RETURN all -- br0 * 0.0.0.0/0
0.0.0.0/0 PHYSDEV match --physdev-in em3
0 0 brdg_dnat all -- br0 * 0.0.0.0/0
0.0.0.0/0
[....]
Chain brdg_dnat (1 references)
pkts bytes target prot opt in out source
destination
0 0 DNAT tcp -- * * 0.0.0.0/0
129.176.15.10 multiport dports 22,25,110,143
to:172.18.10.10
[...]
[^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^]
As it can clearly be seen from the "iptables-save" fragments:
- -------------------------------
- -A dnat -i br0 -m physdev --physdev-in em1 -j RETURN
- -A dnat -i br0 -m physdev --physdev-in em3 -j RETURN
- -A dnat -i br0 -j brdg_dnat
[....]
- -------------------------------
all the traffic coming to the bridge, via the "em1" interface or the
"em3" interface is simply matched by the first two rules and.... never
reach the third rule (...so to be properly managed by the real DNAT
chain/rules).
Is this a bug?
Or are we missing a major point in the 4.5.4 configuration?
Please note that, while searching for a definitive solution, we have
setup an "hack" by putting:
- ----------------
/sbin/iptables -t nat -D dnat -i br0 -m physdev --physdev-in em1 -j RETURN
/sbin/iptables -t nat -D dnat -i br0 -m physdev --physdev-in em3 -j RETURN
- ----------------
in /etc/shorewall/started and... now everything work correctly :-)
Should you need further information, don't hesitate to ask (I'm
deliberately avoinding to provide all the cfg files, as they are quite...
large and, in our opinion, not strictly related to the problem. But,
again, if you need info, please ask).
Cheers,
DV
- --
Damiano Verzulli
e-mail: [email protected]
- ---
possible?ok:while(!possible){open_mindedness++}
- ---
"Technical people tend to fall into two categories: Specialists
and Generalists. The Specialist learns more and more about a
narrower and narrower field, until he eventually, in the limit,
knows everything about nothing. The Generalist learns less and
less about a wider and wider field, until eventually he knows
nothing about everything." - William Stucke - AfrISPA
http://elists.isoc.org/mailman/private/pubsoft/2007-December/001935.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iEYEARECAAYFAlUTUWYACgkQcwT9fsMT4SztJACdFoCwG4+ba20aydzoBaBJGiE+
EEwAn1A6PS48+V1wnIsJnotHBW4dX1DY
=OtBp
-----END PGP SIGNATURE-----
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Shorewall-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-users
