[Openswan Users] Why route to VPN gateway is lost ?
alet at librelogiciel.com
alet at librelogiciel.com
Tue Aug 25 00:15:53 EDT 2009
Hi,
I'm trying to setup an Openswan VPN gateway as described in the
attached PNG image, to allow roadwarriors to securely connect to BOTH
servers with private IP addresses on some internal VLANs and on servers
with public IP addresses which are located in the DMZ.
Our VPN box currently has a single public IP address, let's call it
(as in the image) mm.nn.oo.33, part of our DMZ range mm.nn.oo.00/25. the DMZ's
gateway is mm.nn.oo.125 (addresses and domains and user names below and in
the attached picture are "hidden", although easily guessable, but I
think they are consistent with our configuration).
Our Roadwarriors will use both GNU/linux, Windows (XP or Vista) and
MacOSX (up to the latest one, whatever it is). Very often they will be
NATed behind a DSL modem/router/NAT box as shown in the image. We will
never know their router's public IP, nor of course the internal IP
addresses of their home/hotel network.
Our VPN box' ipsec.conf is as follows, copied and adapted from
/etc/ipsec.d/examples/l2tp-cert.conf :
--- start of VPN server's ipsec.conf ---
version 2.0
config setup
nat_traversal=yes
virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12
nhelpers=0
uniqueids=yes
conn MyCNX
authby=rsasig
pfs=no
auto=add
rekey=no
#
# VPN Gateway itself
left=%defaultroute
leftrsasigkey=%cert
leftcert=/etc/ipsec.d/certs/vpngateway.example.com.pem
leftprotoport=17/1701
#
# End users
right=%any
rightca=%same
rightrsasigkey=%cert
rightprotoport=17/%any
rightsubnet=vhost:%priv,%no
include /etc/ipsec.d/examples/no_oe.conf
--- end of VPN server's ipsec.conf ---
As can be seen we will use certificates. The VPN gateway contains the
certificate of the certification authority in /etc/ipsec.d/cacerts/ and
its own certificate in /etc/ipsec.d/certs/
To end users, we give both their own certificate and private key,
as well as the CA's certificate, in a PKCS#12 file, and they have to
optionally extract the contents, and import onto their operating system.
We would like our VPN gateway to assign IP addresses to clients in the
10.66.66.2-10.66.66.254 range, so on the VPN gateway we've setup xl2tpd with the
following configuration :
--- start of VPN server's xl2tpd.conf ---
[global]
listen-addr = mm.nn.oo.33
port = 1701
access control = no
debug avp = yes
debug network = yes
debug state = yes
debug tunnel = yes
rand source = dev
;
[lns default]
exclusive = no
ip range = 10.66.66.2-10.66.66.254
hidden bit = no
local ip = 10.66.66.1
length bit = yes
require chap = yes
refuse pap = yes
require authentication = yes
unix authentication = no
name = vpngateway.example.com
ppp debug = yes
pppoptfile = /etc/ppp/options.l2tpd
call rws = 10
tunnel rws = 4
flow bit = yes
challenge = no
--- end of VPN server's xl2tpd.conf ---
Now for a start we begin with GNU/Linux clients, and we will try with
Windows and MacOSX clients once we're done with GNU/Linux ones, so we
setup Openswan as well, with the following configuration :
--- start of an end user's ipsec.conf ---
version 2.0
config setup
nat_traversal=yes
nhelpers=0
uniqueids=yes
conn MyCNX
authby=rsasig
pfs=no
auto=add
rekey=yes
keyingtries=3
#
# Me
left=%defaultroute
leftrsasigkey=%cert
leftcert=/etc/ipsec.d/certs/myownusercert.pem
leftsendcert=always
leftprotoport=17/1701
#
# VPN Gateway
right=mm.nn.oo.33
rightca=%same
rightrsasigkey=%cert
rightprotoport=17/1701
rightid="C=NC, ST=PS, O=UNC, OU=CRI, CN=vpngateway.example.com, E=vpnadmin at example.com"
include /etc/ipsec.d/examples/no_oe.conf
--- end of an end user's ipsec.conf ---
and xl2tpd with the following configuration :
--- start of an end user's xl2tpd.conf ---
[global]
port = 1701
access control = no
debug avp = yes
debug network = yes
debug state = yes
debug tunnel = yes
rand source = dev
;
[lac vpngateway.example.com]
lns = mm.nn.oo.33
redial = yes
redial timeout = 15
max redials = 5
length bit = yes
require chap = yes
refuse pap = yes
require authentication = yes
name = client
ppp debug = yes
pppoptfile = /etc/ppp/options.l2tpd.client
--- end of an end user's xl2tpd.conf ---
Finally, on a client we do this :
sudo ipsec auto --rereadsecrets
[sudo] password for jerome:
040 need passphrase for '/etc/ipsec.d/private/myownuser.key'
Enter secret:
004 valid passphrase, private key loaded successfully
sudo ipsec auto --up MyCNX
104 "MyCNX" #1: STATE_MAIN_I1: initiate
003 "MyCNX" #1: received Vendor ID payload [Openswan (this version) 2.4.12 LDAP_V3 PLUTO_SENDS_VENDORID PLUTO_USES_KEYRR]
003 "MyCNX" #1: received Vendor ID payload [Dead Peer Detection]
003 "MyCNX" #1: received Vendor ID payload [RFC 3947] method set to=109
106 "MyCNX" #1: STATE_MAIN_I2: sent MI2, expecting MR2
003 "MyCNX" #1: NAT-Traversal: Result using RFC 3947 (NAT-Traversal): no NAT detected
108 "MyCNX" #1: STATE_MAIN_I3: sent MI3, expecting MR3
004 "MyCNX" #1: STATE_MAIN_I4: ISAKMP SA established {auth=OAKLEY_RSA_SIG cipher=oakley_3des_cbc_192 prf=oakley_md5 group=modp1536}
117 "MyCNX" #2: STATE_QUICK_I1: initiate
004 "MyCNX" #2: STATE_QUICK_I2: sent QI2, IPsec SA established {ESP=>0xb375a8a4 <0x2177c3fb xfrm=AES_0-HMAC_SHA1 NATD=none DPD=none}
sudo ipsec auto --status
...
000 "MyCNX": 192.168.1.144[C=NC, ST=PS, O=UNC, OU=CRI, CN=myusername, E=myemailaddress at example.com]:17/1701...mm.nn.oo.33[C=NC, ST=PS, O=UNC, OU=CRI, CN=vpngateway.example.com, E=vpnadmin at example.com]:17/1701; erouted; eroute owner: #2
000 "MyCNX": srcip=unset; dstip=unset; srcup=ipsec _updown; dstup=ipsec _updown;
000 "MyCNX": CAs: 'C=NC, ST=PS, L=N, O=UNC, OU=CRI, CN=RSSI, E=rssi at example.com'...'C=NC, ST=PS, L=N, O=UNC, OU=CRI, CN=RSSI, E=rssi at example.com'
000 "MyCNX": ike_life: 3600s; ipsec_life: 28800s; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 3
000 "MyCNX": policy: RSASIG+ENCRYPT+TUNNEL+UP; prio: 32,32; interface: eth0; encap: esp;
000 "MyCNX": newest ISAKMP SA: #1; newest IPsec SA: #2;
000 "MyCNX": IKE algorithm newest: 3DES_CBC_192-MD5-MODP1536
000
000 #2: "MyCNX":500 STATE_QUICK_I2 (sent QI2, IPsec SA established); EVENT_SA_REPLACE in 27857s; newest IPSEC; eroute owner
000 #2: "MyCNX" esp.b375a8a4 at mm.nn.oo.33 esp.2177c3fb at 192.168.1.144 tun.0 at mm.nn.oo.33 tun.0 at 192.168.1.144
000 #1: "MyCNX":500 STATE_MAIN_I4 (ISAKMP SA established); EVENT_SA_REPLACE in 2475s; newest ISAKMP; lastdpd=-1s(seq in:0 out:0)
000
And when I try to ping the mm.nn.oo.33 address it seems the client has
lost its route to it :
ping mm.nn.oo.33
PING mm.nn.oo.33 (mm.nn.oo.33) 56(84) bytes of data.
>From 192.168.1.144 icmp_seq=1 Destination Host Unreachable
Ctrl+C
Also, when doing the following, I can see that xl2tpd on the client
machine can't reach the other end of the tunnel :
echo "c vpngateway.example.com" >/var/run/xl2tpd/l2tp-control
tail /var/log/daemon.log
xl2tpd[9422]: Listening on IP address 0.0.0.0, port 1701
xl2tpd[9422]: get_call: allocating new tunnel for host mm.nn.oo.33, port 1701.
xl2tpd[9422]: Connecting to host mm.nn.oo.33, port 1701
xl2tpd[9422]: control_finish: message type is (null)(0). Tunnel is 0, call is 0.
xl2tpd[9422]: control_finish: sending SCCRQ
xl2tpd[9422]: Maximum retries exceeded for tunnel 24355. Closing.
xl2tpd[9422]: build_fdset: closing down tunnel 24355
xl2tpd[9422]: Connection 0 closed to mm.nn.oo.33, port 1701 (Timeout)
xl2tpd[9422]: Unable to deliver closing message for tunnel 24355. Destroying anyway.
xl2tpd[9422]: build_fdset: closing down tunnel 24355
xl2tpd[9422]: Will redial in 15 seconds
tail /var/log/auth.log
Aug 25 14:20:04 lafrime pluto[8399]: "MyCNX" #2: ERROR: asynchronous network error report on eth0 (sport=500) for message to mm.nn.oo.33 port 500, complainant 192.168.1.144: No route to host [errno 113, origin ICMP type 3 code 1 (not authenticated)]
Aug 25 14:20:11 lafrime pluto[8399]: "MyCNX" #2: retransmitting in response to duplicate packet; already STATE_QUICK_I2
And on the gateway I've got this in /var/log/auth.log :
"MyCNX"[1] 192.168.1.144 #1: responding to Main Mode from unknown peer 192.168.1.144
"MyCNX"[1] 192.168.1.144 #1: transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
"MyCNX"[1] 192.168.1.144 #1: STATE_MAIN_R1: sent MR1, expecting MI2
"MyCNX"[1] 192.168.1.144 #1: NAT-Traversal: Result using RFC 3947 (NAT-Traversal): no NAT detected
"MyCNX"[1] 192.168.1.144 #1: transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
"MyCNX"[1] 192.168.1.144 #1: STATE_MAIN_R2: sent MR2, expecting MI3
"MyCNX"[1] 192.168.1.144 #1: Main mode peer ID is ID_DER_ASN1_DN: 'C=NC, ST=PS, O=UNC, OU=CRI, CN=myusername, E=myemailaddress at example.com'
"MyCNX"[1] 192.168.1.144 #1: no crl from issuer "C=NC, ST=PS, L=N, O=UNC, OU=CRI, CN=RSSI, E=rssi at example.com" found (strict=no)
"MyCNX"[1] 192.168.1.144 #1: switched from "MyCNX" to "MyCNX"
"MyCNX"[2] 192.168.1.144 #1: deleting connection "MyCNX" instance with peer 192.168.1.144 {isakmp=#0/ipsec=#0}
"MyCNX"[2] 192.168.1.144 #1: I am sending my cert
"MyCNX"[2] 192.168.1.144 #1: transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
"MyCNX"[2] 192.168.1.144 #1: STATE_MAIN_R3: sent MR3, ISAKMP SA established {auth=OAKLEY_RSA_SIG cipher=oakley_3des_cbc_192 prf=oakley_md5 group=modp1536}
"MyCNX"[2] 192.168.1.144 #2: responding to Quick Mode {msgid:fda79f90}
"MyCNX"[2] 192.168.1.144 #2: transition from state STATE_QUICK_R0 to state STATE_QUICK_R1
"MyCNX"[2] 192.168.1.144 #2: STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2
So it seems something is missing somewhere, but knowing what exactly is well above
my skills.
NB : the cut & paste sessions above are similar if I use a client in
some of our internal VLANs or at home : at some point the route to the
VPN gateway is lost.
Any idea ?
Thanks in advance
Jerome Alet
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vpn-unc.png
Type: image/png
Size: 34946 bytes
Desc: not available
Url : http://lists.openswan.org/pipermail/users/attachments/20090825/0b9b71f5/attachment-0001.png
More information about the Users
mailing list