Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Open
Climax777 opened this issue Sep 24, 2015 · 20 comments
Open

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

Climax777 opened this issue Sep 24, 2015 · 20 comments

Comments

@Climax777
Copy link
Contributor

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
Copy link
Collaborator

mcr commented Sep 24, 2015

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link

gulikoza commented Dec 9, 2015

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
Copy link

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
Copy link

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

@shussain
Copy link
Collaborator

@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
Copy link
Collaborator

shussain commented Jun 8, 2017

@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
Copy link

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
Copy link

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.

@bradjohn bradjohn mentioned this issue Oct 24, 2017
Open
@shussain
Copy link
Collaborator

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

@gulikoza
Copy link

@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
Copy link

@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
Copy link

martking1 commented Oct 31, 2017 •
edited
Loading

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
Copy link

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 :

  1. 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?
  2. Is this xl2tpd patch work with Specified Linux Kernel, not suppurt Linux 2.6.X?

Thank you very much.

@gulikoza
Copy link

gulikoza commented Dec 8, 2017 •
edited
Loading

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?

@dvornikov-aa dvornikov-aa mentioned this issue Sep 5, 2018
Open
@kis1yi
Copy link

kis1yi commented Apr 2, 2022 •
edited
Loading

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 
1: lo: <LOOPBACK,UP,LOWER_UP> 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: <BROADCAST,MULTICAST,UP,LOWER_UP> 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: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> 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: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> 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 
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 
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' 
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 
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 
[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 
+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
Copy link

gulikoza commented Apr 2, 2022

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
Copy link

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
#...
}
}
}`
image

@dreamhighhd
Copy link

Sorry to call less}

@dkosovic dkosovic mentioned this issue Jan 14, 2023
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
9 participants
@mcr @Climax777 @shussain @gulikoza @bradjohn @martking1 @flyjohnji @kis1yi @dreamhighhd