[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