IKEv2 "TS_UNACCEPTABLE" error when behind a NAT

Discussion:

Hector Akamine

2009-11-30 09:37:49 UTC

Hello,

Is it possible to establish a host-to-host IPsec tunnel between two hosts
when one of them is behind a NAT? I have problems in the following configuration
(NAT device is a Corega broadband router, with "VPN passthrough" option enabled.
PC1 and PC2 are Fedora 11 boxes. StrongSwan version is 4.3.5)

(WAN) (LAN)
PC2(CF-W8) ------------- NAT router ---------------- PC1(CF-W7)
192.168.0.14 192.168.0.21 192.168.1.1 192.168.1.11

I configured PC1 and PC2 to set up a host-to-host IPsec tunnel using IKEv2,
but it fails (the IKE SA is established but the CHILD SA is not)
(certificates and keys are correct, since I can establish an IPsec connection
between the PCs when removing the NAT)

CF-W8 log (in /var/log/messages) shows:
traffic selectors 192.168.0.14/32 === 192.168.1.11/32 inacceptable
11[ENC] generating IKE_AUTH response 1 [ IDr CERT AUTH N(AUTH_LFT) N(MOBIKE_SUP)
N(ADD_6_ADDR) N(TS_UNACCEPT)

CF-W7 log (in /var/log/messages) shows:
received TS_UNACCEPTABLE notify, no CHILD_SA built

ipsec.conf in CF-W7:
--------------------
config setup
plutostart=no
conn host-host
left=%defaultroute
leftcert=cf-w7hostCert.pem
right=192.168.0.14
rightid="C=GB, ST=Berkshire, O=My Company Ltd"
auto=add
keyingtries=1
keyexchange=ikev2

ipsec.conf in CF-W8:
--------------------
config setup
plutostart=no
conn host-host
left=%defaultroute
leftcert=cf-w8hostCert.pem
right=192.168.0.21
rightid="C=GB, ST=Berkshire, O=My Company Ltd"
auto=add
keyingtries=1
keyexchange=ikev2

shell(in CF-W7) :
---------------

# ipsec start
Starting strongSwan 4.3.5 IPsec [starter]...

# ipsec up host-host
initiating IKE_SA host-host[1] to 192.168.0.14
generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ]
sending packet: from 192.168.1.11[500] to 192.168.0.14[500]
received packet: from 192.168.0.14[500] to 192.168.1.11[500]
parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ
N(MULT_AUTH) ]
local host is behind NAT, sending keep alives
received cert request for "C=GB, ST=Berkshire, L=Newbury, O=My Company Ltd"
sending cert request for "C=GB, ST=Berkshire, L=Newbury, O=My Company Ltd"
authentication of 'C=GB, ST=Berkshire, O=My Company Ltd' (myself) with RSA
signature successful
sending end entity cert "C=GB, ST=Berkshire, O=My Company Ltd"
establishing CHILD_SA host-host
generating IKE_AUTH request 1 [ IDi CERT CERTREQ IDr AUTH SA TSi TSr
N(MOBIKE_SUP) N(ADD_6_ADDR) N(MULT_AUTH) ]
sending packet: from 192.168.1.11[4500] to 192.168.0.14[4500]
received packet: from 192.168.0.14[4500] to 192.168.1.11[4500]
parsed IKE_AUTH response 1 [ IDr CERT AUTH N(AUTH_LFT) N(MOBIKE_SUP)
N(ADD_6_ADDR) N(TS_UNACCEPT) ]
received end entity cert "C=GB, ST=Berkshire, O=My Company Ltd"
using trusted ca certificate "C=GB, ST=Berkshire, L=Newbury, O=My Company Ltd"
checking certificate status of "C=GB, ST=Berkshire, O=My Company Ltd"
certificate status is not available
using trusted certificate "C=GB, ST=Berkshire, O=My Company Ltd"
signature validation failed, looking for another key
using certificate "C=GB, ST=Berkshire, O=My Company Ltd"
using trusted ca certificate "C=GB, ST=Berkshire, L=Newbury, O=My Company Ltd"
checking certificate status of "C=GB, ST=Berkshire, O=My Company Ltd"
certificate status is not available
authentication of 'C=GB, ST=Berkshire, O=My Company Ltd' with RSA signature
successful
IKE_SA host-host[1] established between 192.168.1.11[C=GB, ST=Berkshire, O=My
Company Ltd]...192.168.0.14[C=GB, ST=Berkshire, O=My Company Ltd]
scheduling reauthentication in 10126s
maximum IKE_SA lifetime 10666s
received TS_UNACCEPTABLE notify, no CHILD_SA built

# ipsec status
Security Associations:
host-host[1]: ESTABLISHED 9 seconds ago, 192.168.1.11[C=GB, ST=Berkshire,
O=My Company Ltd]...192.168.0.14[C=GB, ST=Berkshire, O=My Company Ltd]

Any hints on what can be wrong?

Thank you,
Hector

Daniel Mentz

2009-11-30 10:04:12 UTC

Permalink

Post by Hector Akamine
(WAN) (LAN)
PC2(CF-W8) ------------- NAT router ---------------- PC1(CF-W7)
192.168.0.14 192.168.0.21 192.168.1.1 192.168.1.11
I configured PC1 and PC2 to set up a host-to-host IPsec tunnel using IKEv2,
traffic selectors 192.168.0.14/32 === 192.168.1.11/32 inacceptable

Could you please try adding

rightsubnet=192.168.1.11/32

to ipsec.conf on CF-W8.

The problem is IMHO that CF-W7 thinks that it has IP address
192.168.1.11 whereas in the perception of CF-W8 CF-W7 has the IP
address 192.168.0.21.

Please get back to use with the result.
-Daniel

Martin Willi

2009-11-30 10:08:44 UTC

Permalink

Hi Hector,

Post by Hector Akamine
with "VPN passthrough" option enabled.

VPN passthrough is not needed, IKEv2 will use UDP encapsulation if a NAT
device is detected between your hosts.

Post by Hector Akamine
(WAN) (LAN)
PC2(CF-W8) ------------- NAT router ---------------- PC1(CF-W7)
192.168.0.14 192.168.0.21 192.168.1.1 192.168.1.11
traffic selectors 192.168.0.14/32 === 192.168.1.11/32 inacceptable

If you don't configure any traffic selectors, strongSwan will propose a
host-to-host tunnel between the local and the remote address. The
responder will expect the same.

PC2 expects a 192.168.0.14 === 192.168.0.21 tunnel, but PC1 proposes
192.168.0.14 === 192.168.1.11.

You could define the tunnel on PC2 by explicitly setting
rightsubnet=192.168.1.11/32 if you have statically assigned IP
addresses. If your addresses are more dynamic, you could define
rightsubnet=192.168.1.0/24 (or even 0.0.0.0/0) on PC2 and let strongSwan
narrow down the actual tunnel to what PC1 proposes. But then you'll have
to trust PC1, as it potentially could route any PC2 traffic through the
tunnel by proposing a larger traffic selector.

The most elegant solution is to assign virtual IP addresses from PC2 to
PC1 out of a pool. This will prevent address conflicts if you have
multiple clients behind different NATs and does not require you to trust
the clients.

Regards
Martin

Daniel Mentz

2009-11-30 19:13:22 UTC

Permalink

Post by Martin Willi

Post by Hector Akamine
with "VPN passthrough" option enabled.

VPN passthrough is not needed, IKEv2 will use UDP encapsulation if a NAT
device is detected between your hosts.

If I remember correctly I once had trouble with a router that explicitly
blocked traffic on UDP ports 500 and 4500 if VPN passthrough was disabled.
I recommend to try both settings: on and off.

Hector Akamine

2009-12-01 04:59:52 UTC

Permalink

Hi Daniel, Martin

Post by Daniel Mentz
Could you please try adding
rightsubnet=192.168.1.11/32
to ipsec.conf on CF-W8.
The problem is IMHO that CF-W7 thinks that it has IP address
192.168.1.11 whereas in the perception of CF-W8 CF-W7 has the IP
address 192.168.0.21.

Thanks! This made it work.

to summarize:

(WAN) (LAN)
PC2(CF-W8) ------------- NAT router ---------------- PC1(CF-W7)
192.168.0.14 192.168.0.21 192.168.1.1 192.168.1.11

ipsec.conf in CF-W7:
--------------------
config setup
plutostart=no
conn host-host
left=%defaultroute
leftcert=cf-w7hostCert.pem
right=192.168.0.14
rightid="C=GB, ST=Berkshire, O=My Company Ltd"
auto=add
keyingtries=1
keyexchange=ikev2

ipsec.conf in CF-W8:
--------------------
config setup
plutostart=no
conn host-host
left=%defaultroute
leftcert=cf-w8hostCert.pem
right=192.168.0.21
rightsubnet=192.168.1.11/32
rightid="C=GB, ST=Berkshire, O=My Company Ltd"
auto=add
keyingtries=1
keyexchange=ikev2

- "ipsec up host-host" must be done from the LAN side (CF-W7), in order to
create the NAT mapping used for UDP encapsulated IPsec packets.
- As an (obvious?) effect, I am able to access CF-W7 from
CF-W8 (that is, from WAN to LAN), since NAT keepalives are periodically sent
from CF-W7 to CF-W8 to "keep alive" the port mapping used by IPsec packets.
If I not were using the VPN, I would normally require to set the router for
accessing a host in the LAN from the WAN.

Post by Daniel Mentz

Post by Martin Willi
VPN passthrough is not needed, IKEv2 will use UDP encapsulation if a NAT
device is detected between your hosts.

If I remember correctly I once had trouble with a router that explicitly
blocked traffic on UDP ports 500 and 4500 if VPN passthrough was disabled.

I do need to enable VPN passthrough at least in this particular router,
if VPN passthrough is disabled, the router blocks UDP traffic and the
VPN can't be set up.

Thank you,
Hector

Daniel Mentz

2009-12-01 09:58:02 UTC

Permalink

Post by Hector Akamine
(WAN) (LAN)
PC2(CF-W8) ------------- NAT router ---------------- PC1(CF-W7)
192.168.0.14 192.168.0.21 192.168.1.1 192.168.1.11
- "ipsec up host-host" must be done from the LAN side (CF-W7), in order to
create the NAT mapping used for UDP encapsulated IPsec packets.

Hi Hector,

why not set up a port forwarding rule on the NAT router so that packets
arriving on the WAN port destined for 192.168.0.21 UDP port 500 or 4500
are mapped to 192.168.1.11.

Post by Hector Akamine
- As an (obvious?) effect, I am able to access CF-W7 from
CF-W8 (that is, from WAN to LAN), since NAT keepalives are periodically sent
from CF-W7 to CF-W8 to "keep alive" the port mapping used by IPsec packets.
If I not were using the VPN, I would normally require to set the router for
accessing a host in the LAN from the WAN.

That is the reason why you set up a VPN, isn't it? You have a virtual
private network that connects CF-W8 and CF-W7. So it goes without saying
that you can access CF-W7 from CF-W8.

Post by Hector Akamine

Post by Daniel Mentz

Post by Martin Willi
VPN passthrough is not needed, IKEv2 will use UDP encapsulation if a NAT
device is detected between your hosts.

If I remember correctly I once had trouble with a router that explicitly
blocked traffic on UDP ports 500 and 4500 if VPN passthrough was disabled.

I do need to enable VPN passthrough at least in this particular router,
if VPN passthrough is disabled, the router blocks UDP traffic and the
VPN can't be set up.

Thank you for this information. I put the following on record:

VPN passthrough is counterproductive and does more harm than good.

-Daniel

Hector Akamine

2009-12-01 14:31:04 UTC

Permalink

Hi Daniel,

Post by Martin Willi

Hi Hector,
why not set up a port forwarding rule on the NAT router so that packets
arriving on the WAN port destined for 192.168.0.21 UDP port 500 or 4500
are mapped to 192.168.1.11.

Of course, that would make an exchange starting from PC2 work. I just wanted to
say that in that particular scenario (eg., an unconfigured router of a typical
home user) the exchange should start from the LAN side (I realize it is so
obvious I shouldn't have written it in the first place...).

Post by Martin Willi

Post by Hector Akamine
I do need to enable VPN passthrough at least in this particular router,
if VPN passthrough is disabled, the router blocks UDP traffic and the
VPN can't be set up.

VPN passthrough is counterproductive and does more harm than good.

I think it is just a way to make consumer-grade equipment more "user-friendly".
For a normal home user, it is easier to follow "turn VPN passthrough on", than
"open UDP ports 500 and 4500 of your router in order to use a VPN".

Thanks,
Hector