[Openswan Users] OpenSwan, L2TP and Windows - works if behind NAT, but not directly

[Danilo Godec]

 I just found out (well, one of my users did, actually) that since
upgrading OpenSwan from 2.4.x to 2.6.31, we cannot connect to OpenSwan
if we have a public IP address. In only works if we're behind NAT.


> conn l2tp-X.509
>         authby=rsasig
>         pfs=no
>         auto=add
>         rekey=no
>         ikelifetime=8h
>         keylife=1h
>         type=transport
>         #
>         left=MY_SERVERS_IP
>         leftid=%fromcert
>         leftrsasigkey=%cert
>         leftcert=/etc/ipsec.d/certs/lj.ibe.si.pem
>         leftprotoport=17/1701
>         #
>         # The remote user.
>         #
>         right=%any
>         rightca=%same
>         rightrsasigkey=%cert
>         # Using the magic port of "0" means "any one single port". This is
>         # a work around required for Apple OSX clients that use a randomly
>         # high port, but propose "0" instead of their port. If that does
>         # not work, try 17/%any
>         rightprotoport=17/%any
>         rightsubnet=vhost:%priv,%no
>
> conn passthrough-for-non-l2tp
>         type=passthrough
>         left=193.77.13.34
>         leftnexthop=193.77.13.33
>         right=0.0.0.0
>         rightsubnet=0.0.0.0/0
>         auto=route


Additionally, I have a 'virtual_private' line in my 'ipsec.conf' that
excludes the private IP ranges used behind server:

> virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%4:172.16.0.0/12,%v4:!172.16.11.0/16,%v4:!172.18.0.0/23

When the Windows client is using a public IP, this is what I get in logs:

> Nov 14 10:12:40 dioda pluto[4996]: "l2tp-X.509"[90] xxx.xxx.xxx.xxx
> #299: responding to Main Mode from unknown peer xxx.xxx.xxx.xxx
> Nov 14 10:12:40 dioda pluto[4996]: "l2tp-X.509"[90] xxx.xxx.xxx.xxx
> #299: OAKLEY_GROUP 20 not supported.  Attribute OAKLEY_GROUP_DESCRIPTION
> Nov 14 10:12:40 dioda pluto[4996]: "l2tp-X.509"[90] xxx.xxx.xxx.xxx
> #299: OAKLEY_GROUP 19 not supported.  Attribute OAKLEY_GROUP_DESCRIPTION
> Nov 14 10:12:40 dioda pluto[4996]: "l2tp-X.509"[90] xxx.xxx.xxx.xxx
> #299: transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
> Nov 14 10:12:40 dioda pluto[4996]: "l2tp-X.509"[90] xxx.xxx.xxx.xxx
> #299: STATE_MAIN_R1: sent MR1, expecting MI2
> Nov 14 10:12:40 dioda pluto[4996]: "l2tp-X.509"[90] xxx.xxx.xxx.xxx
> #299: NAT-Traversal: Result using RFC 3947 (NAT-Traversal): no NAT
> detected
> Nov 14 10:12:40 dioda pluto[4996]: "l2tp-X.509"[90] xxx.xxx.xxx.xxx
> #299: transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
> Nov 14 10:12:40 dioda pluto[4996]: "l2tp-X.509"[90] xxx.xxx.xxx.xxx
> #299: STATE_MAIN_R2: sent MR2, expecting MI3
> Nov 14 10:12:40 dioda pluto[4996]: "l2tp-X.509"[90] xxx.xxx.xxx.xxx
> #299: Main mode peer ID is ID_DER_ASN1_DN: 'xxxx CERT INFO xxxx''
> Nov 14 10:12:40 dioda pluto[4996]: "l2tp-X.509"[90] xxx.xxx.xxx.xxx
> #299: switched from "l2tp-X.509" to "l2tp-X.509"
> Nov 14 10:12:40 dioda pluto[4996]: "l2tp-X.509"[91] xxx.xxx.xxx.xxx
> #299: deleting connection "l2tp-X.509" instance with peer
> xxx.xxx.xxx.xxx {isakmp=#0/ipsec=#0}
> Nov 14 10:12:40 dioda pluto[4996]: "l2tp-X.509"[91] xxx.xxx.xxx.xxx
> #299: I am sending my cert
> Nov 14 10:12:41 dioda pluto[4996]: "l2tp-X.509"[91] xxx.xxx.xxx.xxx
> #299: transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
> Nov 14 10:12:41 dioda pluto[4996]: "l2tp-X.509"[91] xxx.xxx.xxx.xxx
> #299: STATE_MAIN_R3: sent MR3, ISAKMP SA established
> {auth=OAKLEY_RSA_SIG cipher=aes_256 prf=oakley_sha group=modp2048}
> Nov 14 10:12:41 dioda pluto[4996]: "l2tp-X.509"[91] xxx.xxx.xxx.xxx
> #299: the peer proposed: yyy.yyy.yyy.yyy/32:17/1701 ->
> xxx.xxx.xxx.xxx/32:17/0
> Nov 14 10:12:41 dioda pluto[4996]: "l2tp-X.509"[91] xxx.xxx.xxx.xxx
> #299: cannot respond to IPsec SA request because no connection is
> known for yyy.yyy.yyy.yyy<yyy.yyy.yyy.yyy>[xxxx CERT_INFO
> xxxx]:17/1701...xxx.xxx.xxx.xxx[xxxx CERT_INFO xxxx]:17/1701
> Nov 14 10:12:41 dioda pluto[4996]: "l2tp-X.509"[91] xxx.xxx.xxx.xxx
> #299: sending encrypted notification INVALID_ID_INFORMATION to
> xxx.xxx.xxx.xxx:500
> Nov 14 10:12:43 dioda pluto[4996]: "l2tp-X.509"[91] xxx.xxx.xxx.xxx
> #299: the peer proposed: yyy.yyy.yyy.yyy/32:17/1701 ->
> xxx.xxx.xxx.xxx/32:17/0
> Nov 14 10:12:43 dioda pluto[4996]: "l2tp-X.509"[91] xxx.xxx.xxx.xxx
> #299: cannot respond to IPsec SA request because no connection is
> known for yyy.yyy.yyy.yyy<yyy.yyy.yyy.yyy>[xxxx CERT_INFO
> xxxx]:17/1701...xxx.xxx.xxx.xxx[xxxx CERT_INFO xxxx]:17/1701
> Nov 14 10:12:43 dioda pluto[4996]: "l2tp-X.509"[91] xxx.xxx.xxx.xxx
> #299: sending encrypted notification INVALID_ID_INFORMATION to
> xxx.xxx.xxx.xxx:500
> Nov 14 10:12:45 dioda pluto[4996]: "l2tp-X.509"[91] xxx.xxx.xxx.xxx
> #299: the peer proposed: yyy.yyy.yyy.yyy/32:17/1701 ->
> xxx.xxx.xxx.xxx/32:17/0
> Nov 14 10:12:45 dioda pluto[4996]: "l2tp-X.509"[91] xxx.xxx.xxx.xxx
> #299: cannot respond to IPsec SA request because no connection is
> known for yyy.yyy.yyy.yyy<yyy.yyy.yyy.yyy>[xxxx CERT_INFO
> xxxx]:17/1701...xxx.xxx.xxx.xxx[xxxx CERT_INFO xxxx]:17/1701
> Nov 14 10:12:45 dioda pluto[4996]: "l2tp-X.509"[91] xxx.xxx.xxx.xxx
> #299: sending encrypted notification INVALID_ID_INFORMATION to
> xxx.xxx.xxx.xxx:500
> Nov 14 10:12:49 dioda pluto[4996]: "l2tp-X.509"[91] xxx.xxx.xxx.xxx
> #299: the peer proposed: yyy.yyy.yyy.yyy/32:17/1701 ->
> xxx.xxx.xxx.xxx/32:17/0
> Nov 14 10:12:49 dioda pluto[4996]: "l2tp-X.509"[91] xxx.xxx.xxx.xxx
> #299: cannot respond to IPsec SA request because no connection is
> known for yyy.yyy.yyy.yyy<yyy.yyy.yyy.yyy>[xxxx CERT_INFO
> xxxx]:17/1701...xxx.xxx.xxx.xxx[xxxx CERT_INFO xxxx]:17/1701
> Nov 14 10:12:49 dioda pluto[4996]: "l2tp-X.509"[91] xxx.xxx.xxx.xxx
> #299: sending encrypted notification INVALID_ID_INFORMATION to
> xxx.xxx.xxx.xxx:500
> Nov 14 10:12:57 dioda pluto[4996]: "l2tp-X.509"[91] xxx.xxx.xxx.xxx
> #299: the peer proposed: yyy.yyy.yyy.yyy/32:17/1701 ->
> xxx.xxx.xxx.xxx/32:17/0
> Nov 14 10:12:57 dioda pluto[4996]: "l2tp-X.509"[91] xxx.xxx.xxx.xxx
> #299: cannot respond to IPsec SA request because no connection is
> known for yyy.yyy.yyy.yyy<yyy.yyy.yyy.yyy>[xxxx CERT_INFO
> xxxx]:17/1701...xxx.xxx.xxx.xxx[xxxx CERT_INFO xxxx]:17/1701
> Nov 14 10:12:57 dioda pluto[4996]: "l2tp-X.509"[91] xxx.xxx.xxx.xxx
> #299: sending encrypted notification INVALID_ID_INFORMATION to
> xxx.xxx.xxx.xxx:500

When that same client computer is behind a home router / NAT, it works
as expected...

Could the 'passthrough-for-non-l2tp' part of the connection config be
the cause of that?


   Danilo