[strongSwan] strongSwan Configuration Issue - NAT Both Ends, Road Warrior
Adam Ely
a at fjear.me
Thu Jul 28 03:33:38 CEST 2011
I’m having a problem getting over some last hurdles. Hopefully someone can
help. Here is my scenario:
- True road warrior, never know where the clients will connect from
- Currently testing with OS X and iPhone LT2P clients and will expand
to Win and other clients. Server is Linux
- Currently using PSK with no IP, username, or server restrictions
(all wild cards) to make testing easier
- BOTH ends are behind NAT
- Server local IP (eth0) = 10.254.90.xxx
- Server Public IP = 50.17.152.xxx (Amazon EC2)
- All ports/protocols allowed to server
- Client IP = ANY
During install, enabled NAT transport support:
./configure –enable-nat-transport
ipsec.conf:
config setup
nat_traversal=yes
charonstart=yes
plutostart=yes
virtual_private=%v4:
10.0.0.0/8,%v4:172.16.0.0/12,%v4:192.168.0.0/16,%v4:!192.168.1.0/24
conn L2TP
dpddelay=40
dpdtimeout=130
dpdaction=clear
authby=psk
pfs=no
type=tunnel
esp=aes128-sha1
ike=aes128-sha-modp1024
keyexchange=ikev1
keyingtries=3
left=10.254.90.xxx
leftnexthop=%defaultroute
leftprotoport=17/1701
leftsubnet=50.17.152.xxx/32
right=%any
rightprotoport=17/%any
rightsubnet=vhost:%no,%priv
forceencaps=yes
auto=add
more /etc/xl2tpd/l2tp-secrets
* * password
more /etc/xl2tpd/xl2tpd.conf
[global]
debug network = yes
debug tunnel = yes
[lns default]
ip range = 172.16.1.200-172.16.1.254
local ip = 172.16.1.201
require chap = yes
refuse pap = yes
require authentication = yes
name = vpn.adamely.com
ppp debug = yes
pppoptfile = /etc/ppp/options.xl2tpd
length bit = yes
more /etc/ppp/options.xl2tpd
ipcp-accept-local
ipcp-accept-remote
ms-dns 172.16.0.23
noccp
auth
crtscts
idle 1800
mtu 1410
mru 1410
nodefaultroute
debug
lock
proxyarp
connect-delay 5000
name testbox
more /etc/ppp/chap-secrets
* * password *
Log:
/var/log/secure
pluto[1833]: packet from 75.208.217.xxx:57364: received Vendor ID payload
[RFC 3947]
pluto[1833]: packet from 75.208.217.xxx:57364: ignoring Vendor ID payload
[4df37928e9fc4fd1b3262170d515c662]
pluto[1833]: packet from 75.208.217.xxx:57364: ignoring Vendor ID payload
[8f8d83826d246b6fc7a8a6a428c11de8]
pluto[1833]: packet from 75.208.217.xxx:57364: ignoring Vendor ID payload
[439b59f8ba676c4c7737ae22eab8f582]
pluto[1833]: packet from 75.208.217.xxx:57364: ignoring Vendor ID payload
[4d1e0e136deafa34c4f3ea9f02ec7285]
pluto[1833]: packet from 75.208.217.xxx:57364: ignoring Vendor ID payload
[80d0bb3def54565ee84645d4c85ce3ee]
pluto[1833]: packet from 75.208.217.xxx:57364: ignoring Vendor ID payload
[9909b64eed937c6573de52ace952fa6b]
pluto[1833]: packet from 75.208.217.xxx:57364: ignoring Vendor ID payload
[draft-ietf-ipsec-nat-t-ike-03]
pluto[1833]: packet from 75.208.217.xxx:57364: ignoring Vendor ID payload
[draft-ietf-ipsec-nat-t-ike-02]
pluto[1833]: packet from 75.208.217.xxx:57364: ignoring Vendor ID payload
[draft-ietf-ipsec-nat-t-ike-02_n]
pluto[1833]: packet from 75.208.217.xxx:57364: received Vendor ID payload
[Dead Peer Detection]
pluto[1833]: "L2TP"[7] 75.208.217.xxx:57364 #7: responding to Main Mode
from unknown peer 75.208.217.xxx:57364
pluto[1833]: "L2TP"[7] 75.208.217.xxx:57364 #7: NAT-Traversal: Result using
RFC 3947: both are NATed
pluto[1833]: "L2TP"[7] 75.208.217.xxx:57364 #7: ignoring informational
payload, type IPSEC_INITIAL_CONTACT
pluto[1833]: "L2TP"[7] 75.208.217.xxx:57364 #7: Peer ID is ID_IPV4_ADDR:
'192.168.1.2'
pluto[1833]: "L2TP"[8] 75.208.217.xxx:57364 #7: deleting connection "L2TP"
instance with peer 75.208.217.xxx {isakmp=#0/ipsec=#0}
pluto[1833]: | NAT-T: new mapping 75.208.217.xxx:57364/57365)
pluto[1833]: "L2TP"[8] 75.208.217.xxx:57365 #7: sent MR3, ISAKMP SA
established
Jul 27 17:04:11 domU-12-31-39-00-54-F1 pluto[1833]: "L2TP"[8]
75.208.217.xxx:57365 #8: NAT-Traversal: received 2 NAT-OA. using first,
ignoring others
Jul 27 17:04:11 domU-12-31-39-00-54-F1 pluto[1833]: "L2TP"[8]
75.208.217.xxx:57365 #8: responding to Quick Mode
Jul 27 17:04:11 domU-12-31-39-00-54-F1 pluto[1833]: "L2TP"[8]
75.208.217.xxx:57365 #7: ignoring informational payload, type
INVALID_HASH_INFORMATION
Jul 27 17:04:11 domU-12-31-39-00-54-F1 pluto[1833]: "L2TP"[8]
75.208.217.xxx:57365 #7: received Delete SA payload: deleting ISAKMP State
#7
I’m not sure where to look now. I’ve read the mailing list, forums,
tutorials, and blogs. I’ve compared my configure against others that say
theirs works but seem to keep running into the same result. Logs look the
same, client disconnects.
Any help is much appreciated.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20110727/b9e65954/attachment.html>
More information about the Users
mailing list