[Openswan Users] Roadwarriors can't access network behind server despite successful IPsec SA

Ryan Cabell rcabell at gmail.com
Tue Feb 5 13:53:59 EST 2008


Hello,
I'm trying to work out an issue that I've been struggling with for over a
week now. I am trying to support roadwarrior clients (using Mac OS X)
connecting to xl2tpd on an Openswan (2.4.10) server behind a NAT router.
Some of these clients are using a customer's wireless network that does not
allow access to port 4500, only UDP port 500 and ESP/AH, so I can't use
NAT-T.

I finally got the IPsec handshake working by turning off NAT-T and enabling
"IPsec Passthrough" on the gateway. However, clients can't access the L2TP
server (or anything else) when connected.

I suspect this is a routing issue, but changing anything in my
ipsec.confseems to break the (fragile) configuration I have working.

I am running on CentOS 5, KLIPS, Openswan 2.4.10, Linux 2.6.18.

This is my /etc/ipsec.conf: (items commented out are things I thought would
be needed but caused errors)
-------------------------

version 2

config setup
        interfaces="ipsec0=eth0"
        klipsdebug=none
        plutodebug=none
        fragicmp=no
        uniqueids=no
        overridemtu=1390
        nocrsend=yes
        keep_alive=60
        crlcheckinterval=0
        forwardcontrol="yes"
        virtual_private=%v4:192.168.1.0/24

conn %default
        rekeymargin=9m
        rekeyfuzz=100%
        keyingtries=0
        dpddelay=30
        dpdtimeout=120
        dpdaction=clear

include /etc/ipsec.d/examples/no_oe.conf

conn roadwarrior-l2tp
        #left="192.168.1.42"
        left=%defaultroute
        leftsourceip="192.168.1.42"
        leftnexthop="192.168.1.1"
        leftsubnet="67.xxx.xxx.153/32"
        leftprotoport="17/1701"
        keyingtries=3
        authby="secret"
        auth="esp"
        ikelifetime="28800"
        keyexchange="ike"
        pfs="no"
        keylife="3600"
        rekey="no"
        right=%any
        rightnexthop="192.168.1.1"
        #rightsubnet=vhost:%no,%priv
        #rightsourceip="192.168.1.1"
        rightprotoport="17/%any"
        type="transport"
        auto="add"
-------------------------------------

Running "ipsec auto --status" give me this routing info:

000 "roadwarrior-l2tp": 67.xxx.xxx.153/32===
192.168.1.42:17/1701---192.168.1.1...192.168.1.1---%any:17/%any; unrouted;
eroute owner: #0
000 "roadwarrior-l2tp":     srcip=192.168.1.42; dstip=unset; srcup=ipsec
_updown; dstup=ipsec _updown;
000 "roadwarrior-l2tp":   ike_life: 28800s; ipsec_life: 3600s; rekey_margin:
540s; rekey_fuzz: 100%; keyingtries: 3
000 "roadwarrior-l2tp":   policy: PSK+ENCRYPT+TUNNEL+DONTREKEY; prio: 32,32;
interface: eth0; encap: esp;
000 "roadwarrior-l2tp":   dpd: action:clear; delay:30; timeout:120;
000 "roadwarrior-l2tp":   newest ISAKMP SA: #0; newest IPsec SA: #0;
000 "roadwarrior-l2tp"[2]: 67.xxx.xxx.153/32===
192.168.1.42:17/1701---192.168.1.1...192.168.1.1---128.xxx.xxx.30:17/49684;
erouted; eroute owner: #4
000 "roadwarrior-l2tp"[2]:     srcip=192.168.1.42; dstip=unset; srcup=ipsec
_updown; dstup=ipsec _updown;
000 "roadwarrior-l2tp"[2]:   ike_life: 28800s; ipsec_life: 3600s;
rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 3
000 "roadwarrior-l2tp"[2]:   policy: PSK+ENCRYPT+TUNNEL+DONTREKEY; prio:
32,32; interface: eth0; encap: esp;
000 "roadwarrior-l2tp"[2]:   dpd: action:clear; delay:30; timeout:120;
000 "roadwarrior-l2tp"[2]:   newest ISAKMP SA: #3; newest IPsec SA: #4;
000 "roadwarrior-l2tp"[2]:   IKE algorithm newest:
3DES_CBC_192-SHA1-MODP1024

and "ipsec eroute" gives me:

0          67.xxx.xxx.153/32:1701 -> 128.xxx.xxx.30/32:49694 =>
esp0x8cda0e2 at 128.xxx.xxx.30:17

---------------------------------

I suspect things would work better if I could get Openswan running on the
external internet-facing IP, but I would really like to keep things the way
they are (server behind the NAT gateway) if at all possible...

thanks,
Ryan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20080205/1152fd21/attachment.html 


More information about the Users mailing list