search

xelerance / Openswan

Openswan
Other
852 stars 214 forks source link

Openswan behind NAT problem (only after 2.6.37) #116

Open mixman68 opened 9 years ago

mixman68 commented 9 years ago

Hello, i have multiple NAT for attack my openswan server :+1: 10.0.1.201(my server) <> WAN Adress 1 <------> WAN Client1 <> Client1( 192.168.1.10)

Openswan crash after upgrade to 2.6.38 or later, downgrade to 2.6.37 resolve problem

On OpenSwan 2.6.37 : 

Mar  4 17:38:09 DHCP pluto[1528]: packet from 109.221.173.1:500: received Vendor ID payload [RFC 3947] method set to=109 
Mar  4 17:38:09 DHCP pluto[1528]: packet from 109.221.173.1:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike] method set to=110 
Mar  4 17:38:09 DHCP pluto[1528]: packet from 109.221.173.1:500: ignoring unknown Vendor ID payload [8f8d83826d246b6fc7a8a6a428c11de8]
Mar  4 17:38:09 DHCP pluto[1528]: packet from 109.221.173.1:500: ignoring unknown Vendor ID payload [439b59f8ba676c4c7737ae22eab8f582]
Mar  4 17:38:09 DHCP pluto[1528]: packet from 109.221.173.1:500: ignoring unknown Vendor ID payload [4d1e0e136deafa34c4f3ea9f02ec7285]
Mar  4 17:38:09 DHCP pluto[1528]: packet from 109.221.173.1:500: ignoring unknown Vendor ID payload [80d0bb3def54565ee84645d4c85ce3ee]
Mar  4 17:38:09 DHCP pluto[1528]: packet from 109.221.173.1:500: ignoring unknown Vendor ID payload [9909b64eed937c6573de52ace952fa6b]
Mar  4 17:38:09 DHCP pluto[1528]: packet from 109.221.173.1:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03] meth=108, but already using method 110
Mar  4 17:38:09 DHCP pluto[1528]: packet from 109.221.173.1:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02] meth=107, but already using method 110
Mar  4 17:38:09 DHCP pluto[1528]: packet from 109.221.173.1:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] meth=106, but already using method 110
Mar  4 17:38:09 DHCP pluto[1528]: packet from 109.221.173.1:500: ignoring Vendor ID payload [FRAGMENTATION 80000000]
Mar  4 17:38:09 DHCP pluto[1528]: packet from 109.221.173.1:500: received Vendor ID payload [Dead Peer Detection]
Mar  4 17:38:09 DHCP pluto[1528]: "L2TP-PSK-NAT"[1] 109.221.173.1 #1: responding to Main Mode from unknown peer 109.221.173.1
Mar  4 17:38:09 DHCP pluto[1528]: "L2TP-PSK-NAT"[1] 109.221.173.1 #1: transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
Mar  4 17:38:09 DHCP pluto[1528]: "L2TP-PSK-NAT"[1] 109.221.173.1 #1: STATE_MAIN_R1: sent MR1, expecting MI2
Mar  4 17:38:09 DHCP pluto[1528]: "L2TP-PSK-NAT"[1] 109.221.173.1 #1: NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike (MacOS X): both are NATed
Mar  4 17:38:09 DHCP pluto[1528]: "L2TP-PSK-NAT"[1] 109.221.173.1 #1: transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
Mar  4 17:38:09 DHCP pluto[1528]: "L2TP-PSK-NAT"[1] 109.221.173.1 #1: STATE_MAIN_R2: sent MR2, expecting MI3
Mar  4 17:38:09 DHCP pluto[1528]: "L2TP-PSK-NAT"[1] 109.221.173.1 #1: ignoring informational payload, type IPSEC_INITIAL_CONTACT msgid=00000000
Mar  4 17:38:09 DHCP pluto[1528]: "L2TP-PSK-NAT"[1] 109.221.173.1 #1: Main mode peer ID is ID_IPV4_ADDR: '192.168.1.18'
Mar  4 17:38:09 DHCP pluto[1528]: "L2TP-PSK-NAT"[1] 109.221.173.1 #1: switched from "L2TP-PSK-NAT" to "L2TP-PSK-NAT"
Mar  4 17:38:09 DHCP pluto[1528]: "L2TP-PSK-NAT"[2] 109.221.173.1 #1: deleting connection "L2TP-PSK-NAT" instance with peer 109.221.173.1 {isakmp=#0/ipsec=#0}
Mar  4 17:38:09 DHCP pluto[1528]: "L2TP-PSK-NAT"[2] 109.221.173.1 #1: transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
Mar  4 17:38:09 DHCP pluto[1528]: "L2TP-PSK-NAT"[2] 109.221.173.1 #1: new NAT mapping for #1, was 109.221.173.1:500, now 109.221.173.1:4500
Mar  4 17:38:09 DHCP pluto[1528]: "L2TP-PSK-NAT"[2] 109.221.173.1 #1: STATE_MAIN_R3: sent MR3, ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cipher=aes_256 prf=oakley_sha group=modp1024}
Mar  4 17:38:09 DHCP pluto[1528]: "L2TP-PSK-NAT"[2] 109.221.173.1 #1: Dead Peer Detection (RFC 3706): enabled
Mar  4 17:38:10 DHCP pluto[1528]: "L2TP-PSK-NAT"[2] 109.221.173.1 #1: Applying workaround for Mac OS X NAT-OA bug, ignoring proposed subnet
Mar  4 17:38:10 DHCP pluto[1528]: "L2TP-PSK-NAT"[2] 109.221.173.1 #1: the peer proposed: 62.210.127.211/32:17/1701 -> 109.221.173.1/32:17/0
Mar  4 17:38:10 DHCP pluto[1528]: "L2TP-PSK-NAT"[2] 109.221.173.1 #2: responding to Quick Mode proposal {msgid:55d80291}
Mar  4 17:38:10 DHCP pluto[1528]: "L2TP-PSK-NAT"[2] 109.221.173.1 #2:     us: 10.0.1.201<10.0.1.201>[+S=C]:17/1701---10.0.1.1
Mar  4 17:38:10 DHCP pluto[1528]: "L2TP-PSK-NAT"[2] 109.221.173.1 #2:   them: 109.221.173.1[192.168.1.18,+S=C]:17/58317
Mar  4 17:38:10 DHCP pluto[1528]: "L2TP-PSK-NAT"[2] 109.221.173.1 #2: transition from state STATE_QUICK_R0 to state STATE_QUICK_R1
Mar  4 17:38:10 DHCP pluto[1528]: "L2TP-PSK-NAT"[2] 109.221.173.1 #2: STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2
Mar  4 17:38:10 DHCP pluto[1528]: "L2TP-PSK-NAT"[2] 109.221.173.1 #2: Dead Peer Detection (RFC 3706): enabled
Mar  4 17:38:10 DHCP pluto[1528]: "L2TP-PSK-NAT"[2] 109.221.173.1 #2: transition from state STATE_QUICK_R1 to state STATE_QUICK_R2
Mar  4 17:38:10 DHCP pluto[1528]: "L2TP-PSK-NAT"[2] 109.221.173.1 #2: STATE_QUICK_R2: IPsec SA established transport mode {ESP=>0x0bc96274 <0x6ef7c556 xfrm=AES_256-HMAC_SHA1 NATOA=none NATD=109.221.173.1:4500 DPD=enabled}

On OpenSwan 2.6.38 :

Mar  4 17:34:17 DHCP pluto[1381]: packet from 109.221.173.1:500: received Vendor ID payload [RFC 3947] method set to=115 
Mar  4 17:34:17 DHCP pluto[1381]: packet from 109.221.173.1:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike] meth=114, but already using method 115
Mar  4 17:34:17 DHCP pluto[1381]: packet from 109.221.173.1:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-08] meth=113, but already using method 115
Mar  4 17:34:17 DHCP pluto[1381]: packet from 109.221.173.1:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-07] meth=112, but already using method 115
Mar  4 17:34:17 DHCP pluto[1381]: packet from 109.221.173.1:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-06] meth=111, but already using method 115
Mar  4 17:34:17 DHCP pluto[1381]: packet from 109.221.173.1:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-05] meth=110, but already using method 115
Mar  4 17:34:17 DHCP pluto[1381]: packet from 109.221.173.1:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-04] meth=109, but already using method 115
Mar  4 17:34:17 DHCP pluto[1381]: packet from 109.221.173.1:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03] meth=108, but already using method 115
Mar  4 17:34:17 DHCP pluto[1381]: packet from 109.221.173.1:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02] meth=107, but already using method 115
Mar  4 17:34:17 DHCP pluto[1381]: packet from 109.221.173.1:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] meth=106, but already using method 115
Mar  4 17:34:17 DHCP pluto[1381]: packet from 109.221.173.1:500: ignoring Vendor ID payload [FRAGMENTATION 80000000]
Mar  4 17:34:17 DHCP pluto[1381]: packet from 109.221.173.1:500: received Vendor ID payload [Dead Peer Detection]
Mar  4 17:34:17 DHCP pluto[1381]: "L2TP-PSK-NAT"[3] 109.221.173.1 #3: responding to Main Mode from unknown peer 109.221.173.1
Mar  4 17:34:17 DHCP pluto[1381]: "L2TP-PSK-NAT"[3] 109.221.173.1 #3: transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
Mar  4 17:34:17 DHCP pluto[1381]: "L2TP-PSK-NAT"[3] 109.221.173.1 #3: STATE_MAIN_R1: sent MR1, expecting MI2
Mar  4 17:34:17 DHCP pluto[1381]: "L2TP-PSK-NAT"[3] 109.221.173.1 #3: NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike (MacOS X): both are NATed
Mar  4 17:34:17 DHCP pluto[1381]: "L2TP-PSK-NAT"[3] 109.221.173.1 #3: transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
Mar  4 17:34:17 DHCP pluto[1381]: "L2TP-PSK-NAT"[3] 109.221.173.1 #3: STATE_MAIN_R2: sent MR2, expecting MI3
Mar  4 17:34:17 DHCP pluto[1381]: "L2TP-PSK-NAT"[3] 109.221.173.1 #3: ignoring informational payload, type IPSEC_INITIAL_CONTACT msgid=00000000
Mar  4 17:34:17 DHCP pluto[1381]: "L2TP-PSK-NAT"[3] 109.221.173.1 #3: Main mode peer ID is ID_IPV4_ADDR: '192.168.1.18'
Mar  4 17:34:17 DHCP pluto[1381]: "L2TP-PSK-NAT"[3] 109.221.173.1 #3: switched from "L2TP-PSK-NAT" to "L2TP-PSK-NAT"
Mar  4 17:34:17 DHCP pluto[1381]: "L2TP-PSK-NAT"[4] 109.221.173.1 #3: deleting connection "L2TP-PSK-NAT" instance with peer 109.221.173.1 {isakmp=#0/ipsec=#0}
Mar  4 17:34:17 DHCP pluto[1381]: "L2TP-PSK-NAT"[4] 109.221.173.1 #3: transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
Mar  4 17:34:17 DHCP pluto[1381]: "L2TP-PSK-NAT"[4] 109.221.173.1 #3: new NAT mapping for #3, was 109.221.173.1:500, now 109.221.173.1:4500
Mar  4 17:34:17 DHCP pluto[1381]: "L2TP-PSK-NAT"[4] 109.221.173.1 #3: STATE_MAIN_R3: sent MR3, ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cipher=aes_256 prf=oakley_sha group=modp1024}
Mar  4 17:34:17 DHCP pluto[1381]: "L2TP-PSK-NAT"[4] 109.221.173.1 #3: Dead Peer Detection (RFC 3706): enabled
Mar  4 17:34:18 DHCP pluto[1381]: "L2TP-PSK-NAT"[4] 109.221.173.1 #3: the peer proposed: 62.210.127.211/32:17/1701 -> 192.168.1.18/32:17/0
Mar  4 17:34:18 DHCP pluto[1381]: "L2TP-PSK-NAT"[4] 109.221.173.1 #3: NAT-Traversal: received 2 NAT-OA. using first, ignoring others
Mar  4 17:34:18 DHCP pluto[1381]: "L2TP-PSK-NAT"[4] 109.221.173.1 #4: responding to Quick Mode proposal {msgid:da98c9fd}
Mar  4 17:34:18 DHCP pluto[1381]: "L2TP-PSK-NAT"[4] 109.221.173.1 #4:     us: 10.0.1.201<10.0.1.201>:17/1701---10.0.1.1
Mar  4 17:34:18 DHCP pluto[1381]: "L2TP-PSK-NAT"[4] 109.221.173.1 #4:   them: 109.221.173.1[192.168.1.18]:17/58376===192.168.1.18/32
Mar  4 17:34:18 DHCP pluto[1381]: "L2TP-PSK-NAT"[4] 109.221.173.1 #4: transition from state STATE_QUICK_R0 to state STATE_QUICK_R1
Mar  4 17:34:18 DHCP pluto[1381]: "L2TP-PSK-NAT"[4] 109.221.173.1 #4: STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2
Mar  4 17:34:18 DHCP pluto[1381]: "L2TP-PSK-NAT"[4] 109.221.173.1 #4: Dead Peer Detection (RFC 3706): enabled
Mar  4 17:34:18 DHCP pluto[1381]: "L2TP-PSK-NAT"[4] 109.221.173.1 #4: transition from state STATE_QUICK_R1 to state STATE_QUICK_R2
Mar  4 17:34:18 DHCP pluto[1381]: "L2TP-PSK-NAT"[4] 109.221.173.1 #4: STATE_QUICK_R2: IPsec SA established transport mode {ESP=>0x0fb072ef <0xc19dc813 xfrm=AES_256-HMAC_SHA1 NATOA=192.168.1.18 NATD=109.221.173.1:4500 DPD=enabled}
Mar  4 17:34:38 DHCP pluto[1381]: "L2TP-PSK-NAT"[4] 109.221.173.1 #3: received Delete SA(0x0fb072ef) payload: deleting IPSEC State #4
Mar  4 17:34:38 DHCP pluto[1381]: "L2TP-PSK-NAT"[4] 109.221.173.1 #3: ERROR: netlink XFRM_MSG_DELPOLICY response for flow eroute_connection delete included errno 2: No such file or directory
Mar  4 17:34:38 DHCP pluto[1381]: "L2TP-PSK-NAT"[4] 109.221.173.1 #3: received and ignored informational message
Mar  4 17:34:38 DHCP pluto[1381]: "L2TP-PSK-NAT"[4] 109.221.173.1 #3: received Delete SA payload: deleting ISAKMP State #3
Mar  4 17:34:38 DHCP pluto[1381]: "L2TP-PSK-NAT"[4] 109.221.173.1: deleting connection "L2TP-PSK-NAT" instance with peer 109.221.173.1 {isakmp=#0/ipsec=#0}
Mar  4 17:34:38 DHCP pluto[1381]: packet from 109.221.173.1:4500: received and ignored informational message
letoams commented 9 years ago

On Wed, 4 Mar 2015, djgreg13 wrote:

Hello, i have multiple NAT for attack my openswan server :+1: 10.0.1.201(my server) <> WAN Adress 1 <------> WAN Client1 <> Client1( 192.168.1.10)

Openswan crash after upgrade to 2.6.38 or later, downgrade to 2.6.37 resolve problem

it does not actually crash but it looks like what you see is the bad patch to the old/new style NAT-T detection that was added to openswan. So packet flow fails and the remote sends you a delete to hang up.

The broken patch was introduced by Simon

Paul

simondeziel commented 9 years ago

With 2.6.38, the OSX client proposal of using 192.168.1.18/32 as the remote subnet was accepted while it was previously ignored as bogus in 2.6.37.

This change in behaviour was introduced by commit b44418272c1fbd686cb4e7ca860494664270a04b

Could you tell us the OS X/iOS version that is ran by the client?

letoams commented 9 years ago

in both cases the connection establishes - nothing is rejected as bogus in either 2.6.37 or 2.6.38.

The pointed to commit is not the problem. The problem is most likely https://github.com/xelerance/Openswan/commit/3eb39709ac9dd78534f96e57204514bf22e69937

simondeziel commented 9 years ago

I assumed you were referring to that commit but since it's not part of 2.6.38 I started looking elsewhere.

The timing between the established IPsec SA (17:34:18) and the delete message (17:34:38) could indicate that the L2TP client was unhappy and hung up.

letoams commented 9 years ago

months ago i tested your patch to the nat style detection and it broke all NAT'ed clients. You can try it in one of your test cases. This has nothing to do with L2TP

simondeziel commented 9 years ago

I'm not debating if my patch is good or bad, I'm just saying that it can hardly be it because it is not part of 2.6.38. That said, my patch seems to pass our automated test suite but that doesn't involve clients that are not OSW.

Of course, before including it in a stable release, we'll test it with iPhone/OSX clients.

letoams commented 9 years ago

On Wed, 4 Mar 2015, Simon Deziel wrote:

I'm not debating if my patch is good or bad, I'm just saying that it can hardly be it because it is not part of 2.6.38. That said, my patch seems to pass our automated test suite but that doesn't involve clients that are not OSW.

At the time I ran openswan-klips + openswan-userland through our NAT test and it failed to interop with itself. Perhaps results are different if you were on < 2.6.23 kernels.

mixman68 commented 9 years ago

I run latest version of OSX and 8.1.3 for iOS

I will test ta evening with a fortigate 60

Gregory G

Le 5 mars 2015 à 00:04, Paul Wouters (libreswan) notifications@github.com a écrit :

On Wed, 4 Mar 2015, Simon Deziel wrote:

I'm not debating if my patch is good or bad, I'm just saying that it can hardly be it because it is not part of 2.6.38. That said, my patch seems to pass our automated test suite but that doesn't involve clients that are not OSW.

At the time I ran openswan-klips + openswan-userland through our NAT test and it failed to interop with itself. Perhaps results are different if you were on < 2.6.23 kernels.

— Reply to this email directly or view it on GitHub.

letoams commented 9 years ago

Libreswan-3.12 should work as a drop in replacement too

Sent from my iPhone

On Mar 5, 2015, at 01:10, djgreg13 notifications@github.com wrote:

I run latest version of OSX and 8.1.3 for iOS

I will test ta evening with a fortigate 60

Gregory G

Le 5 mars 2015 à 00:04, Paul Wouters (libreswan) notifications@github.com a écrit :

On Wed, 4 Mar 2015, Simon Deziel wrote:

I'm not debating if my patch is good or bad, I'm just saying that it can hardly be it because it is not part of 2.6.38. That said, my patch seems to pass our automated test suite but that doesn't involve clients that are not OSW.

At the time I ran openswan-klips + openswan-userland through our NAT test and it failed to interop with itself. Perhaps results are different if you were on < 2.6.23 kernels.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub.

mixman68 commented 9 years ago

Libreswan works fine, switch to this fork while openswan not working

2015-03-05 7:44 GMT+01:00 Paul Wouters (libreswan) <notifications@github.com

:

Libreswan-3.12 should work as a drop in replacement too

Sent from my iPhone

On Mar 5, 2015, at 01:10, djgreg13 notifications@github.com wrote:

I run latest version of OSX and 8.1.3 for iOS

I will test ta evening with a fortigate 60

Gregory G

Le 5 mars 2015 à 00:04, Paul Wouters (libreswan) < notifications@github.com> a écrit :

On Wed, 4 Mar 2015, Simon Deziel wrote:

I'm not debating if my patch is good or bad, I'm just saying that it can hardly be it because it is not part of 2.6.38. That said, my patch seems to pass our automated test suite but that doesn't involve clients that are not OSW.

At the time I ran openswan-klips + openswan-userland through our NAT test and it failed to interop with itself. Perhaps results are different if you were on < 2.6.23 kernels.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub https://github.com/xelerance/Openswan/issues/116#issuecomment-77315168.

simondeziel commented 9 years ago

To the OP, were you able to test OpenSwan releases that were newer? Something like 2.6.42 or even 2.6.43-rc1?

Paul, thanks for pointing the problem with KLIPS and my patch, we'll make sure to look into this during QA. As for our testing, we don't test with such old kernels; 2.6.32 is the oldest kernel we test with.

mixman68 commented 9 years ago

At the future maintenance, i use open(libre)swan under production environment, and we don't have development environment

wenbozzz commented 8 years ago

I got the same problem here. I am trying to build a L2TP server on ubuntu 14.4.1. So far, I have tested openswan: version 2.6.38 and before: Android 6.0: unable to connect, (stuck at " STATE_QUICK_R2: IPsec SA established transport mode" and eventually connection timed out)

version 2.6.43: Android 6.0: IT WORKED !!! mac OS 10.11.2 unable to connect (keep getting "received and ignored informational message") Windows 10: unable to connect (keep getting "received and ignored informational message")

version 2.6.44-UNSTABLE: Android 6.0: unable to connect, (keep getting "received and ignored informational message") mac OS 10.11.2 unable to connect, (keep getting "received and ignored informational message") Windows 10: unable to connect (keep getting "received and ignored informational message")