[Openswan Users] Openswan gateway behind NAT

Marcus Better marcus at better.se
Sun Jan 9 22:17:03 CET 2005


Hello,

I have a problem reaching hosts behind an Openswan gateway which is 
behind NAT. I suspect that it may be a NAT-T problem since otherwise the
setup is quite ordinary.

My internal network is 192.168.1.0/24. I have the following hosts:

gw.example.com			D-link router (Internet side)
192.168.1.1    			D-link router (LAN side)
192.168.1.2    			Openswan gateway (responder)
                  (Fedora Core 3, Openswan U2.3.0dr5/K2.6.9-1.667)
83.227.75.174			Openswan client (initiator)
		 (Debian testing, i386, openswan 2.2.0-4).

The router is configured to pass all incoming traffic to the gateway
192.168.1.2, which has only one Ethernet interface.

The IPsec connection is host-to-subnet. I get an IPsec connection, and
the client can talk to the gateway (192.168.1.2) without problems.
However the client cannot reach other hosts on the 192.168.1 subnet.

If I ping for example 192.168.1.3 from the client, I can see the packets
reaching the IPsec gateway, but nothing is sent to 192.168.1.3.

Here is the log output on the gateway (192.168.1.2) when I connect:
-------------------------------------------------------------------------
Jan  7 09:43:09 kakmonster pluto[25485]: packet from 83.227.75.174:500:
received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03] method set to=108
Jan  7 09:43:09 kakmonster pluto[25485]: packet from 83.227.75.174:500:
received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02] meth=107, but
already using method 108
Jan  7 09:43:09 kakmonster pluto[25485]: packet from 83.227.75.174:500:
received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-00]
Jan  7 09:43:09 kakmonster pluto[25485]: "rw"[7] 83.227.75.174 #18:
responding to Main Mode from unknown peer 83.227.75.174
Jan  7 09:43:09 kakmonster pluto[25485]: "rw"[7] 83.227.75.174 #18:
transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
Jan  7 09:43:09 kakmonster pluto[25485]: "rw"[7] 83.227.75.174 #18:
NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike-02/03: i am NATed
Jan  7 09:43:09 kakmonster pluto[25485]: "rw"[7] 83.227.75.174 #18:
transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
Jan  7 09:43:09 kakmonster pluto[25485]: "rw"[7] 83.227.75.174 #18: Main
mode peer ID is ID_USER_FQDN: 'marcus at example.com'
Jan  7 09:43:09 kakmonster pluto[25485]: "rw"[7] 83.227.75.174 #18: no
crl from issuer "C=SE, O=Example.com, CN=Development CA" found (strict=no)
Jan  7 09:43:09 kakmonster pluto[25485]: "rw"[7] 83.227.75.174 #18: I am
sending my cert
Jan  7 09:43:09 kakmonster pluto[25485]: "rw"[7] 83.227.75.174 #18:
transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
Jan  7 09:43:09 kakmonster pluto[25485]: | NAT-T: new mapping
83.227.75.174:500/4500)
Jan  7 09:43:09 kakmonster pluto[25485]: "rw"[7] 83.227.75.174:4500 #18:
sent MR3, ISAKMP SA established
Jan  7 09:43:09 kakmonster pluto[25485]: "rw"[7] 83.227.75.174:4500 #19:
responding to Quick Mode
Jan  7 09:43:09 kakmonster pluto[25485]: "rw"[7] 83.227.75.174:4500 #19:
transition from state STATE_QUICK_R0 to state STATE_QUICK_R1
Jan  7 09:43:10 kakmonster pluto[25485]: "rw"[7] 83.227.75.174:4500 #19:
transition from state STATE_QUICK_R1 to state STATE_QUICK_R2
Jan  7 09:43:10 kakmonster pluto[25485]: "rw"[7] 83.227.75.174:4500 #19:
IPsec SA established {ESP/NAT=>0xcf2592ad <0x8710af63 NATOA=0.0.0.0}
-----------------------------------------------------------------------

And here is the log output on the client:
-----------------------------------------------------------------------
Jan  7 09:45:37 thales pluto[3088]: "dac" #1: initiating Main Mode
Jan  7 09:45:37 thales pluto[3088]: "dac" #1: received Vendor ID payload
[Dead Peer Detection]
Jan  7 09:45:37 thales pluto[3088]: "dac" #1: received Vendor ID payload
[draft-ietf-ipsec-nat-t-ike-03]
Jan  7 09:45:37 thales pluto[3088]: "dac" #1: enabling possible
NAT-traversal with method RFC XXXX (NAT-Traversal)
Jan  7 09:45:38 thales pluto[3088]: "dac" #1: transition from state
STATE_MAIN_I1 to state STATE_MAIN_I2
Jan  7 09:45:38 thales pluto[3088]: "dac" #1: NAT-Traversal: Result
using draft-ietf-ipsec-nat-t-ike-02/03: peer is NATed
Jan  7 09:45:38 thales pluto[3088]: "dac" #1: I am sending my cert
Jan  7 09:45:38 thales pluto[3088]: "dac" #1: I am sending a certificate
request
Jan  7 09:45:38 thales pluto[3088]: "dac" #1: transition from state
STATE_MAIN_I2 to state STATE_MAIN_I3
Jan  7 09:45:38 thales pluto[3088]: "dac" #1: Peer ID is ID_FQDN:
'@*.dactylis.com'
Jan  7 09:45:38 thales pluto[3088]: "dac" #1: no crl from issuer "C=SE,
O=Example.com, CN=Development CA" found (strict=no)
Jan  7 09:45:38 thales pluto[3088]: "dac" #1: transition from state
STATE_MAIN_I3 to state STATE_MAIN_I4
Jan  7 09:45:38 thales pluto[3088]: "dac" #1: ISAKMP SA established
Jan  7 09:45:38 thales pluto[3088]: "dac" #2: initiating Quick Mode
RSASIG+ENCRYPT+TUNNEL+PFS+UP {using isakmp#1}
Jan  7 09:45:38 thales pluto[3088]: "dac" #2: transition from state
STATE_QUICK_I1 to state STATE_QUICK_I2
Jan  7 09:45:38 thales pluto[3088]: "dac" #2: sent QI2, IPsec SA
established {ESP=>0x8710af63 <0xcf2592ad NATOA=0.0.0.0}
---------------------------------------------------------------------


Output from tcpdump on the client when pinging the gateway 192.168.1.2:
------------------------------------
09:54:22.277365 IP client.example.com.4500 > gw.example.com.4500: UDP,
length: 132
09:54:22.316655 IP gw.example.com > client.example.com:
ESP(spi=0x11941194,seq=0x8c0000)
09:54:22.316655 IP 192.168.1.2 > client.example.com: icmp 64: echo reply
seq 1
------------------------------------
Here everything is OK.


Output from tcpdump on the client when pinging another host such as
192.168.1.34:
------------------------------------
09:55:11.732276 IP client.example.com.4500 > gw.example.com.4500: UDP,
length: 132
------------------------------------
There is no reply.


Output from tcpdump on the gateway when pinging the gateway from the client:
----------------------------------
14:18:36.089324 IP gw.example.com.4500 > 192.168.1.2.4500: UDP, length 64
14:18:42.239276 IP gw.example.com > 192.168.1.2:
ESP(spi=0x11941194,seq=0x8c0000)
14:18:42.239276 IP gw.example.com > 192.168.1.2: icmp 64: echo request seq 1
14:18:42.239955 IP 192.168.1.2.4500 > gw.example.com.4500: UDP, length 132
----------------------------------
This looks normal too.


Output from tcpdump on the gateway when pinging another host
192.168.1.34 from the client:
----------------------------------
14:18:56.239081 IP client.example.com > 192.168.1.2:
ESP(spi=0x11941194,seq=0x8c0000)
14:18:56.239081 IP client example.com  > 192.168.1.34: icmp 64: echo
request seq 6
----------------------------------
Interesting, I don't see the the incoming UDP packets anymore. This
seems odd. But the echo request seems to make it through anyway...


Here is the client's ipsec.conf:
-----------------------------------------------
version	2.0

config setup
     nat_traversal=yes

conn dac
      authby=rsasig
      rightrsasigkey=%cert
      leftcert=user.pem
      leftsendcert=always
      leftid=user at example.com
      left=%defaultroute
      rightca="C=SE, O=Example.com, CN=Development CA"
      ike=aes128-sha
      esp=aes128-sha1
      right=gw.example.com
      rightsubnet=192.168.1.0/24
      rightid=@*.example.com
      auto=add
------------------------------------------------


And the gateway's ipsec.conf:
---------------------------------------------
version 2.0

config setup
     nat_traversal=yes
     virtual_private=%v4:192.168.0.0/16

conn rw
     authby=rsasig
     rightrsasigkey=%cert
     left=%defaultroute
     leftcert=gw.pem
     leftsubnet=192.168.1.0/24
     leftid=@*.example.com
     leftsendcert=always
     rightca="C=SE, O=Example.com, CN=Development CA"
     esp=aes128-sha1
     ike=aes128-sha
     right=%any
     rightid=user at example.com
     rightsubnet=vhost:%no,%priv
     auto=add
----------------------------------------------

Regards,

Marcus


More information about the Users mailing list