Thomas Heinz wrote: > Hallo guys Ciao > I have the following standard ipsec tunnel: > > [tun_A] host_A [pub_A]-------------[pub_B] host_B [tun_B] > > pub_A/B: public IP of host_A/B > tun_A/B: tunnel IP of host_A/B > > After establishing the ipsec connection, putting two simple log-all rules > in INPUT and OUTPUT like this: > # iptables -I INPUT -j LOG > # iptables -I OUTPUT -j LOG > and pinging tun_B from host_A, I get the following log entries: > > IN= OUT=eth0 SRC=tun_A DST=tun_B LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF > PROTO=ICMP TYPE=8 CODE=0 ID=16181 SEQ=1 > IN= OUT=eth0 SRC=pub_A DST=pub_B LEN=136 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF > PROTO=ESP SPI=0xxxxxxxxx > > Very nice so far: the packet is seen twice, once clear and once encrypted. > Now, let's look at the ICMP reply. > > IN=eth0 OUT= MAC=xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx SRC=pub_B > DST=pub_A LEN=136 TOS=0x00 PREC=0x00 TTL=56 ID=57843 PROTO=ESP > SPI=0xxxxxxxxx > IN=eth0 OUT= MAC=xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx SRC=pub_B > DST=pub_A LEN=104 TOS=0x00 PREC=0x00 TTL=56 ID=57843 PROTO=4 > > Here, we see the packet also twice but the cleartext one has PROTO=4 > (ipencap, ipip tunnel). You aren't seeing the clear text packet because because you should log also the FORWARD chain: 'iptables -I FORWARD -j LOG' > This has been observed in e.g. this thread: > http://marc.theaimsgroup.com/?l=netfilter-devel&m=114010374229806&w=2 > > However, I don't see any solution. What is your approach to filter > cleartext packets? You must filter packets in the FORWARD chain, nor INPUT nor OUTPUT > Is the issue considered a bug? Yes, the issue in the above thread is a know bug to the netfilter team.
