VPN:- IPsec L2P NAT-T not working

setdet · 04-06-2020, 05:58 PM

So, I've been reading up on VPNsand managed to get a server<>client setup working using libreswan and xl2ptd. All works fine and I've systemd'd it all so nice n easy to control.

However,

Only 1 client can connect from behind my ISP router. After days and hours of late night reading a tweaking, I discovered that a limitation of IPsec is exactly this. But then I came across NAT-T so set about configuring this , Lest an Right sides. Looking at the logs/outputs I think I have NAT-T enabled both sides but two clients behind my router , will collapse the tunnel for the connected client and the one I'm trying to connect. I thought NAT-T encapsulates packets with another UDP packet to pass-through the NATs.

My router is an ISP provided router from EE - the only VPN setting it has is "Port Clamping" which I've set on and off - to no avail.

My setup is:-
* a droplet in Digital Ocean public IP a.a.a.a
* droplet running the VPN server. VPN server IP is 10.1.1.1
* nginx reverse proxy running on the server, proxying to VPN client 10.1.1.10
* ISP provided router with [dynamic] IP b.b.b.b
* clients X and Y behind ISP Router NAT.

ipsec verify on SERVER:-

Code:

Verifying installed system and configuration files

Version check and ipsec on-path                         [OK]
Libreswan 3.29 (netkey) on 4.15.0-91-generic
Checking for IPsec support in kernel                    [OK]
 NETKEY: Testing XFRM related proc values
         ICMP default/send_redirects                    [OK]
         ICMP default/accept_redirects                  [OK]
         XFRM larval drop                               [OK]
Pluto ipsec.conf syntax                                 [OK]
Checking rp_filter                                      [OK]
Checking that pluto is running                          [OK]
 Pluto listening for IKE on udp 500                     [OK]
 Pluto listening for IKE/NAT-T on udp 4500              [OK]
 Pluto ipsec.secret syntax                              [OK]
Checking 'ip' command                                   [OK]
Checking 'iptables' command                             [OK]
Checking 'prelink' command does not interfere with FIPS [OK]
Checking for obsolete ipsec.conf options                [OK]
root@ubuntu-s-1vcpu-1gb-lon1-01:~/VPN#

ipsec verify on CLIENT

Code:

Verifying installed system and configuration files

Version check and ipsec on-path                         [OK]
Libreswan 3.27 (netkey) on 4.19.97-v7+
Checking for IPsec support in kernel                    [OK]
 NETKEY: Testing XFRM related proc values
         ICMP default/send_redirects                    [OK]
         ICMP default/accept_redirects                  [OK]
         XFRM larval drop                               [OK]
Pluto ipsec.conf syntax                                 [OK]
Two or more interfaces found, checking IP forwarding    [OK]
Checking rp_filter                                      [OK]
Checking that pluto is running                          [OK]
 Pluto listening for IKE on udp 500                     [OK]
 Pluto listening for IKE/NAT-T on udp 4500              [OK]
 Pluto ipsec.secret syntax                              [OBSOLETE]
  003 WARNING: using a weak secret (PSK)
Checking 'ip' command                                   [OK]
Checking 'iptables' command                             [OK]
Checking 'prelink' command does not interfere with FIPS [OK]
Checking for obsolete ipsec.conf options                [OBSOLETE KEYWORD]
Traceback (most recent call last):
  File "/usr/lib/ipsec/verify", line 426, in <module>
    main()
  File "/usr/lib/ipsec/verify", line 417, in main
    configsetupcheck()
  File "/usr/lib/ipsec/verify", line 398, in configsetupcheck
    err = err.replace("Warning"," Warning")
TypeError: a bytes-like object is required, not 'str'

Strange that is crashes??

server journalctl log

Code:

Apr 06 23:05:19 ubuntu-s-1vcpu-1gb-lon1-01 pluto[11681]: "l2tp-psk"[6] 95.147.158.93 #11: responding to Main Mode from unknown peer 95.147.158.93 on port 500
Apr 06 23:05:19 ubuntu-s-1vcpu-1gb-lon1-01 pluto[11681]: "l2tp-psk"[6] 95.147.158.93 #11: WARNING: connection l2tp-psk PSK length of 4 bytes is too short for sha2_256 PRF in FIPS mode (16 bytes required)
Apr 06 23:05:19 ubuntu-s-1vcpu-1gb-lon1-01 pluto[11681]: "l2tp-psk"[6] 95.147.158.93 #11: STATE_MAIN_R1: sent MR1, expecting MI2
Apr 06 23:05:19 ubuntu-s-1vcpu-1gb-lon1-01 pluto[11681]: "l2tp-psk"[6] 95.147.158.93 #11: STATE_MAIN_R2: sent MR2, expecting MI3
Apr 06 23:05:19 ubuntu-s-1vcpu-1gb-lon1-01 pluto[11681]: "l2tp-psk"[6] 95.147.158.93 #11: Peer ID is ID_IPV4_ADDR: '192.168.1.10'
Apr 06 23:05:19 ubuntu-s-1vcpu-1gb-lon1-01 pluto[11681]: "l2tp-psk"[6] 95.147.158.93 #11: STATE_MAIN_R3: sent MR3, ISAKMP SA established {auth=PRESHARED_KEY cipher=aes_256 integ=sha2_256 group=MODP2048}
Apr 06 23:05:19 ubuntu-s-1vcpu-1gb-lon1-01 pluto[11681]: "l2tp-psk"[6] 95.147.158.93 #11: the peer proposed: a.a.a.a/32:17/1701 -> 192.168.1.10/32:17/0
Apr 06 23:05:19 ubuntu-s-1vcpu-1gb-lon1-01 pluto[11681]: "l2tp-psk"[6] 95.147.158.93 #11: NAT-Traversal: received 2 NAT-OA. Using first, ignoring others
Apr 06 23:05:19 ubuntu-s-1vcpu-1gb-lon1-01 pluto[11681]: "l2tp-psk"[6] 95.147.158.93 #12: responding to Quick Mode proposal {msgid:fd279e64}
Apr 06 23:05:19 ubuntu-s-1vcpu-1gb-lon1-01 pluto[11681]: "l2tp-psk"[6] 95.147.158.93 #12:     us: a.a.a.a<a.a.a.a>:17/1701
Apr 06 23:05:19 ubuntu-s-1vcpu-1gb-lon1-01 pluto[11681]: "l2tp-psk"[6] 95.147.158.93 #12:   them: b.b.b.b:17/1701===192.168.1.10/32
Apr 06 23:05:19 ubuntu-s-1vcpu-1gb-lon1-01 pluto[11681]: "l2tp-psk"[6] 95.147.158.93 #12: STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2 transport mode {ESP/NAT=>0xdd5c8521 <0x83ffede6 xfrm=AES_CBC_128-HMAC_SHA1_96 NATOA=192.168.1.10 NATD=95.147.158.93:4500 DPD=passive}
Apr 06 23:05:20 ubuntu-s-1vcpu-1gb-lon1-01 pluto[11681]: "l2tp-psk"[6] 95.147.158.93 #12: STATE_QUICK_R2: IPsec SA established transport mode {ESP/NAT=>0xdd5c8521 <0x83ffede6 xfrm=AES_CBC_128-HMAC_SHA1_96 NATOA=192.168.1.10 NATD=95.147.158.93:4500 DPD=passive}

server side journalctl log when attempting 2nd client connectionL

Code:

Apr 06 23:08:50 ubuntu-s-1vcpu-1gb-lon1-01 pluto[11681]: packet from 95.147.158.93:500: ignoring unknown Vendor ID payload [01528bbbc00696121849ab9a1c5b2a5100000001]
Apr 06 23:08:50 ubuntu-s-1vcpu-1gb-lon1-01 pluto[11681]: "l2tp-psk"[6] 95.147.158.93 #13: responding to Main Mode from unknown peer 95.147.158.93 on port 500
Apr 06 23:08:50 ubuntu-s-1vcpu-1gb-lon1-01 pluto[11681]: "l2tp-psk"[6] 95.147.158.93 #13: WARNING: connection l2tp-psk PSK length of 4 bytes is too short for sha PRF in FIPS mode (10 bytes required)
Apr 06 23:08:50 ubuntu-s-1vcpu-1gb-lon1-01 pluto[11681]: "l2tp-psk"[6] 95.147.158.93 #13: STATE_MAIN_R1: sent MR1, expecting MI2
Apr 06 23:08:50 ubuntu-s-1vcpu-1gb-lon1-01 pluto[11681]: "l2tp-psk"[6] 95.147.158.93 #13: STATE_MAIN_R2: sent MR2, expecting MI3
Apr 06 23:08:50 ubuntu-s-1vcpu-1gb-lon1-01 pluto[11681]: "l2tp-psk"[6] 95.147.158.93 #13: Peer ID is ID_IPV4_ADDR: '192.168.1.197'
Apr 06 23:08:50 ubuntu-s-1vcpu-1gb-lon1-01 pluto[11681]: "l2tp-psk"[6] 95.147.158.93 #13: STATE_MAIN_R3: sent MR3, ISAKMP SA established {auth=PRESHARED_KEY cipher=aes_256 integ=sha group=DH20}
Apr 06 23:08:50 ubuntu-s-1vcpu-1gb-lon1-01 pluto[11681]: "l2tp-psk"[6] 95.147.158.93 #13: the peer proposed: a.a.a.a/32:17/1701 -> 192.168.1.197/32:17/1701
Apr 06 23:08:50 ubuntu-s-1vcpu-1gb-lon1-01 pluto[11681]: "l2tp-psk"[6] 95.147.158.93 #13: NAT-Traversal: received 2 NAT-OA. Using first, ignoring others
Apr 06 23:08:50 ubuntu-s-1vcpu-1gb-lon1-01 pluto[11681]: "l2tp-psk"[7] 95.147.158.93 #14: responding to Quick Mode proposal {msgid:01000000}
Apr 06 23:08:50 ubuntu-s-1vcpu-1gb-lon1-01 pluto[11681]: "l2tp-psk"[7] 95.147.158.93 #14:     us: a.a.a.a<a.a.a.a>:17/1701
Apr 06 23:08:50 ubuntu-s-1vcpu-1gb-lon1-01 pluto[11681]: "l2tp-psk"[7] 95.147.158.93 #14:   them: 95.147.158.93:17/1701===192.168.1.197/32
Apr 06 23:08:50 ubuntu-s-1vcpu-1gb-lon1-01 pluto[11681]: "l2tp-psk"[7] 95.147.158.93 #14: STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2 transport mode {ESP/NAT=>0x6a391b62 <0x5f8c0224 xfrm=AES_CBC_256-HMAC_SHA1_96 NATOA=192.168.1.197 NATD=95.147.158.93:1025 DPD=passive}
Apr 06 23:08:50 ubuntu-s-1vcpu-1gb-lon1-01 pluto[11681]: "l2tp-psk"[7] 95.147.158.93 #14: STATE_QUICK_R2: IPsec SA established transport mode {ESP/NAT=>0x6a391b62 <0x5f8c0224 xfrm=AES_CBC_256-HMAC_SHA1_96 NATOA=192.168.1.197 NATD=95.147.158.93:1025 DPD=passive}

looks pretty much the same, but the 2nd client forces the 1st client tunnel to collapse and the 2nd client cant connect either. A restart on the client of ipsec and xl2tpd is needed to restore sanity.

On the droplet firewall I have UDP 500, 4500, 1701 open and TCP 50 and 51 open.

Wondering if a super-network guru can advice if there any way to configure NAT-T and to debug it to see whats happening?

ferrari · 04-07-2020, 01:21 AM

This thread caught my attention as I use L2TP for colleagues to connect into our company network. We're generally out in the field using tethering or working from home using different networks, so not generally an issue for us.

Some good information here concerning firewall ports for VPN connectivity (including L2TP/IPSec)...
https://docs.microsoft.com/en-us/pre...ectedfrom=MSDN

ferrari · 04-07-2020, 03:34 AM

I don't have a good handle on the Linux VPN server components, but is there somewhere you can enforce UDP encapsulation? I note that it is mentioned here...

https://libreswan.org/man/ipsec.conf.5.html

Quote:

encapsulation

In some cases, for example when ESP packets are filtered or when a broken IPsec peer does not properly recognise NAT, it can be useful to force RFC-3948 encapsulation. In other cases, where IKE is NAT*(Aqed but ESP packets can or should flow without encapsulation, it can be useful to ignore the NAT-Traversal auto-detection. encapsulation=yes forces the NAT detection code to lie and tell the remote peer that RFC-3948 encapsulation (ESP in port 4500 packets) is required. encapsulation=no ignores the NAT detection causing ESP packets to send send without encapsulation. The default value of encapsulation=auto follows the regular outcome of the NAT auto-detection code performed in IKE. This option replaced the obsoleted forceencaps option.

My apologies if I'm on the wrong track with this.

setdet · 04-07-2020, 12:07 PM

That's an old version pal. Encapsulated is deprecated.

Hey, thanks for trying tho

Quote:

Originally Posted by ferrari

I don't have a good handle on the Linux VPN server components, but is there somewhere you can enforce UDP encapsulation? I note that it is mentioned here...

https://libreswan.org/man/ipsec.conf.5.html

My apologies if I'm on the wrong track with this.

setdet · 04-07-2020, 12:09 PM

The digital ocean droplet is behind the cloud firewall so the ports are open on that side.

Quote:

Originally Posted by ferrari

This thread caught my attention as I use L2TP for colleagues to connect into our company network. We're generally out in the field using tethering or working from home using different networks, so not generally an issue for us.

Some good information here concerning firewall ports for VPN connectivity (including L2TP/IPSec)...
https://docs.microsoft.com/en-us/pre...ectedfrom=MSDN

ferrari · 04-07-2020, 04:44 PM

Quote:

That's an old version pal. Encapsulated is deprecated.

Ok, I guess you mean 'IPSec-over-UDP'. NAT-T is using UDP encapsulation as well (albeit via dedicated port 4500).

Code:

packet from 95.147.158.93:500: ignoring unknown Vendor ID payload [01528bbbc00696121849ab9a1c5b2a5100000001]

This does indeed suggest an issue with activation of the second concurrent client. Hard to debug from a distance and without your config files, versions etc. You could use wireshark to capture/inspect the packets.

All I can really suggest to help progress this is posting on the libreswan.org mailing list.

BTW, is using OpenVPN a pragmatic option for you?

Good luck.

setdet · 04-07-2020, 05:12 PM

No, you're helping now thanks...

Erm, so config files, well there's about 7 each side, so 14. I didnt want to post 14 config files unless necessary. I've no idea whether IPsec is doing this or that. I'm not an expert in this domain. Software dev is my forte and not in IP but in SQL/Oracle and Forms. I'm confused. Because much of the net is peppered with reports of only being able to connect through one client behind a NAT (router in my case) , and , other reports about being able to use NAT-T to overcome this. Which one is true and can I get two clients on my LAN to connect to the VPN server over IPsec (libreswan and xl2tpd latest packages in ubuntu 18.04) ? And is so, how ?

Quote:

Originally Posted by ferrari

Ok, I guess you mean 'IPSec-over-UDP'. NAT-T is using UDP encapsulation as well (albeit via dedicated port 4500).

Code:

packet from 95.147.158.93:500: ignoring unknown Vendor ID payload [01528bbbc00696121849ab9a1c5b2a5100000001]

This does indeed suggest an issue with activation of the second concurrent client. Hard to debug from a distance and without your config files, versions etc. You could use wireshark to capture/inspect the packets.

All I can really suggest to help progress this is posting on the libreswan.org mailing list.

BTW, is using OpenVPN a pragmatic option for you?

Good luck.

ferrari · 04-07-2020, 09:42 PM

This stackexchange thread asks " Is it possible to have remote access clients (road warriors) all behind the same NAT device?"

In particular one comment (quoted below) seemed interesting to me....

Quote:

The two projects are actually quite different. And multiple clients behind the same NAT should work fine with NAT-T unless your NAT device does something strange (or you use transport mode), as e.g. in this strongSwan example showing two hosts behind the same NAT. You should provide more information on the issues you are seeing (e.g. where and which packets are dropped or don't reach the right host). – ecdsa May 13 '16 at 5:12

The logs you shared show that you appear to be using 'transport mode'. IPsec Transport mode is implemented for client-to-site VPN connectivity, and NAT-T is not supported for this mode. You likely need 'tunnel mode' (the default). I note the manpage (man ipsec.conf) mentions

Quote:

type = tunnel | transport | transport_proxy | passthrough | drop

the type of the connection; currently the accepted values are tunnel (the default) signifying a host-to-host, host-to-subnet, or subnet-to-subnet tunnel; transport, signifying host-to-host transport mode; transport_proxy, signifying the special Mobile IPv6 transport proxy mode; passthrough, signifying that no IPsec processing should be done at all; drop, signifying that packets should be discarded.

ferrari · 04-07-2020, 09:53 PM

More info...
IPSec Tunnel Mode
IPSec Transport Mode
These show how the encapsulation is done with each mode

A good technical overview here as well...
https://www.linuxjournal.com/article/9916

setdet · 04-08-2020, 05:32 PM

Many thanks @ferrari - that was extremely useful.

I followed that example - alice and sun in my case. It all works with the same configs (bar I use PSK not Certs) but only when I use transport on the client (alice) side. If I use tunnel then the ppp0 interface isnt created and neither alice nor sun can ping each other? Any ideas?

on my setup "alice" is 192.168.1.10 behind my ISP router. On the VPN its client IP is 192.168.2.10
"sun" is my digital ocean public IP d.d.d.d and its VPN is is 192.168.2.1

"Sun" /etc/ipsec.conf

Code:

version 2.0

config setup
#  virtual-private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:!192.168.42.0/24,%v4:!192.168.2.0/24
#  protostack=netkey
#  interfaces=%defaultroute
#  uniqueids=no

conn l2tp-psk
  auto=add
  leftfirewall=yes
  leftsubnet=192.168.2.0/24
  leftprotoport=17/1701
  rightprotoport=17/%any
  type=tunnel
#  phase2=esp
  also=shared

conn xauth-psk
  auto=add
  leftsubnet=0.0.0.0/0
  rightaddresspool=192.168.2.10-192.168.2.20
  modecfgdns="8.8.8.8 8.8.4.4"
  leftxauthserver=yes
  rightxauthclient=yes
  leftmodecfgserver=yes
  rightmodecfgclient=yes
  modecfgpull=yes
  xauthby=file
  ike-frag=yes
  cisco-unity=yes
  also=shared

"sun" /etc/strongswan.conf

Code:

charon {
  load = random nonce aes sha1 sha2 pem pkcs1 curve25519 gmp x509 curl revocatio     n hmac stroke kernel-netlink socket-default updown
}

"alice" /etc/ipsec.conf

Code:

config setup
  # strictcrlpolicy=yes
  # uniqueids = no

conn %default
  ikelifetime=60m
  keylife=20m
  rekeymargin=3m
  keyingtries=1
  keyexchange=ikev1
  authby=secret
  ike=aes128-sha1-modp2048!
  esp=aes128-sha1-modp2048!

conn myvpn
  keyexchange=ikev1
  left=%defaultroute
  auto=add
  authby=secret

#--DOES NOT BRING UP ppp0
  #type=tunnel

#--ppp0 CREATED AND ALL WORKS
  type=transport

  leftprotoport=17/1701
  rightprotoport=17/1701
  right=d.d.d.d

"sun" /etc/strongswan.conf

Code:

charon {
  load = random nonce aes sha1 sha2 pem pkcs1 curve25519 gmp x509 curl revocation hmac stroke kernel-netlink socket-default updown

  keep_alive = 5
}

LOG FiLES (filtered to include only charon):----

"alice"

Code:

Apr  8 23:25:03 pi ipsec[10762]: 00[DMN] Starting IKE charon daemon (strongSwan 5.7.2, Linux 4.19.97-v7+, armv7l)
Apr  8 23:25:03 pi ipsec[10762]: 00[LIB] loaded plugins: charon random nonce aes sha1 sha2 pem pkcs1 gmp x509 revocation hmac stroke kernel-netlink socket-default updown
Apr  8 23:25:03 pi ipsec[10762]: charon stopped after 200 ms
Apr  8 23:25:04 pi ipsec[10817]: !! Your strongswan.conf contains manual plugin load options for charon.
Apr  8 23:25:04 pi charon: 00[DMN] Starting IKE charon daemon (strongSwan 5.7.2, Linux 4.19.97-v7+, armv7l)
Apr  8 23:25:04 pi charon: 00[CFG] loading ca certificates from '/etc/ipsec.d/cacerts'
Apr  8 23:25:04 pi charon: 00[CFG] loading aa certificates from '/etc/ipsec.d/aacerts'
Apr  8 23:25:04 pi charon: 00[CFG] loading ocsp signer certificates from '/etc/ipsec.d/ocspcerts'
Apr  8 23:25:04 pi charon: 00[CFG] loading attribute certificates from '/etc/ipsec.d/acerts'
Apr  8 23:25:04 pi charon: 00[CFG] loading crls from '/etc/ipsec.d/crls'
Apr  8 23:25:04 pi charon: 00[CFG] loading secrets from '/etc/ipsec.secrets'
Apr  8 23:25:04 pi ipsec[10817]: charon (10839) started after 20 ms
Apr  8 23:25:04 pi charon: 00[CFG]   loaded IKE secret for %any
Apr  8 23:25:04 pi charon: 00[LIB] loaded plugins: charon random nonce aes sha1 sha2 pem pkcs1 gmp x509 revocation hmac stroke kernel-netlink socket-default updown
Apr  8 23:25:04 pi charon: 00[LIB] dropped capabilities, running as uid 0, gid 0
Apr  8 23:25:04 pi charon: 00[JOB] spawning 16 worker threads
Apr  8 23:25:04 pi charon: 05[CFG] received stroke: add connection 'myvpn'
Apr  8 23:25:04 pi charon: 05[CFG] added configuration 'myvpn'
Apr  8 23:25:04 pi charon: 05[CFG] received stroke: initiate 'myvpn'
Apr  8 23:25:04 pi charon: 07[IKE] initiating Main Mode IKE_SA myvpn[1] to d.d.d.d
Apr  8 23:25:04 pi charon: 07[ENC] generating ID_PROT request 0 [ SA V V V V V ]
Apr  8 23:25:04 pi charon: 07[NET] sending packet: from 192.168.1.10[500] to d.d.d.d[500] (180 bytes)
Apr  8 23:25:04 pi charon: 08[NET] received packet: from d.d.d.d[500] to 192.168.1.10[500] (144 bytes)
Apr  8 23:25:04 pi charon: 08[ENC] parsed ID_PROT response 0 [ SA V V V ]
Apr  8 23:25:04 pi charon: 08[IKE] received FRAGMENTATION vendor ID
Apr  8 23:25:04 pi charon: 08[IKE] received DPD vendor ID
Apr  8 23:25:04 pi charon: 08[IKE] received NAT-T (RFC 3947) vendor ID
Apr  8 23:25:04 pi charon: 08[CFG] selected proposal: IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
Apr  8 23:25:04 pi charon: 08[ENC] generating ID_PROT request 0 [ KE No NAT-D NAT-D ]
Apr  8 23:25:04 pi charon: 08[NET] sending packet: from 192.168.1.10[500] to d.d.d.d[500] (372 bytes)
Apr  8 23:25:04 pi charon: 09[NET] received packet: from d.d.d.d[500] to 192.168.1.10[500] (372 bytes)
Apr  8 23:25:04 pi charon: 09[ENC] parsed ID_PROT response 0 [ KE No NAT-D NAT-D ]
Apr  8 23:25:04 pi charon: 09[IKE] local host is behind NAT, sending keep alives
Apr  8 23:25:04 pi charon: 09[IKE] remote host is behind NAT
Apr  8 23:25:04 pi charon: 09[ENC] generating ID_PROT request 0 [ ID HASH N(INITIAL_CONTACT) ]
Apr  8 23:25:04 pi charon: 09[NET] sending packet: from 192.168.1.10[4500] to d.d.d.d[4500] (108 bytes)
Apr  8 23:25:04 pi charon: 10[NET] received packet: from d.d.d.d[4500] to d.d.d.d[4500] (76 bytes)
Apr  8 23:25:04 pi charon: 10[ENC] parsed ID_PROT response 0 [ ID HASH ]
Apr  8 23:25:04 pi charon: 10[IKE] IKE_SA myvpn[1] established between 192.168.1.10[192.168.1.10]...d.d.d.d[d.d.d.d]
Apr  8 23:25:04 pi charon: 10[IKE] scheduling reauthentication in 3281s
Apr  8 23:25:04 pi charon: 10[IKE] maximum IKE_SA lifetime 3461s
Apr  8 23:25:04 pi charon: 10[ENC] generating QUICK_MODE request 3578867426 [ HASH SA No KE ID ID NAT-OA NAT-OA ]
Apr  8 23:25:04 pi charon: 10[NET] sending packet: from 192.168.1.10[4500] to d.d.d.d[4500] (460 bytes)
Apr  8 23:25:04 pi charon: 11[NET] received packet: from d.d.d.d[4500] to 192.168.1.10[4500] (428 bytes)
Apr  8 23:25:04 pi charon: 11[ENC] parsed QUICK_MODE response 3578867426 [ HASH SA No KE ID ID ]
Apr  8 23:25:04 pi charon: 11[CFG] selected proposal: ESP:AES_CBC_128/HMAC_SHA1_96/MODP_2048/NO_EXT_SEQ
Apr  8 23:25:04 pi charon: 11[IKE] CHILD_SA myvpn{1} established with SPIs cd578759_i 9e40ed4e_o and TS 192.168.1.10/32[udp/l2f] === 161.35.36.182/32[udp/l2f]
Apr  8 23:25:04 pi charon: 11[ENC] generating QUICK_MODE request 3578867426 [ HASH ]
Apr  8 23:25:04 pi charon: 11[NET] sending packet: from 192.168.1.10[4500] to 161.35.36.182[4500] (60 bytes)
Apr  8 23:25:04 pi charon: 14[KNL] 192.168.2.10 appeared on ppp0
Apr  8 23:25:04 pi charon: 15[KNL] 192.168.2.10 disappeared from ppp0
Apr  8 23:25:04 pi charon: 16[KNL] 192.168.2.10 appeared on ppp0
Apr  8 23:25:04 pi charon: 16[KNL] interface ppp0 activated
Apr  8 23:25:13 pi charon: 08[IKE] sending keep alive to d.d.d.d[4500]

"sun"

Code:

Apr  8 22:25:04 ubuntu-s-1vcpu-1gb-lon1-01 xl2tpd[32479]: start_pppd: I'm running:
Apr  8 22:25:04 ubuntu-s-1vcpu-1gb-lon1-01 xl2tpd[32479]: "/usr/sbin/pppd"
Apr  8 22:25:04 ubuntu-s-1vcpu-1gb-lon1-01 xl2tpd[32479]: "/dev/pts/0"
Apr  8 22:25:04 ubuntu-s-1vcpu-1gb-lon1-01 xl2tpd[32479]: "passive"
Apr  8 22:25:04 ubuntu-s-1vcpu-1gb-lon1-01 xl2tpd[32479]: "nodetach"
Apr  8 22:25:04 ubuntu-s-1vcpu-1gb-lon1-01 xl2tpd[32479]: "192.168.2.1:192.168.2.10"
Apr  8 22:25:04 ubuntu-s-1vcpu-1gb-lon1-01 xl2tpd[32479]: "refuse-pap"
Apr  8 22:25:04 ubuntu-s-1vcpu-1gb-lon1-01 xl2tpd[32479]: "auth"
Apr  8 22:25:04 ubuntu-s-1vcpu-1gb-lon1-01 xl2tpd[32479]: "require-chap"
Apr  8 22:25:04 ubuntu-s-1vcpu-1gb-lon1-01 xl2tpd[32479]: "name"
Apr  8 22:25:04 ubuntu-s-1vcpu-1gb-lon1-01 xl2tpd[32479]: "l2tpd"
Apr  8 22:25:04 ubuntu-s-1vcpu-1gb-lon1-01 xl2tpd[32479]: "file"
Apr  8 22:25:04 ubuntu-s-1vcpu-1gb-lon1-01 xl2tpd[32479]: "/etc/ppp/options.xl2tpd"
Apr  8 22:25:04 ubuntu-s-1vcpu-1gb-lon1-01 xl2tpd[32479]: Call established with 95.147.158.93, PID: 790, Local: 32885, Remote: 33674, Serial: 1
Apr  8 22:25:04 ubuntu-s-1vcpu-1gb-lon1-01 pppd[790]: pppd 2.4.7 started by root, uid 0
Apr  8 22:25:04 ubuntu-s-1vcpu-1gb-lon1-01 pppd[790]: Using interface ppp0
Apr  8 22:25:04 ubuntu-s-1vcpu-1gb-lon1-01 pppd[790]: Connect: ppp0 <--> /dev/pts/0
Apr  8 22:25:04 ubuntu-s-1vcpu-1gb-lon1-01 systemd-udevd[791]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
Apr  8 22:25:04 ubuntu-s-1vcpu-1gb-lon1-01 networkd-dispatcher[835]: WARNING:Unknown index 29 seen, reloading interface list
Apr  8 22:25:04 ubuntu-s-1vcpu-1gb-lon1-01 systemd-timesyncd[10778]: Network configuration changed, trying to establish connection.
Apr  8 22:25:04 ubuntu-s-1vcpu-1gb-lon1-01 systemd-timesyncd[10778]: Synchronized to time server 91.189.94.4:123 (ntp.ubuntu.com).
Apr  8 22:25:04 ubuntu-s-1vcpu-1gb-lon1-01 pppd[790]: Cannot determine ethernet address for proxy ARP
Apr  8 22:25:04 ubuntu-s-1vcpu-1gb-lon1-01 pppd[790]: local  IP address 192.168.2.1
Apr  8 22:25:04 ubuntu-s-1vcpu-1gb-lon1-01 pppd[790]: remote IP address 192.168.2.10
Apr  8 22:25:04 ubuntu-s-1vcpu-1gb-lon1-01 systemd-networkd[10747]: ppp0: Link UP
Apr  8 22:25:04 ubuntu-s-1vcpu-1gb-lon1-01 systemd-networkd[10747]: ppp0: Gained carrier
Apr  8 22:25:04 ubuntu-s-1vcpu-1gb-lon1-01 systemd-timesyncd[10778]: Network configuration changed, trying to establish connection.
Apr  8 22:25:04 ubuntu-s-1vcpu-1gb-lon1-01 systemd-timesyncd[10778]: Synchronized to time server 91.189.94.4:123 (ntp.ubuntu.com).

At least now if another client say "bob" behind my ISP (public IP = 95.147.158.93) tried to connect , it doesnt bring the tunnel down and disconnect the 1st client. That's what happened before. However, the 2nd client still cannot connect. Either client "alice" or "bob" can connect, but not together. Any client not behind my NAT can connect. So NAT-T isnt working ??

I grabbed a fewlines from "sun" syslog, noting that it creates a transport connection not tunnel ?

Code:

Apr 08 22:51:35 ubuntu-s-1vcpu-1gb-lon1-01 pluto[29829]: "l2tp-psk"[57] 95.147.158.93 #111: STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2 transport mode {ESP/NAT=>0xc7da955a <0xd6887ae7 xfrm=AES_CBC_128-HMAC_SHA1_96 NATOA=none NATD=95.147.158.93:4500 DPD=active}
Apr 08 22:51:35 ubuntu-s-1vcpu-1gb-lon1-01 pluto[29829]: "l2tp-psk"[57] 95.147.158.93 #111: STATE_QUICK_R2: IPsec SA established transport mode {ESP/NAT=>0xc7da955a <0xd6887ae7 xfrm=AES_CBC_128-HMAC_SHA1_96 NATOA=none NATD=95.147.158.93:4500 DPD=active}

ferrari · 04-09-2020, 03:53 AM

Quote:

I followed that example - alice and sun in my case. It all works with the same configs (bar I use PSK not Certs) but only when I use transport on the client (alice) side. If I use tunnel then the ppp0 interface isnt created and neither alice nor sun can ping each other? Any ideas?

Okay, you lost me a bit here. Which URL/example are you referring to? Did you switch from using libreswan to strongswan?

I'm at the limits of my knowledge with this, but AFAIU you don't want to mix IPSec modes.

ferrari · 04-09-2020, 04:27 AM

Just a suggestion: Consider using OpenVPN instead...
https://ubuntu.com/server/docs/service-openvpn

setdet · 04-09-2020, 05:08 PM

Hi pal

I am referring to the URL (link) to the Alice/Sun/Moon etc. you provided, above ???? remember

I switched to swanstrong . yes , it just doesnt work as per that link. I cant connect two clients behind my router - if I do , it drops the tunnel. Either client works alone, but not together.
I do have one separate aspect, I am using a PSK not Certs. But that is authentication and not setting up the tunnel.
I cannot believe this hasn't been done before and someone doesnt have a simple config. But searching the net, it seems to be that this is "new". Unbelievable. I've read ipsec man and xl2tdp man, but I cannot get it to work.

You mention OpenVPN -but that is very very sloooow. There's a lot of marketing hype around OpenVPN and its "speed", but I've never experienced anything near comparable speeds compared to IPsec/L2TP and I've seen it used in many scenarios in many sites. For example, and after "tuning", the best I could get on my 80Mbps broadband, was 20Mpbs - paltry - but IPsec/L2TP gives a shining 72Mpbs. Without any VPN, I get about 78Mpbs. So no, no thanks to OpenVPN.

Now, what is interesting is that I setup an *almost* successful SoftEther install and used its IPsec/LT2PD. However, it doesnt use/modify the usual IPsec/L2TP/PPP config files - if it did then I could have pinched them and used them. 55Mpbs speed through the VPN was ok-ish but not great. Plus,the *almost* well I could get an IPV6 address but never an IPV4 when doing NAT-T. And I need IPV4 IP. So SoftEther was almost but not quite, good enough.

I just cannot believe that IPsec/LT2P has never been used to get two clients concurrent connections working behind a router.

Where else could I go ???

ferrari · 04-09-2020, 06:21 PM

Quote:

Originally Posted by setdet

Hi pal

I am referring to the URL (link) to the Alice/Sun/Moon etc. you provided, above ???? remember

I had to trawl through the links I provided to find that it was a link within the page I linked to.

Quote:

I switched to swanstrong . yes , it just doesnt work as per that link. I cant connect two clients behind my router - if I do , it drops the tunnel. Either client works alone, but not together.
I do have one separate aspect, I am using a PSK not Certs. But that is authentication and not setting up the tunnel.
I cannot believe this hasn't been done before and someone doesnt have a simple config. But searching the net, it seems to be that this is "new". Unbelievable. I've read ipsec man and xl2tdp man, but I cannot get it to work.

Yeah, I can't really add anything further here. I have L2TP/IPSec configured on Linux and Windows clients (with a Mikrotik firewall acting as the server), but I'm not using NAT-T.

Quote:

You mention OpenVPN -but that is very very sloooow. There's a lot of marketing hype around OpenVPN and its "speed", but I've never experienced anything near comparable speeds compared to IPsec/L2TP and I've seen it used in many scenarios in many sites. For example, and after "tuning", the best I could get on my 80Mbps broadband, was 20Mpbs - paltry - but IPsec/L2TP gives a shining 72Mpbs. Without any VPN, I get about 78Mpbs. So no, no thanks to OpenVPN.

Ok, fair enough. It depends on your use case I guess. I don't require anything like that speed.

Quote:

I just cannot believe that IPsec/LT2P has never been used to get two clients concurrent connections working behind a router.

Yes, I agree it is surprising and a bit disappointing.

Quote:

Where else could I go ???

One suggestion I gave back in post #6...

Quote:

All I can really suggest to help progress this is posting on the libreswan.org mailing list.

ferrari · 04-09-2020, 06:25 PM

I still wondered about the EE-supplied router and how it might be impacting here. You might try changing that for a more sophisticated/configurable model perhaps.