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 <[email protected]> To: [email protected] 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 - ---- <[email protected]> -----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 [email protected] https://lists.libreswan.org/mailman/listinfo/swan
_______________________________________________ Swan mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan
