[strongSwan] IPSec -Charon versus Pluto

[Andreas Steffen]

Hi Farid,

no plaintext packets are transmitted! You only see decrypted payloads
on the inbound side because of the peculiar way tcpdump hooks into the
Linux 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 <farid21657 at yahoo.com>
> 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
> <martin at strongswan.org> 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
> Users at lists.strongswan.org <mailto:Users at lists.strongswan.org>
> https://lists.strongswan.org/mailman/listinfo/users
>
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.strongswan.org
> https://lists.strongswan.org/mailman/listinfo/users
>

-- 
======================================================================
Andreas Steffen                         andreas.steffen at strongswan.org
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]==

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4255 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.strongswan.org/pipermail/users/attachments/20131018/18ee14d4/attachment.bin>