[strongSwan-dev] Tunnel mode failed for a NATted desktop client at phase1

[Ben Zhu]

Hi Andreas and others,

I am testing my VPN with a NATed Client and a server.

Here are settings:
1. Server side:
The server is installed with Strongswan 4.6.4 and its IP address is 192.155.8167.
# server ipsec.conf
config setup
        plutostart=yes
        nat_traversal=yes
        uniqueids=no

conn nat-desktop
         keyexchange=ikev1
         forceencaps=yes
         authby=xauthrsasig
         xauth=server
         left=192.155.81.67
         leftid=server
         leftcert=serverCert.pem
         leftfirewall=yes
         right=%any
         rightid=@client
         rightcert=clientCert.pem
         rightsourceip=10.1.0.0/16
         auto=add

2. Client side:
Client is a linux guest VM. Its IP addess is 10.0.2.15 and NATted to its Windows host.
The guest VM is installed with Strongswan 5.0.4 and has the following ipsec settings:
 
# client ipsec.conf

config setup

ca testca
     cacert=caCert.pem
     auto=add

conn %default
         ikelifetime=60m
         keylife=20m
         rekeymargin=3m
         keyingtries=1
         keyexchange=ikev1
         forceencaps=yes

con nat-desktop
         left=10.0.2.15
         leftsubnet=0.0.0.0/0
         leftid=client
         leftcert=clientCert.pem
         leftfirewall=yes
         right=192.155.81.67
         rightsubnet=10.1.0.0/16
         rightid=@server
         rightcert=serverCert.pem
         authby=xauthrsasig
         xauth=client
         xauth_identity=testvpn
         auto=start

My issue is:
The IKE negotiation was passed phase 1 but failed at phase 2 - Quick Mode INIT.

Here are log messages I got:

...
peer client is 10.1.0.1
| peer client protocol/port is 0/0
| our client is 192.155.81.67
| our client protocol/port is 0/0
| no valid attribute cert found
| find_client_connection starting with nat-desktop
|   looking for 192.155.81.67/32:0/0 -> 10.1.0.1/32:0/0
|   concrete checking against sr#0 192.0.0.0/8 -> 10.1.0.1/32
|   fc_try trying nat-desktop:192.155.81.67/32:0/0 -> 10.1.0.1/32:0/0 vs nat-desktop:192.0.0.0/8:0/0 -> 10.1.0.1/32:0/0
|   fc_try concluding with none [0]
|   fc_try nat-desktop gives none
|   checking hostpair 192.0.0.0/8 -> 10.1.0.1/32 is found
|   fc_try trying nat-desktop:192.155.81.67/32:0/0 -> 10.1.0.1/32:0/0 vs nat-desktop:192.0.0.0/8:0/0 -> 10.1.0.0/32:0/0
|   fc_try concluding with none [0]
|   fc_try_oppo trying nat-desktop:192.155.81.67/32 -> 10.1.0.1/32 vs nat-desktop:192.0.0.0/8 -> 10.1.0.0/32
|   fc_try_oppo concluding with none [0]
|   concluding with d = none
"nat-desktop"[1] 209.116.40.70:58646 #1: cannot respond to IPsec SA request because no connection is known for 192.155.81.67:4500[server]...209.116.40.70:58646[client]===10.1.0.1/32
"nat-desktop"[1] 209.116.40.70:58646 #1: sending encrypted notification INVALID_ID_INFORMATION to 209.116.40.70:58646
...

I have noticed:
at server side, the packages show the server directly talked to a machine with IP address 209.11.40.70 at port 58646 instead of the real client 10.0.2.15 at 500/4500.
at client side, the packages show the client talked to the server (192.155.81.67) at port 500/4500.

It seems the machine 209.116.40.70 is viewed as the real client and it intercepted IKE negotiation between the client and the server. 
the other thing is the log messages show the network masks are different from what I set in ipsec.con file.

My questions are:
1. if my settings correct for a NATted connection?
2. if yes, what can cause this issue?
3. if not, how I can fix this issue?


Thanks a lot,
Ben