Climax777 commented 9 years ago

Hello

I want to ask how to configure/use xl2tpd with strongswan in the scenario that there are multiple clients connecting from behind the same NAT.

What happens now is that when multiple units connect, one or more of them stop working and time out. Packet traces show that no packets come in after a while.

I use mark=%unique with strongswan and the rules are being applied. How can I configure x2ltpd to use these marks to forward to the correct NATed client?

Currently all of them connect to xl2tpd with the same public ip with source port 1701.

Can I use some mangling rule or something to mangle the source ip/port? Can I use SAref or connmark directly in xl2tpd?

Currently the strongswan phase is working perfectly, I just can't get the second phase (L2TP) stable.

mcr commented 9 years ago

Pieter Jordaan notifications@github.com wrote:

I want to ask how to configure/use xl2tpd with strongswan in the scenario that there are multiple clients connecting from behind the same NAT.

> What happens now is that when multiple units connect, one or more of
> them stop working and time out. Packet traces show that no packets come
> in after a while.

Yes, so with L2TP, there are transport mode IPsec tunnels, and they occur from the IP address of the machine behind the NAT. So they all come from "192.168.1.101" (the first IP that a linksys router usually gives out), and they conflict.

The answer is that you have to have kernel code that can sort it out (KLIPS), or you can now do some netfilter magic to make it happen.

I suggest that you look into what libreswan documents today for the netfilter magic.

> I use mark=%unique with strongswan and the rules are being applied. How
> can I configure x2ltpd to use these marks to forward to the correct
> NATed client?

> Currently all of them connect to xl2tpd with the same public ip with
> source port 1701.

I don't know what mark=%unique does.

] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [

Climax777 commented 9 years ago

The Ipsec part is sorted out by the mark=%unique settings. This enables special netfilter entries to be made that fixes the problem. https://wiki.strongswan.org/projects/strongswan/wiki/Connmark

However I'm not sure if it just works with xl2tp or if some special sauce is needed, because after decapsulation the source ip is the public ip of the nat with 1701 as source port.

So I'm not sure where packets sent to this address will go because all natted clients will have that same ip/port except for the netfilter marks.

Climax777 commented 9 years ago

Here is an excerpt from the iptables after connmark usage:

*mangle :PREROUTING ACCEPT [1765:398811] :INPUT ACCEPT [1485:299604] :FORWARD ACCEPT [278:98818] :OUTPUT ACCEPT [1406:319822] :POSTROUTING ACCEPT [1684:418640] -A PREROUTING -s 41.13.28.224/32 -d 172.30.0.143/32 -p udp -m udp --sport 54696 --dport 4500 -j MARK --set-xmark 0x1dd/0xffffffff -A PREROUTING -s 197.77.18.170/32 -d 172.30.0.143/32 -p udp -m udp --sport 10518 --dport 4500 -j MARK --set-xmark 0x1dc/0xffffffff -A INPUT -s 41.13.28.224/32 -d 172.30.0.143/32 -m policy --dir in --pol ipsec --spi 0x81329dc3 -j CONNMARK --set-xmark 0x1dd/0xffffffff -A INPUT -s 197.77.18.170/32 -d 172.30.0.143/32 -m policy --dir in --pol ipsec --spi 0x489ba5cf -j CONNMARK --set-xmark 0x1dc/0xffffffff -A OUTPUT -s 172.30.0.143/32 -d 41.13.28.224/32 -j CONNMARK --restore-mark --nfmask 0xffffffff --ctmask 0xffffffff -A OUTPUT -s 172.30.0.143/32 -d 197.77.18.170/32 -j CONNMARK --restore-mark --nfmask 0xffffffff --ctmask 0xffffffff

gulikoza commented 8 years ago

Hi,

I've managed to make this working. There's a few issues on the strongswan side, which I have sorted out (see issues 1212, 1229, 1230 on the strongswan tracker) but xl2tpd also needs to support it. Fortunately unlike SAref, no kernel patching is needed.

What is needed is setting up NFQUEUE and parsing control packets inside xl2tpd so that netfilter mark is matched to a specific tunnel. After correct mark is extracted from the incoming packets, the same mark is used on replies (using SO_MARK on the socket).

Here's my WIP patch that sets up NFQUEUE handling and sending packets with proper mark. You also need to add iptables rule that will redirect l2tp control packets into proper NFQUEUE:

iptables -t mangle -A INPUT -p udp -m l2tp --type control --dport 1701 -m policy --strict --dir in --pol ipsec --proto esp -j NFQUEUE --queue-num 0 --queue-bypass

(l2tp match is in the kernel, but it's not in iptables - I had to patch that separately...xl2tpd could be made to directly insert rule into the kernel in which case iptables would not have to be patched; additionally a config option for setting a NFQUEUE number could be set ;-) )

999-nfqeueue.txt

gulikoza commented 8 years ago

Is there any interest in this? I'm willing to work on the code further...but I don't know that much about l2tp protocol.

There's still some potential problems I see:

the first reply packet is not marked as the first request packet does not have a tunnel id yet...
race conditions (two clients from the same NAT IP connect at (almost) the same time)?
is there a better way to identify which mark belongs to what tunnel?
SO_MARK needs CAP_NET_ADMIN...not a problem on an embedded system like OpenWRT, but other uses?
performance implications (parsing packets and setting marks)?

gulikoza commented 7 years ago

@shussain Did you have a chance to review this...it would be great if xl2tpd would support this setup :-)

shussain commented 7 years ago

@gulikoza I am interested in integrating this but right now I am a bit busy. I am hoping to make time later this week to further look at the commit.

shussain commented 7 years ago

@gulikoza Is 999-nfqueue.txt the latest version of your code?

I think it could be integrated as a configuration or possibly preproc. That way, the performance implications do not impact regular users. Would you be able to do that?

gulikoza commented 7 years ago

That is the latest version, more or less...I think I've updated it for 1.3.9 recently, but just minor changes because of differences in existing code.

I don't think there should be any performance implications. If nfqueue is not set (for which a config option should be added), the hook is not set in init_network() and no other code runs (apart for 1 'if()' in udp_xmit). The performance implications I mentioned are when nfqueue is active (because each control packet in then queued by iptables and processed by nfq_q_handle()).

I don't really like parsing control packets for tunel_id in the nfq_q_handle()...is there any better way to do it? :)

I'll prepare some changes and do a PR.

bradjohn commented 7 years ago

We are using strongSwan version 5.5.3 along with xl2tpd version 1.3.10 as an L2TP server. We are using the strongSwan connmark plugin, so it now handles multiple windows clients behind the same NAT IP from an IPSec point of view. But even with the 999-nfqueue patch applied to xl2tpd I can not connect 2 L2TP clients and have them both stay up. Behavior varies, but usually the second one attempting to connect will hang 'Verifying user and password', and eventually the xl2tpd on the server will report 'Maximum retries exceeded for tunnel...' and will terminate the pppd. Sometimes they will both connect for a period of time but one or both will eventually get disconnected. So I am curious what the status of this strongSwan integration issue (this issue and #123) is, and would appreciate any suggestions.

shussain commented 7 years ago

@bradjohn We don't specifically test for StrongSwan integration.

gulikoza commented 7 years ago

@bradjohn Did you setup the NFQUEUE iptables rule? Although I have experienced intermittent disconnects as well...haven't had the time yet to diagnose the issue that's why I haven't posted a PR yet...

bradjohn commented 7 years ago

@gulikoza yes, thanks. I see now I am missing some things. I have no kernel xt_l2tp module, and I'm not sure of the iptables l2tp patch I'm using, found here: https://patchwork.ozlabs.org/patch/307177/

So I have some work to do before being able to fully use the NFQUEUE

martking1 commented 7 years ago

Hi All

I Have been reading this thread with great interest as I am in need of the nfqeueue patch. I have a fully running IPSEC/L2TP server running using Libreswan as the IPSEC server but I've never had to patch anything like this before would someone please be able to tell me how i can patch this

flyjohnji commented 6 years ago

Hi @gulikoza @shussain , Thank you for this xl2tpd patch, and I have tested it in Linux-3.10.0-514, it works very good. 👍 But when I tested it in CentOS6.9(Linux-2.6.32-696), it failed to establish l2tp connection while ipsec is established successfully. xl2tpd receive packet SCCRQ, and send back packet SCCRP, but l2tp SCCRP packet is sent directly to client, and not in ESP, that is to say the first l2tp packet form server to client is not go through XFRM. So my question is :

it is because "the first reply packet is not marked as the first request packet does not have a tunnel id yet..." as you have list before, so the first packet back to client have no xfrm mark value?
Is this xl2tpd patch work with Specified Linux Kernel, not suppurt Linux 2.6.X?

Thank you very much.

gulikoza commented 6 years ago

Hi,

If the packet is not marked, then the default strongswan CONNMARK rule should be able to match and mark it appropriately. If you check the mangle table, the connmark strongswan module inserts a bunch of rules, one of them should be:

Chain OUTPUT (policy ACCEPT 99130 packets, 32M bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 CONNMARK   all  --  *      *       xx.xx.xx.xx        xx.xx.xx.xx         mark match 0x0 CONNMARK restore

So the idea is that the first packet is handled by these default rules until the packets can be explicitly marked in xl2tpd. I don't think the patch should be kernel specific. What strongswan version do you use?

kis1yi commented 2 years ago

Hi @gulikoza @shussain , It looks like the patch doesn't work with actual packages. My VPS with CentOS 7 has the following installed (IPSec PSK + L2TP):

kernel - 3.10.0-1160.59.1.el7.x86_64, added xt_l2tp module
ppp - 2.4.5-34.el7_7.x86_64
xl2tpd - 1.3.15-1.el7.x86_64, patched with 999-nfqeueue.txt
strongswan - 5.9.5, compiled with ./configure --prefix=/usr --sysconfdir=/etc --enable-connmark
iptables - 1.4.21-35.el7.x86_64, patched with this, added rule iptables -t mangle -A INPUT -p udp -m l2tp --type control --dport 1701 -m policy --strict --dir in --pol ipsec --proto esp -j NFQUEUE --queue-num 0 --queue-bypass

When I connect one windows computer and an unlimited number of ios devices at the same time, VPN works perfectly on all devices. When connecting a second windows computer, xl2tpd gives a lot of errors write_packet: tty is not open yet and resets the connection of the first computer.

I have been trying to solve this problem for several days now. Help me please. Maybe needed a new version of the xl2tpd patch or I made a mistake in the config?

Below are my configs and outputs when connecting two windows computers. X.X.X.X - IP of VPS Y.Y.Y.Y - IP of my home router

ip a

```bash 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 52:54:00:98:d9:eb brd ff:ff:ff:ff:ff:ff inet X.X.X.X/22 brd 95.182.123.255 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::5054:ff:fe98:d9eb/64 scope link valid_lft forever preferred_lft forever 13: ppp0: mtu 1280 qdisc pfifo_fast state UNKNOWN group default qlen 3 link/ppp inet 10.0.1.1 peer 10.0.1.10/32 scope global ppp0 valid_lft forever preferred_lft forever 14: ppp1: mtu 1280 qdisc pfifo_fast state UNKNOWN group default qlen 3 link/ppp inet 10.0.1.1 peer 10.0.1.11/32 scope global ppp1 valid_lft forever preferred_lft forever ```

iptables -n -L -v -t mangle --line-numbers

```bash Chain PREROUTING (policy ACCEPT 38028 packets, 10M bytes) num pkts bytes target prot opt in out source destination 1 8571 3125K MARK udp -- * * Y.Y.Y.Y X.X.X.X udp spt:1024 dpt:4500 MARK set 0xf 2 7556 1349K MARK udp -- * * Y.Y.Y.Y X.X.X.X udp spt:4500 dpt:4500 MARK set 0xd Chain INPUT (policy ACCEPT 24329 packets, 6753K bytes) num pkts bytes target prot opt in out source destination 1 8567 2677K CONNMARK all -- * * Y.Y.Y.Y X.X.X.X policy match dir in pol ipsec spi 0x2a2740cb CONNMARK set 0xf 2 7543 954K CONNMARK all -- * * Y.Y.Y.Y X.X.X.X policy match dir in pol ipsec spi 0x96a8bbca CONNMARK set 0xd 3 139 8913 NFQUEUE udp -- * * 0.0.0.0/0 0.0.0.0/0 l2tp type control udp dpt:1701 policy match dir in pol ipsec strict proto 50 NFQUEUE num 0 bypass Chain FORWARD (policy ACCEPT 13525 packets, 3224K bytes) num pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 11279 packets, 3117K bytes) num pkts bytes target prot opt in out source destination 1 5607 1673K CONNMARK all -- * * X.X.X.X Y.Y.Y.Y mark match 0x0 CONNMARK restore 2 2446 1940K CONNMARK all -- * * X.X.X.X Y.Y.Y.Y mark match 0x0 CONNMARK restore Chain POSTROUTING (policy ACCEPT 24804 packets, 6341K bytes) num pkts bytes target prot opt in out source destination ```

ipsec statusall

```bash Status of IKE charon daemon (strongSwan 5.9.5, Linux 3.10.0-1160.59.1.el7.x86_64, x86_64): uptime: 5 days, since Mar 28 01:57:31 2022 malloc: sbrk 1449984, mmap 0, used 336832, free 1113152 worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 6 loaded plugins: charon aes des rc2 sha2 sha1 md5 mgf1 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem fips-prf gmp curve25519 xcbc cmac hmac drbg attr kernel-netlink resolve socket-default connmark stroke vici updown xauth-generic counters Listening IP addresses: X.X.X.X 10.0.1.1 10.0.1.1 Connections: l2tp-psk: X.X.X.X...%any IKEv1 l2tp-psk: local: [X.X.X.X] uses pre-shared key authentication l2tp-psk: remote: uses pre-shared key authentication l2tp-psk: child: dynamic[udp/l2tp] === dynamic[udp] TRANSPORT Security Associations (2 up, 0 connecting): l2tp-psk[31]: ESTABLISHED 95 seconds ago, X.X.X.X[X.X.X.X]...Y.Y.Y.Y[192.168.0.10] l2tp-psk[31]: IKEv1 SPIs: e6c862c24cc0dce8_i 994ac547af22a8de_r*, pre-shared key reauthentication in 53 minutes l2tp-psk[31]: IKE proposal: AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048 l2tp-psk{18}: INSTALLED, TRANSPORT, reqid 1, ESP in UDP SPIs: cb40272a_i 6f15db44_o l2tp-psk{18}: AES_CBC_256/HMAC_SHA1_96, 2579242 bytes_i (9093 pkts, 0s ago), 730664 bytes_o (3986 pkts, 0s ago), rekeying in 13 minutes l2tp-psk{18}: X.X.X.X/32[udp/l2tp] === Y.Y.Y.Y/32[udp/l2tp] l2tp-psk[29]: ESTABLISHED 4 minutes ago, X.X.X.X[X.X.X.X]...Y.Y.Y.Y[192.168.0.20] l2tp-psk[29]: IKEv1 SPIs: e86e2f2705076eea_i 7dd70f48f263529b_r*, pre-shared key reauthentication in 51 minutes l2tp-psk[29]: IKE proposal: AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048 l2tp-psk{15}: INSTALLED, TRANSPORT, reqid 2, ESP in UDP SPIs: cabba896_i 345a5326_o l2tp-psk{15}: AES_CBC_256/HMAC_SHA1_96, 832954 bytes_i (7950 pkts, 0s ago), 911574 bytes_o (4732 pkts, 0s ago), rekeying in 11 minutes l2tp-psk{15}: X.X.X.X/32[udp/l2tp] === Y.Y.Y.Y/32[udp/l2tp] ```

grep /var/log/messages -e 'xl2tpd'

```bash Apr 2 13:28:41 kis1yi xl2tpd: xl2tpd[3658]: NFLINK callback, len: 136 Apr 2 13:28:41 kis1yi xl2tpd: xl2tpd[3658]: Found UDP packet, size: 136 Apr 2 13:28:41 kis1yi xl2tpd: xl2tpd[3658]: Found Control packet Apr 2 13:28:41 kis1yi xl2tpd: xl2tpd[3658]: Found packet mark: 13 (tunnel_id: 0) Apr 2 13:28:41 kis1yi xl2tpd: xl2tpd[3658]: NFLINK callback, len: 48 Apr 2 13:28:41 kis1yi xl2tpd: xl2tpd[3658]: Found UDP packet, size: 48 Apr 2 13:28:41 kis1yi xl2tpd: xl2tpd[3658]: Found Control packet Apr 2 13:28:41 kis1yi xl2tpd: xl2tpd[3658]: Found packet mark: 13 (tunnel_id: 62546) Apr 2 13:28:41 kis1yi xl2tpd: xl2tpd[3658]: NFLINK callback, len: 40 Apr 2 13:28:41 kis1yi xl2tpd: xl2tpd[3658]: Found UDP packet, size: 40 Apr 2 13:28:41 kis1yi xl2tpd: xl2tpd[3658]: Found Control packet Apr 2 13:28:41 kis1yi xl2tpd: xl2tpd[3658]: Found packet mark: 13 (tunnel_id: 62546) Apr 2 13:28:41 kis1yi xl2tpd: xl2tpd[3658]: Connection established to Y.Y.Y.Y, 1701. Local: 62546, Remote: 1 (ref=0/0). LNS session is 'default' Apr 2 13:28:41 kis1yi xl2tpd: xl2tpd[3658]: NFLINK callback, len: 76 Apr 2 13:28:41 kis1yi xl2tpd: xl2tpd[3658]: Found UDP packet, size: 76 Apr 2 13:28:41 kis1yi xl2tpd: xl2tpd[3658]: Found Control packet Apr 2 13:28:41 kis1yi xl2tpd: xl2tpd[3658]: Found packet mark: 13 (tunnel_id: 62546) Apr 2 13:28:41 kis1yi xl2tpd: xl2tpd[3658]: check_control: Received out of order control packet on tunnel 1 (got 3, expected 2) Apr 2 13:28:41 kis1yi xl2tpd: xl2tpd[3658]: handle_control: bad control packet! Apr 2 13:28:41 kis1yi xl2tpd: xl2tpd[3658]: NFLINK callback, len: 76 Apr 2 13:28:41 kis1yi xl2tpd: xl2tpd[3658]: Found UDP packet, size: 76 Apr 2 13:28:41 kis1yi xl2tpd: xl2tpd[3658]: Found Control packet Apr 2 13:28:41 kis1yi xl2tpd: xl2tpd[3658]: Found packet mark: 13 (tunnel_id: 62546) Apr 2 13:28:41 kis1yi xl2tpd: xl2tpd[3658]: Call established with Y.Y.Y.Y, PID: 26789, Local: 7962, Remote: 1, Serial: 0 Apr 2 13:29:37 kis1yi xl2tpd: xl2tpd[3658]: NFLINK callback, len: 136 Apr 2 13:29:37 kis1yi xl2tpd: xl2tpd[3658]: Found UDP packet, size: 136 Apr 2 13:29:37 kis1yi xl2tpd: xl2tpd[3658]: Found Control packet Apr 2 13:29:37 kis1yi xl2tpd: xl2tpd[3658]: Found packet mark: 14 (tunnel_id: 0) Apr 2 13:29:37 kis1yi xl2tpd: xl2tpd[3658]: control_finish: Peer requested tunnel 1 twice, ignoring second one. Apr 2 13:29:41 kis1yi xl2tpd: xl2tpd[3658]: NFLINK callback, len: 40 Apr 2 13:29:41 kis1yi xl2tpd: xl2tpd[3658]: Found UDP packet, size: 40 Apr 2 13:29:41 kis1yi xl2tpd: xl2tpd[3658]: Found Control packet Apr 2 13:29:41 kis1yi xl2tpd: xl2tpd[3658]: Found packet mark: 13 (tunnel_id: 62546) Apr 2 13:30:17 kis1yi xl2tpd: xl2tpd[3658]: NFLINK callback, len: 48 Apr 2 13:30:17 kis1yi xl2tpd: xl2tpd[3658]: Found UDP packet, size: 48 Apr 2 13:30:17 kis1yi xl2tpd: xl2tpd[3658]: Found Control packet Apr 2 13:30:17 kis1yi xl2tpd: xl2tpd[3658]: Found packet mark: 14 (tunnel_id: 0) Apr 2 13:30:17 kis1yi xl2tpd: xl2tpd[3658]: check_control: Received out of order control packet on tunnel -1 (got 1, expected 0) Apr 2 13:30:17 kis1yi xl2tpd: xl2tpd[3658]: handle_control: bad control packet! Apr 2 13:30:19 kis1yi xl2tpd: xl2tpd[3658]: NFLINK callback, len: 48 Apr 2 13:30:19 kis1yi xl2tpd: xl2tpd[3658]: Found UDP packet, size: 48 Apr 2 13:30:19 kis1yi xl2tpd: xl2tpd[3658]: Found Control packet Apr 2 13:30:19 kis1yi xl2tpd: xl2tpd[3658]: Found packet mark: 14 (tunnel_id: 0) Apr 2 13:30:19 kis1yi xl2tpd: xl2tpd[3658]: check_control: Received out of order control packet on tunnel -1 (got 1, expected 0) Apr 2 13:30:19 kis1yi xl2tpd: xl2tpd[3658]: handle_control: bad control packet! Apr 2 13:30:23 kis1yi xl2tpd: xl2tpd[3658]: NFLINK callback, len: 48 Apr 2 13:30:23 kis1yi xl2tpd: xl2tpd[3658]: Found UDP packet, size: 48 Apr 2 13:30:23 kis1yi xl2tpd: xl2tpd[3658]: Found Control packet Apr 2 13:30:23 kis1yi xl2tpd: xl2tpd[3658]: Found packet mark: 14 (tunnel_id: 0) Apr 2 13:30:23 kis1yi xl2tpd: xl2tpd[3658]: check_control: Received out of order control packet on tunnel -1 (got 1, expected 0) Apr 2 13:30:23 kis1yi xl2tpd: xl2tpd[3658]: handle_control: bad control packet! Apr 2 13:30:31 kis1yi xl2tpd: xl2tpd[3658]: NFLINK callback, len: 48 Apr 2 13:30:31 kis1yi xl2tpd: xl2tpd[3658]: Found UDP packet, size: 48 Apr 2 13:30:31 kis1yi xl2tpd: xl2tpd[3658]: Found Control packet Apr 2 13:30:31 kis1yi xl2tpd: xl2tpd[3658]: Found packet mark: 14 (tunnel_id: 0) Apr 2 13:30:31 kis1yi xl2tpd: xl2tpd[3658]: check_control: Received out of order control packet on tunnel -1 (got 1, expected 0) Apr 2 13:30:31 kis1yi xl2tpd: xl2tpd[3658]: handle_control: bad control packet! Apr 2 13:30:41 kis1yi xl2tpd: xl2tpd[3658]: NFLINK callback, len: 40 Apr 2 13:30:41 kis1yi xl2tpd: xl2tpd[3658]: Found UDP packet, size: 40 Apr 2 13:30:41 kis1yi xl2tpd: xl2tpd[3658]: Found Control packet Apr 2 13:30:41 kis1yi xl2tpd: xl2tpd[3658]: Found packet mark: 13 (tunnel_id: 62546) Apr 2 13:30:41 kis1yi xl2tpd: xl2tpd[3658]: NFLINK callback, len: 48 Apr 2 13:30:41 kis1yi xl2tpd: xl2tpd[3658]: Found UDP packet, size: 48 Apr 2 13:30:41 kis1yi xl2tpd: xl2tpd[3658]: Found Control packet Apr 2 13:30:41 kis1yi xl2tpd: xl2tpd[3658]: Found packet mark: 14 (tunnel_id: 0) Apr 2 13:30:41 kis1yi xl2tpd: xl2tpd[3658]: check_control: Received out of order control packet on tunnel -1 (got 1, expected 0) Apr 2 13:30:41 kis1yi xl2tpd: xl2tpd[3658]: handle_control: bad control packet! Apr 2 13:30:51 kis1yi xl2tpd: xl2tpd[3658]: NFLINK callback, len: 48 Apr 2 13:30:51 kis1yi xl2tpd: xl2tpd[3658]: Found UDP packet, size: 48 Apr 2 13:30:51 kis1yi xl2tpd: xl2tpd[3658]: Found Control packet Apr 2 13:30:51 kis1yi xl2tpd: xl2tpd[3658]: Found packet mark: 14 (tunnel_id: 0) Apr 2 13:30:51 kis1yi xl2tpd: xl2tpd[3658]: check_control: Received out of order control packet on tunnel -1 (got 1, expected 0) Apr 2 13:30:51 kis1yi xl2tpd: xl2tpd[3658]: handle_control: bad control packet! Apr 2 13:31:25 kis1yi xl2tpd: xl2tpd[3658]: NFLINK callback, len: 136 Apr 2 13:31:25 kis1yi xl2tpd: xl2tpd[3658]: Found UDP packet, size: 136 Apr 2 13:31:25 kis1yi xl2tpd: xl2tpd[3658]: Found Control packet Apr 2 13:31:25 kis1yi xl2tpd: xl2tpd[3658]: Found packet mark: 15 (tunnel_id: 0) Apr 2 13:31:25 kis1yi xl2tpd: xl2tpd[3658]: NFLINK callback, len: 48 Apr 2 13:31:25 kis1yi xl2tpd: xl2tpd[3658]: Found UDP packet, size: 48 Apr 2 13:31:25 kis1yi xl2tpd: xl2tpd[3658]: Found Control packet Apr 2 13:31:25 kis1yi xl2tpd: xl2tpd[3658]: Found packet mark: 15 (tunnel_id: 28029) Apr 2 13:31:25 kis1yi xl2tpd: xl2tpd[3658]: Connection established to Y.Y.Y.Y, 1701. Local: 28029, Remote: 2 (ref=0/0). LNS session is 'default' Apr 2 13:31:25 kis1yi xl2tpd: xl2tpd[3658]: NFLINK callback, len: 40 Apr 2 13:31:25 kis1yi xl2tpd: xl2tpd[3658]: Found UDP packet, size: 40 Apr 2 13:31:25 kis1yi xl2tpd: xl2tpd[3658]: Found Control packet Apr 2 13:31:25 kis1yi xl2tpd: xl2tpd[3658]: Found packet mark: 15 (tunnel_id: 28029) Apr 2 13:31:25 kis1yi xl2tpd: xl2tpd[3658]: NFLINK callback, len: 76 Apr 2 13:31:25 kis1yi xl2tpd: xl2tpd[3658]: Found UDP packet, size: 76 Apr 2 13:31:25 kis1yi xl2tpd: xl2tpd[3658]: Found Control packet Apr 2 13:31:25 kis1yi xl2tpd: xl2tpd[3658]: Found packet mark: 15 (tunnel_id: 28029) Apr 2 13:31:25 kis1yi xl2tpd: xl2tpd[3658]: check_control: Received out of order control packet on tunnel 2 (got 3, expected 2) Apr 2 13:31:25 kis1yi xl2tpd: xl2tpd[3658]: handle_control: bad control packet! Apr 2 13:31:25 kis1yi xl2tpd: xl2tpd[3658]: NFLINK callback, len: 76 Apr 2 13:31:25 kis1yi xl2tpd: xl2tpd[3658]: Found UDP packet, size: 76 Apr 2 13:31:25 kis1yi xl2tpd: xl2tpd[3658]: Found Control packet Apr 2 13:31:25 kis1yi xl2tpd: xl2tpd[3658]: Found packet mark: 15 (tunnel_id: 28029) Apr 2 13:31:25 kis1yi xl2tpd: xl2tpd[3658]: Call established with Y.Y.Y.Y, PID: 26933, Local: 44970, Remote: 1, Serial: 0 Apr 2 13:31:25 kis1yi xl2tpd: xl2tpd[3658]: NFLINK callback, len: 40 Apr 2 13:31:25 kis1yi xl2tpd: xl2tpd[3658]: Found UDP packet, size: 40 Apr 2 13:31:25 kis1yi xl2tpd: xl2tpd[3658]: Found Control packet Apr 2 13:31:25 kis1yi xl2tpd: xl2tpd[3658]: Found packet mark: 15 (tunnel_id: 28029) Apr 2 13:31:25 kis1yi xl2tpd: xl2tpd[3658]: write_packet: tty is not open yet. Apr 2 13:31:25 kis1yi xl2tpd: xl2tpd[3658]: write_packet: tty is not open yet. Apr 2 13:31:25 kis1yi xl2tpd: xl2tpd[3658]: write_packet: tty is not open yet. ............... Apr 2 13:33:47 kis1yi xl2tpd: xl2tpd[3658]: write_packet: tty is not open yet. Apr 2 13:33:47 kis1yi xl2tpd: xl2tpd[3658]: write_packet: tty is not open yet. Apr 2 13:33:47 kis1yi xl2tpd: xl2tpd[3658]: write_packet: tty is not open yet. Apr 2 13:33:47 kis1yi xl2tpd: xl2tpd[3658]: child_handler : pppd exited for call 1 with code 16 Apr 2 13:33:47 kis1yi xl2tpd: xl2tpd[3658]: call_close: Call 7962 to Y.Y.Y.Y disconnected Apr 2 13:33:47 kis1yi xl2tpd: xl2tpd[3658]: write_packet: tty is not open yet. Apr 2 13:33:47 kis1yi xl2tpd: xl2tpd[3658]: write_packet: tty is not open yet. Apr 2 13:33:47 kis1yi xl2tpd: xl2tpd[3658]: write_packet: tty is not open yet. Apr 2 13:33:47 kis1yi xl2tpd: xl2tpd[3658]: write_packet: tty is not open yet. Apr 2 13:33:47 kis1yi xl2tpd: xl2tpd[3658]: NFLINK callback, len: 40 Apr 2 13:33:47 kis1yi xl2tpd: xl2tpd[3658]: Found UDP packet, size: 40 Apr 2 13:33:47 kis1yi xl2tpd: xl2tpd[3658]: Found Control packet Apr 2 13:33:47 kis1yi xl2tpd: xl2tpd[3658]: Found packet mark: 13 (tunnel_id: 62546) Apr 2 13:33:47 kis1yi xl2tpd: xl2tpd[3658]: NFLINK callback, len: 66 Apr 2 13:33:47 kis1yi xl2tpd: xl2tpd[3658]: Found UDP packet, size: 66 Apr 2 13:33:47 kis1yi xl2tpd: xl2tpd[3658]: Found Control packet Apr 2 13:33:47 kis1yi xl2tpd: xl2tpd[3658]: Found packet mark: 13 (tunnel_id: 62546) Apr 2 13:33:47 kis1yi xl2tpd: xl2tpd[3658]: control_finish: Connection closed to Y.Y.Y.Y, port 1701 (), Local: 62546, Remote: 1 Apr 2 13:34:25 kis1yi xl2tpd: xl2tpd[3658]: NFLINK callback, len: 40 Apr 2 13:34:25 kis1yi xl2tpd: xl2tpd[3658]: Found UDP packet, size: 40 Apr 2 13:34:25 kis1yi xl2tpd: xl2tpd[3658]: Found Control packet Apr 2 13:34:25 kis1yi xl2tpd: xl2tpd[3658]: Found packet mark: 15 (tunnel_id: 28029) Apr 2 13:34:36 kis1yi xl2tpd: xl2tpd[3658]: NFLINK callback, len: 66 Apr 2 13:34:36 kis1yi xl2tpd: xl2tpd[3658]: Found UDP packet, size: 66 Apr 2 13:34:36 kis1yi xl2tpd: xl2tpd[3658]: Found Control packet Apr 2 13:34:36 kis1yi xl2tpd: xl2tpd[3658]: Found packet mark: 15 (tunnel_id: 28029) Apr 2 13:34:36 kis1yi xl2tpd: xl2tpd[3658]: control_finish: Connection closed to Y.Y.Y.Y, serial 0 () Apr 2 13:34:36 kis1yi xl2tpd: xl2tpd[3658]: NFLINK callback, len: 66 Apr 2 13:34:36 kis1yi xl2tpd: xl2tpd[3658]: Found UDP packet, size: 66 Apr 2 13:34:36 kis1yi xl2tpd: xl2tpd[3658]: Found Control packet Apr 2 13:34:36 kis1yi xl2tpd: xl2tpd[3658]: Found packet mark: 15 (tunnel_id: 28029) Apr 2 13:34:36 kis1yi xl2tpd: xl2tpd[3658]: control_finish: Connection closed to Y.Y.Y.Y, port 1701 (), Local: 28029, Remote: 2 ```

ipsec.conf

```bash config setup charondebug="ike 1, knl 3, cfg 2" conn %default ikelifetime=60m keylife=20m rekeymargin=3m keyingtries=1 conn l2tp-psk left=X.X.X.X leftdns=8.8.8.8,8.8.4.4 right=%any auto=add authby=secret keyexchange=ikev1 type=transport leftprotoport=17/1701 rightprotoport=17/%any mark=%unique ike=aes256-sha1-modp2048,aes128-sha1-modp2048 esp=aes256-sha1,aes128-sha1 ```

xl2tpd.conf

```bash [global] port = 1701 [lns default] ip range = 10.0.1.10-10.0.1.250 local ip = 10.0.1.1 require chap = yes refuse pap = yes require authentication = yes name = l2tpd pppoptfile = /etc/ppp/options.xl2tpd length bit = yes ```

options.xl2tpd

```bash +mschap-v2 ipcp-accept-local ipcp-accept-remote noccp auth mtu 1280 mru 1280 proxyarp lcp-echo-failure 4 lcp-echo-interval 30 connect-delay 5000 ms-dns 8.8.8.8 ms-dns 8.8.4.4 ```

gulikoza commented 2 years ago

There was an additional issue with disconnects after some time that I've discovered and tried to fix, but the whole setup was not reliable over a large amount of clients.

I've migrated to OpenVPN long time ago....

dreamhighhd commented 2 years ago

Please tell me where the following configuration files corresponding to the connmark plug-in need to be configured. Help me see that I can't start strongswan now that I'm configured

`connections {

transport-connmark {

...

children {
  transport-connmark {
    mode = transport
    mark = %unique
    #...
  }
}

}`

dreamhighhd commented 2 years ago

Sorry to call less}

xelerance / xl2tpd

Integration with Strongswan with multiple clients behind the same NAT #82

...