[Swan] Problems converting from OpenSWAN to LibreSWAN
Paul Wouters
paul at nohats.ca
Tue May 6 21:32:08 EEST 2014
On Tue, 6 May 2014, Nels Lindquist wrote:
Can you tell me what happens when you "merge" the conn %default values
in your conn L2TP-Win2KXP ?
Paul
> Date: Tue, 6 May 2014 14:24:03
> From: Nels Lindquist <nlindq at maei.ca>
> To: swan at lists.libreswan.org
> Subject: [Swan] Problems converting from OpenSWAN to LibreSWAN
>
> -----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-----
> _______________________________________________
> Swan mailing list
> Swan at lists.libreswan.org
> https://lists.libreswan.org/mailman/listinfo/swan
>
More information about the Swan
mailing list