[strongSwan] Curious about why I can't see inbound packet with tcpdump

[Noel Kuntze]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello Zhang,

[1] graph shows the path packets follow in the netfilter part of the Linux kernel, which also shows, why it doesn't work as expected.

[1] http://inai.de/images/nf-packet-flow.png

Regards,
Noel Kuntze


GPG Key id: 0x63EC6658
Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658

Am 22.04.2014 10:08, schrieb ZHANG Cheng:
> Answer my own question for other's reference.
> It has been answered by
> <http://wiki.strongswan.org/projects/strongswan/wiki/FAQ#General-Questions>,
> but I just didn't realize that until I found this ticket
> <http://wiki.strongswan.org/issues/470>.
> 
> More digging leads me to
> <https://www.packtpub.com/sites/default/files/sample_chapters/openswan_chapter3_building_and_installing_openswan_0.pdf>,
> which has more explanation:
> 
> [quote]
> NETKEY also hooks into the networking code differently. Packets are
> intercepted by the IPsec
> stack after they are received on the physical ethX interface, and
> magically reappear on the same
> device in decrypted form. Packets that are being sent appear only in
> encrypted form. This
> complicates iptables-based firewall rules and can be confusing when
> using tcpdump to debug
> IPsec connections.
> This interception also creates problems when using NAT and IPsec on
> the same machine, since the
> packet does not traverse through all the iptables as expected.
> Unencrypted packets never travel the
> POSTROUTING table. The netfilter patch-o-matic set of patches contains
> fixes for this, but they
> are being tested and are not yet ready for inclusion in the kernel.
> [/quote]
> 
> On Tue, Apr 22, 2014 at 12:13 PM, ZHANG Cheng <czhang.oss at gmail.com> wrote:
>> Hi,
>>
>> I just setup a proof of concept StrongSwan instance with the help of
>> various references across Internet, and it works finally.
>> During my setup, I use tcpdump to debug the outgoing traffic, and I
>> found something I can't explain, so I'd like to ask knowledgeable
>> folks in this list.
>>
>> My tcpdump output is like this:
>> # tcpdump -nni eth0 -s 0 tcp port http
>> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
>> listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
>> 03:23:01.002667 IP 172.16.0.1.58591 > 202.106.169.188.80: Flags [S],
>> seq 2395687962, win 65535, options [mss 1240,nop,wscale 4,nop,nop,TS
>> val 871408526 ecr 0,sackOK,eol], length 0
>> 03:23:01.002736 IP 10.0.1.101.58591 > 202.106.169.188.80: Flags [S],
>> seq 2395687962, win 65535, options [mss 1240,nop,wscale 4,nop,nop,TS
>> val 871408526 ecr 0,sackOK,eol], length 0
>> 03:23:01.383449 IP 202.106.169.188.80 > 10.0.1.101.58591: Flags [S.],
>> seq 4167962077, ack 2395687963, win 5840, options [mss
>> 1460,nop,nop,sackOK,nop,wscale 7], length 0
>>
>> 10.0.1.101 is my eth0 IP, 172.16.0.0/24 is private subnet for VPN
>> client (rightsourceip=172.16.0.0/24).
>>
>> I set iptables rules as:
>>   iptables -t nat -A POSTROUTING -s 172.16.0.0/24 -o eth0 -j MASQUERADE
>>   iptables -A FORWARD -s 172.16.0.0/24 -j ACCEPT
>>
>> Now I see outbound packet with src ip 172.16.0.1 NAT into src ip
>> 10.0.1.101, but for corresponding inbound packet, I assume I should
>> see "202.106.169.188.80 > 172.16.0.1.58591" after "202.106.169.188.80
>>> 10.0.1.101.58591" but it doesn't show up this way. I am really
>> curious about why.
>>
>> Thanks.
> _______________________________________________
> Users mailing list
> Users at lists.strongswan.org
> https://lists.strongswan.org/mailman/listinfo/users
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJTVjYwAAoJEDg5KY9j7GZYuBYP/jTcV8niE4t2gy4MMsOTB9j2
iAE7rGIpRiOfhuvaWgVu5RNCgScrMb7vqTtmBfpzjzExjIrIlCsBywSNAPvODx2P
h06i+QvHkd7/mKbyXMJ64UUdpxnpdrs190gRKXCyxmlgzkxWiHmtSk7Efqm6dE/E
gANIBzeN2Wkppg4K3An27pZ6OM1yUvT5ALB1cRPJZDjN4bV6VcQd0BP9O+xLQ5P0
P5vJX9Er8d0b+5FQG+9K/rYHE3yfYJ+5SxYzr1V7Zqm7CgudDVRT9S5NaXDnTirf
jJnVM3lXJEK/p9v63weH25y+Ej+5Wl7LyFkE1gBuF11AwzQc/vyRr6ovqrdXM72I
n06w2Z73+aoGFXmT9BZ/tCM5kX/lREFl/bNy8EVEBUP8Ul8m7TQ2C5Cc8o4Dkl4b
hKMm86Qb71qaZlawvOMnYi3JFYwb5/ZuPMRwZ/odsXI52mnYOAs9H+AueD195BXi
l+z1Efri2W8gnxFQHwzOt0zHntJAlCkfWacd+F3oLka1vgRoT+EJYNDDJuGSrbnY
vPH7A6tpGrnckJw1ufaVU1VPNTEoalo+qXKmorvL9M1HOuh955jFar5nWgP8eyDx
kFmDpq2ViIDF9e0SUQlR1tZ7slABrM8m+PcdW9OTEa9FsazjPIhfBy/fgBNkeRP4
MyKzwoMF0tnwZB4/x77D
=8L1l
-----END PGP SIGNATURE-----