[Swan] Problems converting from OpenSWAN to LibreSWAN
Nels Lindquist
nlindq at maei.ca
Tue May 6 21:24:03 EEST 2014
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Good morning.
I'd like to migrate my current OpenSWAN VPN endpoints to LibreSWAN,
and to that end I've set up some testing boxes. I've run into some
difficulties as soon as NAT traversal is involved, and I'm not quite
sure why.
LibreSWAN 3.8 is installed on CentOS 6.x from the EPEL yum repository.
We're using NSS x509 certificates for authentication.
Host B resides on our DMZ. Traffic between the DMZ network and the
Corporate network passes through (and is restricted by) the firewall,
but no NAT is involved. Connections from Client A (Windows 7) to Host
B work perfectly. Connections from Client B to Host B from the
Internet do not connect. Host A, which is a mirror of Host B, was
moved from the DMZ to a colocation facility and has a public IP
address (no NAT). When Host A was in the local DMZ, connections from
Client A worked fine. Once Host A was moved out, Client A (now NATted
for connections to Host A) can no longer connect to Host A. Client B
can't connect to either Host A or Host B, but can connect to our
legacy OpenSWAN endpoint (also behind NAT).
|========|
|========| N|===========|---- DMZ Net --- | Host B |
| Host A |--- Internet --- A| Firewall | |========|
|========| | T|===========|
| |----------- Corp Net ------|
NAT |==========|
|==========| | Client A |
| Client B | |==========|
|==========|
Failed connections from Client A to Host B show up in the logs like so
(hostnames & IP addresses obfuscated):
May 6 12:06:08 mail pluto[21354]: packet from 203.0.113.89:500:
Ignoring Vendor ID payload [MS NT5 ISAKMPOAKLEY 00000008]
May 6 12:06:08 host_a pluto[21354]: packet from 203.0.113.89:500:
received Vendor ID payload [RFC 3947]
May 6 12:06:08 host_a pluto[21354]: packet from 203.0.113.89:500:
ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]
May 6 12:06:08 host_a pluto[21354]: packet from 203.0.113.89:500:
received Vendor ID payload [FRAGMENTATION]
May 6 12:06:08 host_a pluto[21354]: packet from 203.0.113.89:500:
ignoring Vendor ID payload [MS-Negotiation Discovery Capable]
May 6 12:06:08 host_a pluto[21354]: packet from 203.0.113.89:500:
ignoring Vendor ID payload [Vid-Initial-Contact]
May 6 12:06:08 host_a pluto[21354]: packet from 203.0.113.89:500:
ignoring Vendor ID payload [IKE CGA version 1]
May 6 12:06:08 host_a pluto[21354]: packet from 203.0.113.89:500:
initial Main Mode message received on 216.194.67.132:500 but no
connection has been authorized with policy=RSASIG
Connections from Client B to Host B:
May 6 06:24:55 host_b pluto[18985]: packet from 203.0.113.168:500:
ignoring Vendor ID payload [MS NT5 ISAKMPOAKLEY 00000008]
May 6 06:24:55 host_b pluto[18985]: packet from 203.0.113.168:500:
received Vendor ID payload [RFC 3947]
May 6 06:24:55 host_b pluto[18985]: packet from 203.0.113.168:500:
ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]
May 6 06:24:55 host_b pluto[18985]: packet from 203.0.113.168:500:
received Vendor ID payload [FRAGMENTATION]
May 6 06:24:55 host_b pluto[18985]: packet from 203.0.113.168:500:
ignoring Vendor ID payload [MS-Negotiation Discovery Capable]
May 6 06:24:55 host_b pluto[18985]: packet from 203.0.113.168:500:
ignoring Vendor ID payload [Vid-Initial-Contact]
May 6 06:24:55 host_b pluto[18985]: packet from 203.0.113.168:500:
ignoring Vendor ID payload [IKE CGA version 1]
May 6 06:24:55 host_b pluto[18985]: "L2TP-Win2KXP"[3] 203.0.113.168
#3: responding to Main Mode from unknown peer 203.0.113.168
May 6 06:24:55 host_b pluto[18985]: "L2TP-Win2KXP"[3] 203.0.113.168
#3: OAKLEY_GROUP 20 not supported. Attribute OAKLEY_GROUP_DESCRIPTION
May 6 06:24:55 host_b pluto[18985]: "L2TP-Win2KXP"[3] 203.0.113.168
#3: OAKLEY_GROUP 19 not supported. Attribute OAKLEY_GROUP_DESCRIPTION
May 6 06:24:55 host_b pluto[18985]: "L2TP-Win2KXP"[3] 203.0.113.168
#3: transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
May 6 06:24:55 host_b pluto[18985]: "L2TP-Win2KXP"[3] 203.0.113.168
#3: STATE_MAIN_R1: sent MR1, expecting MI2
May 6 06:24:55 host_b pluto[18985]: "L2TP-Win2KXP"[3] 203.0.113.168
#3: NAT-Traversal: Result using RFC 3947 (NAT-Traversal): both are NATed
May 6 06:24:55 host_b pluto[18985]: "L2TP-Win2KXP"[3] 203.0.113.168
#3: transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
May 6 06:24:55 host_b pluto[18985]: "L2TP-Win2KXP"[3] 203.0.113.168
#3: STATE_MAIN_R2: sent MR2, expecting MI3
Here's the connection definition for L2TP. I've tried forceencaps
yes/no to no effect.
Nat traversal is enabled and we're using NETKEY.
conn L2TP-Win2KXP
dpdaction=clear
# Use a certificate. Disable Perfect Forward Secrecy.
pfs=no
# Required for Windows 2000/XP clients.
leftprotoport=17/0
# The remote user.
right=%any
rightsubnet=vhost:%no,%priv
rightca=%same
rightrsasigkey=%cert
rightprotoport=17/%any
#forceencaps=yes
auto=add
keyingtries=3
#type=transport
And the default:
conn %default
keyingtries=0
disablearrivalcheck=no
dpdaction=hold
dpddelay=30
dpdtimeout=120
authby=rsasig
compress=no
left=%defaultroute
leftid=@host_b.example.com
leftrsasigkey=%cert
leftcert="host_b.example.com - Example Friendly Name"
Any suggestions gratefully accepted!
Nels Lindquist
- ----
<nlindq at maei.ca>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlNpKMAACgkQh6z5POoOLgRiLgCgqrVCPC0HEAEplcdhEF+eoAsU
RFEAoJ5MA0Lyl07jsFTBz1tPakuWXZEj
=SacX
-----END PGP SIGNATURE-----
More information about the Swan
mailing list