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

Sun Nov 14 17:18:05 EST 2010

I would first suspect your rightsubnet clause.  I suspect that because
in my experience, limited though it is, when you see "no connection is
known for" in the logs, it means something in your config is not
describing your actual network situation.  If you move your roadwarrior
from NAT to non-NAT, your network situation changes, so the config may
no longer be in sync.
But its just a suspicion...

On Sun, 2010-11-14 at 21:41 +0100, Danilo Godec wrote:
> 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
> 
> _______________________________________________
> Users at openswan.org
> http://lists.openswan.org/mailman/listinfo/users
> Micropayments: https://flattr.com/thing/38387/IPsec-for-Linux-made-easy
> Building and Integrating Virtual Private Networks with Openswan: 
> http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155

Bob Miller
334-7117/660-5315
http://computerisms.ca
bob at computerisms.ca
Network, Internet, Server,
and Open Source Solutions