Bug 1408616 - not able to connect to VPN servers behind NAT
Summary: not able to connect to VPN servers behind NAT
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: libreswan
Version: 25
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Paul Wouters
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-12-26 02:12 UTC by Niki W. Waibel
Modified: 2016-12-29 01:16 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-12-27 15:21:31 UTC


Attachments (Terms of Use)

Description Niki W. Waibel 2016-12-26 02:12:37 UTC
Description of problem:
connection to a L2TP/IPsec VPN results in:
===
Dec 26 02:48:35 lnx-1 pluto[22570]: "nm-ipsec-l2tp-21697" #1: Main mode peer ID is ID_IPV4_ADDR: '192.168.2.31'
Dec 26 02:48:35 lnx-1 pluto[22570]: "nm-ipsec-l2tp-21697" #1: we require IKEv1 peer to have ID '216.72.232.169', but peer declares '192.168.2.31'
Dec 26 02:48:35 lnx-1 NetworkManager[798]: 002 "nm-ipsec-l2tp-21697" #1: Main mode peer ID is ID_IPV4_ADDR: '192.168.2.31'
Dec 26 02:48:35 lnx-1 NetworkManager[798]: 003 "nm-ipsec-l2tp-21697" #1: we require IKEv1 peer to have ID '216.72.232.169', but peer declares '192.168.2.31'
===
the reported IP addresses are all correct. 216.72.232.169 is the public IP and 192.168.2.31 the internal (configured as "exposed host" on the 216.72.232.169 router).

Version-Release number of selected component (if applicable):
 libreswan-3.18-1.fc25.src.rpm

How reproducible:
 always

Steps to Reproduce:
1. create a point-to-point tunneling protocol (l2tp) from nm-applet.
2. enter correct settings of a NATed l2tp/ipsec vpn server
3. connect to that VPN.

Actual results:
 journal as above, no VPN connection

Expected results:
 a VPN connection, as like with VPN servers that use public IPs

Additional info:
* android and ios bring up the vpn connection to the NATed host like charm.
* the same connection settings to the same VPN hardware, but not NATed, works fine.

Comment 1 Paul Wouters 2016-12-27 15:21:31 UTC
we require IKEv1 peer to have ID '216.72.232.169', but peer declares '192.168.2.31'

this is a misconfiguration. You can either configure both sides to use an actual ID, or you can use the public ip as ID. Eg if left is your server behind NAT,
use:

left=%defaultroute  #better then hardcoded private IP
leftid=216.72.232.169

Comment 2 Niki W. Waibel 2016-12-27 17:22:40 UTC
it seems networkmanager comes up with this config:
=====
# cat /var/run/nm-ipsec-l2tp.7848/ipsec.conf 
conn nm-ipsec-l2tp-7848
  auto=add
  type=transport
  authby=secret
  keyingtries=0
  left=%defaultroute
  leftprotoport=udp/l2tp
  rightprotoport=udp/l2tp
  right=216.72.232.169
  pfs=no
  forceencaps=yes
=====
should this work or not, if the server is behind a NAT?

[there is no hardcoded private ip].

Comment 3 Paul Wouters 2016-12-28 15:47:37 UTC
you can work around it on the client by adding rightid=192.168.2.31 but the real fix is on the server to add leftid=216.72.232.169

Comment 4 Niki W. Waibel 2016-12-29 01:16:16 UTC
thank you for the additional details!


Note You need to log in before you can comment on or make changes to this bug.