Hello List, In the meantime I found the cause. With kernel 2.6.32-35-generic and lucid iptables iptables-save does not save the real iptables entries currently active. This should have only mild security implications and might only be observed on machines on machines with paranoid rulesets. How to detect: iptables -t nat -A POSTROUTING -p tcp -m conntrack --ctorigdst 192.168.0.0/24 -j SNAT --to-source 192.168.0.1 # iptables-save -t nat | grep POSTR :POSTROUTING ACCEPT [87:5264] -A POSTROUTING -p tcp -m conntrack --ctorigdst 192.168.0.0 -j SNAT --to-source 192.168.0.1 As you can see, the network prefix in the ctorigdst was lost during save, so rule is not the same after save, restore will restore broken rule. On kernel version 2.6.38-12-generic and Ubuntu oneiric iptables, everything works as expected. Could someone point me to the revision of the fix of this problem, so that I can forward info to Ubuntu? Thanks, Roman > -----Ursprüngliche Nachricht----- > Von: Fiedler Roman > Gesendet: Montag, 28. November 2011 12:47 > An: netfilter-devel@xxxxxxxxxxxxxxx > Betreff: Iptables ruleset modified somehow when performing "iptables- > save" followed by "iptables-restore" > > Hello List, > > I've observed failure in POSTROUTING in a way so strange, that I did not find > any suitable keywords to search the web for solution. But I guess, that > someone, who also observed that, will remember and perhaps could help > me towards a solution. > > Setup and how to reproduce: > =================== > > X--->--- > |--------- FW-----Net-Z > Y----<--- > > The firewall FW receives SYN from X for IP in Net-Z on eth0. Connection is > DNATed to Y and forwarded via eth0. To avoid TCP-breakup by reply from Y- > >X, connection is also SNATed to IP of firewall, so Y receives SYN from FW-IP. > > When building the iptables ruleset using various iptables [-t nat] -A ... > commands, the setup works. Conntrack shows > > # conntrack -L | grep YYYYYY.13 > tcp 6 431995 ESTABLISHED src=XXXXX.129 dst=NET-Z.252 sport=38231 > dport=8080 packets=2 bytes=112 src=YYYYYY.13 dst=FW-IP.250 sport=8080 > dport=38231 packets=1 bytes=60 [ASSURED] mark=0 secmark=0 use=2 > > After > > # iptables-save > iptables.x > # iptables-restore < iptables.x > > and sending SYN from X again conntrack is > # conntrack -L | grep YYYYYY.13 > tcp 6 115 SYN_SENT src=XXXXXX.129 dst=NET-Z.252 sport=38234 > dport=8080 packets=2 bytes=120 [UNREPLIED] src=YYYYYY.13 > dst=XXXXXXXX.129 sport=8080 dport=38234 packets=0 bytes=0 mark=0 > secmark=0 use=2 > > It seems that the POSTROUTING rule is not active, tcpdump really shows the > SYN leaving the firewall with source-IP unmodified (still X). > > Kernel version: 2.6.32-35-generic > Iptables version: iptables-save v1.4.4 on Mon Nov 28 11:36:06 2011 > > > Questions: > ======= > > * Should a save-restore-sequence lead to the exact same iptables-setup > before save or is the some other constraint to be met to guarantee save- > restore to restore exactly what was saved? (There were no concurrent > iptables table-modify activities on that machine during test except but active > network traffic). > * Why does the order of iptables rules created influence outcome? > * Does this behavior correspond to a known bug? > * If really bug, what are the exact effects? Could this be a security problem > when affecting filter instead of nat? > > Thanks for your help, > > DI Roman Fiedler > Safety & Security Department > Information Management & eHealth > > AIT Austrian Institute of Technology GmbH > Reininghausstrae 13/1 | 8020 Graz | Austria > T +43(0) 316 586570-63 | M +43(0) 664 8561599 | F +43(0) 316 586570-12 > roman.fiedler@xxxxxxxxx <mailto:roman.fiedler@xxxxxxxxx> | > http://www.ait.ac.at <http://www.ait.ac.at/> > http://www.ait.ac.at/eHealth/ <http://www.ait.ac.at/eHealth/> > > Kennen Sie die www.eHealth2011.at? > > FN: 115980 i HG Wien | UID: ATU14703506 > This email and any attachments thereto, is intended only for use by the > addressee(s) named herein and may contain legally privileged and/or > confidential information. If you are not the intended recipient, please notify > the sender by return e-mail or by telephone and delete this message from > your system and any printout thereof. Any unauthorized use, reproduction, > or dissemination of this message is strictly prohibited. Please note that e- > mails are susceptible to change. AIT Austrian Institute of Technology GmbH > shall not be liable for the improper or incomplete transmission of the > information contained in this communication, nor shall it be liable for any > delay in its receipt. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
