[Openswan Users] IPsec SA established but packets are not encapsulated

Dennison Williams dennison.williams at gmail.com
Fri Apr 2 21:32:57 EDT 2010


Hello all,

I sent an email yesterday titled "openswan + xl2tpd + iptables issues" 
where I incorrectly diagnosed the problem to be one of iptables.  I now
believe that the problem lies with packets not being correctly
encapsulated between the two endpoints.  I expect that packets should be
encapsulated to the openswan server from the client and that I should be
able to reach addresses on the LAN but this is not happening.

My network looks like follows:
client (192.168.1.23) --> gateway (192.168.1.1) -> INTERNET -> openswan
(24.21.203.123) -> LAN (10.66.6.0/24)


The connection seems to come all the way up correctly:
client# ipsec auto --up pptp-rw
104 "pptp-rw" #15: STATE_MAIN_I1: initiate
003 "pptp-rw" #15: received Vendor ID payload [Openswan (this version)
2.6.25 ]
003 "pptp-rw" #15: received Vendor ID payload [Dead Peer Detection]
003 "pptp-rw" #15: received Vendor ID payload [RFC 3947] method set to=109
106 "pptp-rw" #15: STATE_MAIN_I2: sent MI2, expecting MR2
003 "pptp-rw" #15: NAT-Traversal: Result using RFC 3947 (NAT-Traversal):
both are NATed
108 "pptp-rw" #15: STATE_MAIN_I3: sent MI3, expecting MR3
003 "pptp-rw" #15: discarding duplicate packet; already STATE_MAIN_I3
010 "pptp-rw" #15: STATE_MAIN_I3: retransmission; will wait 20s for response
003 "pptp-rw" #15: received Vendor ID payload [CAN-IKEv2]
004 "pptp-rw" #15: STATE_MAIN_I4: ISAKMP SA established
{auth=OAKLEY_RSA_SIG cipher=aes_128 prf=oakley_sha group=modp2048}
117 "pptp-rw" #16: STATE_QUICK_I1: initiate
004 "pptp-rw" #16: STATE_QUICK_I2: sent QI2, IPsec SA established tunnel
mode {ESP=>0xb1f1203e <0x8f21f2e4 xfrm=AES_128-HMAC_SHA1 NATOA=none
NATD=24.21.203.123:4500 DPD=none}

No new routing rules are setup to the LAN:
# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use
Iface
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0
wlan0
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0
wlan0
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0
wlan0

And packets do not seem to get incapsulated when doing a ping test from
either end:
client# tcpdump -i wlan0 -n host 24.21.203.123 and not port 22
13:48:00.656164 IP 24.21.203.123.4500 > 192.168.1.23.4500:
isakmp-nat-keep-alive
13:48:05.005971 IP 192.168.1.23 > 24.21.203.123: ICMP echo request, id
42584, seq 1, length 64
13:48:05.133579 IP 24.21.203.123 > 192.168.1.23: ICMP echo reply, id
42584, seq 1, length 64

As you can see the nat-keep-alive is coming through, but there are no
ESP packets for the ping.  Things look about the same as you might
expect on the server:

server# ipsec auto --status|grep estab
000 #47: "pptp-rw"[7] 75.93.49.165:4500 STATE_QUICK_R2 (IPsec SA
established); EVENT_SA_REPLACE in 3070s; newest IPSEC; eroute owner;
isakmp#46; idle; import:not set
000 #46: "pptp-rw"[7] 75.93.49.165:4500 STATE_MAIN_R3 (sent MR3, ISAKMP
SA established); EVENT_SA_EXPIRE in 3340s; newest ISAKMP;
lastdpd=-1s(seq in:0 out:0); idle; import:not set

Where as here we do see the route set up to the client:
server# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use
Iface
255.255.255.255 0.0.0.0         255.255.255.255 UH    0      0        0 eth2
10.66.6.0       0.0.0.0         255.255.255.0   U     0      0        0 eth2
24.21.200.0     0.0.0.0         255.255.248.0   U     0      0        0 eth1
0.0.0.0         24.21.200.1     0.0.0.0         UG    0      0        0 eth1

But still no esp encapsulated packets (since the client is NAT-T the
ping is initiated from the client):
server# tcpdump -i eth1 -n \(host 75.93.49.165 and not port 22\) or
\(host 192.168.1.23 and not port 22\)
13:55:22.888588 IP 24.21.203.123.4500 > 75.93.49.165.4500:
isakmp-nat-keep-alive
13:55:26.117191 IP 75.93.49.165 > 24.21.203.123: ICMP echo request, id
64345, seq 1, length 64
13:55:26.117253 IP 24.21.203.123 > 75.93.49.165: ICMP echo reply, id
64345, seq 1, length 64


In this test 75.93.49.165 is the public ip of the network the client is
on.  We see the nat-keep-alive traffic, and we still see the clear text
icmp traffic.

I have been starring at this config issue for so long now, I am
guessing my problem is obvious but can't seem to find it, so any
feedback would be helpful at this point.

Sincerely,
Dennison Williams

ipsec --version: Linux Openswan U2.6.25/K2.6.26-2-486 (netkey)
compiled manually on both client and server

Server ipsec config:
version 2.0
config setup
        interfaces=%defaultroute
        nat_traversal=yes
       
virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:!10.66.6.0/24
        protostack=netkey

conn pptp-rw
        leftcert=StorageCert.pem
        leftrsasigkey=%cert
        leftid=<x509_subject>
        left=24.21.203.123	#%defaultroute is not working here for some reason
        leftsourceip=10.66.6.1
        leftsubnet=10.66.6.0/24
        rightsubnet=vhost:%no,%priv
        right=%any
        auto=add
        rightrsasigkey=%cert
        rightid=<x509_subject>
        authby=rsasig
        pfs=no
        rightca=%same
        rekey=no

conn block
    auto=ignore

conn private
    auto=ignore

conn private-or-clear
    auto=ignore

conn clear-or-private
    auto=ignore

conn clear
    auto=ignore

conn packetdefault
    auto=ignore

Client ipsec config:
version 2.0
config setup
        interfaces=%defaultroute
        nat_traversal=yes
        protostack=netkey

conn pptp-rw
        left=192.168.1.23			#%defaultroute is not working here for some reason
        leftrsasigkey=%cert
        leftcert=<cert_file_name>
        leftprotoport=17/1701
        leftsourceip=192.168.1.23
        right=24.21.203.123
        rightid=<x509_subject>
        rightsubnet=10.66.6.0/24
        rightcert=StorageCert.pem
        rightrsasigkey=%cert
        rightca=%same
        authby=rsasig
        pfs=no
        keyingtries=3
        auto=add
        rekey=yes
        type=transport

conn block
    auto=ignore

conn private
    auto=ignore

conn private-or-clear
    auto=ignore

conn clear-or-private
    auto=ignore

conn clear
    auto=ignore

conn packetdefault
    auto=ignore



More information about the Users mailing list