Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

i have an Ubuntu 11.10 (oneiric) server running on a ReadyNAS. Im planning to use this to accept ipsec+l2tp connections through a router. However, the connection is failing somewhere half through. Using Openswan IPsec U2.6.28/K3.0.0-12-generic and trying to connect with an iOS 5 iPhone 4S.

This is how far i can get:

auth.log:

Jan 19 13:54:11 ubuntu pluto[1990]: added connection description "PSK"
Jan 19 13:54:11 ubuntu pluto[1990]: added connection description "L2TP-PSK-NAT"
Jan 19 13:54:11 ubuntu pluto[1990]: added connection description "L2TP-PSK-noNAT"
Jan 19 13:54:11 ubuntu pluto[1990]: added connection description "passthrough-for-non-l2tp"
Jan 19 13:54:11 ubuntu pluto[1990]: listening for IKE messages
Jan 19 13:54:11 ubuntu pluto[1990]: NAT-Traversal: Trying new style NAT-T
Jan 19 13:54:11 ubuntu pluto[1990]: NAT-Traversal: ESPINUDP(1) setup failed for new style NAT-T family IPv4 (errno=19)
Jan 19 13:54:11 ubuntu pluto[1990]: NAT-Traversal: Trying old style NAT-T
Jan 19 13:54:11 ubuntu pluto[1990]: adding interface eth0/eth0 192.168.19.99:500
Jan 19 13:54:11 ubuntu pluto[1990]: adding interface eth0/eth0 192.168.19.99:4500
Jan 19 13:54:11 ubuntu pluto[1990]: adding interface lo/lo 127.0.0.1:500
Jan 19 13:54:11 ubuntu pluto[1990]: adding interface lo/lo 127.0.0.1:4500
Jan 19 13:54:11 ubuntu pluto[1990]: adding interface lo/lo ::1:500
Jan 19 13:54:11 ubuntu pluto[1990]: adding interface eth0/eth0 2001:470:28:81:a00:27ff:*
Jan 19 13:54:11 ubuntu pluto[1990]: loading secrets from "/etc/ipsec.secrets"
Jan 19 13:54:11 ubuntu pluto[1990]: loading secrets from "/var/lib/openswan/ipsec.secrets.inc"
Jan 19 14:04:31 ubuntu pluto[1990]: packet from 95.*.*.233:500: received Vendor ID payload [RFC 3947] method set to=109
Jan 19 14:04:31 ubuntu pluto[1990]: packet from 95.*.*.233:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike] method set to=110
Jan 19 14:04:31 ubuntu pluto[1990]: packet from 95.*.*.233:500: ignoring unknown Vendor ID payload [8f8d83826d246b6fc7a8a6a428c11de8]
Jan 19 14:04:31 ubuntu pluto[1990]: packet from 95.*.*.233:500: ignoring unknown Vendor ID payload [439b59f8ba676c4c7737ae22eab8f582]
Jan 19 14:04:31 ubuntu pluto[1990]: packet from 95.*.*.233:500: ignoring unknown Vendor ID payload [4d1e0e136deafa34c4f3ea9f02ec7285]
Jan 19 14:04:31 ubuntu pluto[1990]: packet from 95.*.*.233:500: ignoring unknown Vendor ID payload [80d0bb3def54565ee84645d4c85ce3ee]
Jan 19 14:04:31 ubuntu pluto[1990]: packet from 95.*.*.233:500: ignoring unknown Vendor ID payload [9909b64eed937c6573de52ace952fa6b]
Jan 19 14:04:31 ubuntu pluto[1990]: packet from 95.*.*.233:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03] meth=108, but already using method 110
Jan 19 14:04:31 ubuntu pluto[1990]: packet from 95.*.*.233:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02] meth=107, but already using method 110
Jan 19 14:04:31 ubuntu pluto[1990]: packet from 95.*.*.233:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] meth=106, but already using method 110
Jan 19 14:04:31 ubuntu pluto[1990]: packet from 95.*.*.233:500: received Vendor ID payload [Dead Peer Detection]
Jan 19 14:04:31 ubuntu pluto[1990]: "PSK"[1] 95.*.*.233 #1: responding to Main Mode from unknown peer 95.*.*.233
Jan 19 14:04:31 ubuntu pluto[1990]: "PSK"[1] 95.*.*.233 #1: transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
Jan 19 14:04:31 ubuntu pluto[1990]: "PSK"[1] 95.*.*.233 #1: STATE_MAIN_R1: sent MR1, expecting MI2
Jan 19 14:04:33 ubuntu pluto[1990]: "PSK"[1] 95.*.*.233 #1: NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike (MacOS X): both are NATed
Jan 19 14:04:33 ubuntu pluto[1990]: "PSK"[1] 95.*.*.233 #1: transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
Jan 19 14:04:33 ubuntu pluto[1990]: "PSK"[1] 95.*.*.233 #1: STATE_MAIN_R2: sent MR2, expecting MI3
Jan 19 14:05:03 ubuntu pluto[1990]: ERROR: asynchronous network error report on eth0 (sport=500) for message to 95.*.*.233 port 500, complainant 95.*.*.233: Connection refused [errno 111, origin ICMP type 3 code 3 (not authenticated)]

Router config UDP 500, 1701 and 4500 forwarded to 192.168.19.99 (Ubuntu server for ipsec). Ipsec passthrough enabled.

/etc/ipsec.conf

# /etc/ipsec.conf - Openswan IPsec configuration file

# This file:  /usr/share/doc/openswan/ipsec.conf-sample
#
# Manual:     ipsec.conf.5


version 2.0     # conforms to second version of ipsec.conf specification

config setup
 nat_traversal=yes
 #charonstart=yes
 #plutostart=yes
 protostack=netkey

conn PSK
 authby=secret
 forceencaps=yes
 pfs=no
 auto=add
 keyingtries=3
 dpdtimeout=60
 dpdaction=clear
 rekey=no
 left=192.168.19.99
 leftnexthop=192.168.19.1
 leftprotoport=17/1701
 right=%any
 rightprotoport=17/%any
 rightsubnet=vhost:%priv,%no
 dpddelay=10
 #dpdtimeout=10
 #dpdaction=clear

include /etc/ipsec.d/l2tp-psk.conf

/etc/ipsec.d/l2tp-psk.conf

conn L2TP-PSK-NAT
 rightsubnet=vhost:%priv
 also=L2TP-PSK-noNAT

conn L2TP-PSK-noNAT
 #
 # PreSharedSecret needs to be specified in /etc/ipsec.secrets as
 # YourIPAddress     %any: "sharedsecret"
 authby=secret
 pfs=no
 auto=add
 keyingtries=3
 # we cannot rekey for %any, let client rekey
 rekey=no
 # Set ikelifetime and keylife to same defaults windows has
 ikelifetime=8h
 keylife=1h
 # l2tp-over-ipsec is transport mode
 type=transport
 #
 left=192.168.19.99
 #
 # For updated Windows 2000/XP clients,
 # to support old clients as well, use leftprotoport=17/%any
 leftprotoport=17/1701
 #
 # The remote user.
 #
 right=%any
 # Using the magic port of "0" means "any one single port". This is
 # a work around required for Apple OSX clients that use a randomly
 # high port, but propose "0" instead of their port.
 rightprotoport=17/%any
 dpddelay=10
 dpdtimeout=10
 dpdaction=clear

conn passthrough-for-non-l2tp
 type=passthrough
 left=192.168.19.99
 leftnexthop=192.168.19.1
 right=0.0.0.0
 rightsubnet=0.0.0.0/0
 auto=route

/etc/ipsec.secrets

include /var/lib/openswan/ipsec.secrets.inc

%any %any: PSK "my-key"
192.168.19.99 %any: PSK "my-key"

/etc/xl2tpd/xl2tpd.conf

[global]
debug network = yes
debug tunnel = yes
ipsec saref = no
listen-addr = 192.168.19.99

[lns default]
ip range = 192.168.19.201-192.168.19.220
local ip = 192.168.19.99
require chap = yes
refuse chap = no
refuse pap = no
require authentication = no
ppp debug = yes
pppoptfile = /etc/ppp/options.xl2tpd
length bit = yes

/etc/ppp/options.xl2tpd

pcp-accept-local
ipcp-accept-remote
noccp
auth
crtscts
idle 1800
mtu 1410
mru 1410
defaultroute
debug
lock
proxyarp
connect-delay 5000
ipcp-accept-local

/etc/ppp/chap-secrets

# Secrets for authentication using CHAP
# client        server  secret                  IP addresses
maciekish * my-secret *
* maciekish my-secret *

I can't seem to find the problem. Other ipsec connections to other hosts work from the network im currently at.

share|improve this question
    
Can the problem be the server being behind a NAT? The NAS has two ethernet ports, ill try connecting the second one to the outside network and giving the VM a public ip when i get home from work. –  Maciej Swic Jan 19 '12 at 14:12

1 Answer 1

up vote 2 down vote accepted

For anyone that is still looking for the answer to this, I had this problem on Ubuntu 10.04, openswan in the repos for 10.04 is 2.6.23 which gave me the errors mentioned in this question. The quick and easy way to fix this is to upgrade to 2.6.38, to do this you can install the Openswan team's PPA.

Instructions are here - https://launchpad.net/~openswan/+archive/ppa

...but the three steps you need are -

  1. sudo add-apt-repository ppa:openswan/ppa
  2. sudo apt-get update
  3. sudo apt-get upgrade
share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.