Hi Farid, no plaintext packets are transmitted! You only see decrypted payloads on the inbound side because of the peculiar way tcpdump hooks into theLinux Netfilter stack. Incoming ESP packets are queued twice in the Netfilter INPUT chain: first in encrypted form and then again as
plaintext packets.
If you activate tcpdump on a separate host in front of the VPN client|server then you will register encrypted ESP packets only. Regards Andreas On 18.10.2013 18:35, Farid Farid wrote:
Hi Martin, After establishing the successful secure connection between two hosts I am using PING to validate the connectivity. I am capturing the data using TCPDUMP. It is interesting that I can still see the ech-request in plain text I pinged from both sides but no matter what I can see echo-request in plain text. Below you can see output of TCPDUMP: 16:29:40.455844 IP 192.168.1.209 > 192.168.1.55: ESP(spi=0xcaec41a1,seq=0x26), length 132 16:29:40.456164 IP 192.168.1.209 > 192.168.1.55: ICMP echo request, id 19103, seq 1, length 64 16:29:40.456654 IP 192.168.1.55 > 192.168.1.209: ESP(spi=0xc51dee21,seq=0x26), length 132 16:29:41.457091 IP 192.168.1.209 > 192.168.1.55: ESP(spi=0xcaec41a1,seq=0x27), length 132 16:29:41.457406 IP 192.168.1.209 > 192.168.1.55: ICMP echo request, id 19103, seq 2, length 64 16:29:41.457844 IP 192.168.1.55 > 192.168.1.209: ESP(spi=0xc51dee21,seq=0x27), length 132 16:29:42.458345 IP 192.168.1.209 > 192.168.1.55: ESP(spi=0xcaec41a1,seq=0x28), length 132 16:29:42.458658 IP 192.168.1.209 > 192.168.1.55: ICMP echo request, id 19103, seq 3, length 64 16:29:42.459092 IP 192.168.1.55 > 192.168.1.209: ESP(spi=0xc51dee21,seq=0x28), length 132 16:29:43.459526 IP 192.168.1.209 > 192.168.1.55: ESP(spi=0xcaec41a1,seq=0x29), length 132 16:29:43.459844 IP 192.168.1.209 > 192.168.1.55: ICMP echo request, id 19103, seq 4, length 64 16:29:43.460283 IP 192.168.1.55 > 192.168.1.209: ESP(spi=0xc51dee21,seq=0x29), length 132 16:29:44.460732 IP 192.168.1.209 > 192.168.1.55: ESP(spi=0xcaec41a1,seq=0x2a), length 132 16:29:44.461050 IP 192.168.1.209 > 192.168.1.55: ICMP echo request, id 19103, seq 5, length 64 16:29:44.461552 IP 192.168.1.55 > 192.168.1.209: ESP(spi=0xc51dee21,seq=0x2a), length 132 16:29:45.462021 IP 192.168.1.209 > 192.168.1.55: ESP(spi=0xcaec41a1,seq=0x2b), length 132 16:29:45.462338 IP 192.168.1.209 > 192.168.1.55: ICMP echo request, id 19103, seq 6, length 64 16:29:45.462773 IP 192.168.1.55 > 192.168.1.209: ESP(spi=0xc51dee21,seq=0x2b), length 132 16:29:46.463225 IP 192.168.1.209 > 192.168.1.55: ESP(spi=0xcaec41a1,seq=0x2c), length 132 Am I supposed to see one packet in plain text? would it be any reason for it? Thanks a lot for your help. Farid On Friday, October 18, 2013 9:08 AM, Farid Farid <[email protected]> wrote: Thanks Martin for the good detail. Yes that was the problem. It works with IKvE2. Best Regards, Farid On Thursday, October 17, 2013 11:49 PM, Martin Willi <[email protected]> wrote: Hi Farid, > I have observed if I select charonstat=yes and plutostart=no ipsec > is not listening in all interfaces With strongSwan 4.x, two IKE daemons have been in use. Pluto handled IKEv1 connections, while charon was responsible to handle IKEv2 connections. Both protocols receive messages on port 500/4500, but only one process can bind to it. As a work-around, charon used a RAW socket to receive packets, but did not bind to the UDP port. This allowed both daemons to receive packets for their protocol. > and it never receives any connection from outside. charon ignores IKEv1 packets, but it should receive packets for IKEv2. If you have IKEv1 connections, you'll need to start pluto. With 5.x releases, things have changed; charon now handles both IKEv1 and IKEv2 over a standard UDP socket, pluto is not required anymore. Regards Martin _______________________________________________ Users mailing list [email protected] <mailto:[email protected]> https://lists.strongswan.org/mailman/listinfo/users _______________________________________________ Users mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/users
-- ====================================================================== Andreas Steffen [email protected] strongSwan - the Open Source VPN Solution! www.strongswan.org Institute for Internet Technologies and Applications University of Applied Sciences Rapperswil CH-8640 Rapperswil (Switzerland) ===========================================================[ITA-HSR]==
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Users mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/users
