On 3/25/2015 5:23 PM, Damiano Verzulli wrote: > 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).
Please send me (directly) a tarball of your /etc/shorewall configuration so I can reproduce the problem. Thanks, -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________
signature.asc
Description: OpenPGP digital 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
