My Debian 10 box has a Wifi interface, wlx08beac0a6c1d running a WEP AP for old hardware that doens't wupport WPA. My main network is 192.168.1.0/24 and this interface is configured to be 192.168.2.1. For starters that interface is restricted to one MAC and it only allows DHCP on that network

iptables -A INPUT -i wlx08beac0a6c1d -m mac ! --mac-source 00:30:65:05:9F:4D -j DROP
iptables -A INPUT -i wlx08beac0a6c1d -p udp --dport 67:68 --sport 67:68 -j ACCEPT
iptables -A INPUT -i wlx08beac0a6c1d -p tcp --dport 22 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -i wlx08beac0a6c1d -j DROP

(The MAC check is also in hostapd.conf -- where of course it is just as ineffective security measure (although it's probably fairly effective here in Shropshire).) This device (claims to) support L2TP over IPSec. I imagine that by opening another port for this I can get this old machine to join the rest of my network through a tunnel to that port and that once connected the old machine will appear as if it is on my network. Is this so? Or have I got the wrong end of the stick? Is this now secure on the WEP network? It looks like the packages needed are strongswan and xl2tpd? It looks like IPSec is going to encrypt traffic over the WEP network, and that I'll need to open some more ports to allow the encryption to be negotiated and started? It then looks like L2TP will establish a connection a PPP connection to another port on Debia and route all traffic through it? So the old machine will get a second IP address for this PPP connection? And how will it appear in Debian (and be routable between the rest of my network and the Internet)? So: first is strongswan...

# apt-get install strongswan

And now I really don't understand what to do. I've done what it says here https://www.digitalocean.com/community/tutorials/how-to-set-up-an-ikev2-vpn-server-with-strongswan-on-ubuntu-18-04-2 and ended up with this ipsec.conf

config setup
    charondebug="ike 1, knl 1, cfg 0"
    uniqueids=no

conn wep-vpn
    auto=add
    compress=no
    type=tunnel
    keyexchange=ikev2
    fragmentation=yes
    forceencaps=yes
    dpdaction=clear
    dpddelay=300s
    rekey=no
    left=%any
    leftid=192.168.2.31
    leftcert=server-cert.pem
    leftsendcert=always
    leftsubnet=0.0.0.0/
    right=%any
    rightid=%any
    rightauth=eap-mschapv2
    rightsourceip=192.168.2.0/24
    rightdns=192.168.2.31
    rightsendcert=never
    eap_identity=%identity

I think that _left_ is correct if you interpret it as being _this_ machine, but not sure about _right_ which presumably is some _other_ thing? Then it goes on to do something with something called _UFW_ but I am using iptables. I think I need

iptables -A INPUT -i wlx08beac0a6c1d -p udp --dport 500 -j ACCEPT
iptables -A INPUT -i wlx08beac0a6c1d -p udp --dport 4500 -j ACCEPT

to allow connections to IPsec. Then the next part of the trick is xl2tpd...

# apt-get install xl2tpd

/etc/xl2tpd/xl2tpd.conf

[global]
ipsec saref = yes
access control = no

[lns default]
ip range = 192.168.3.100-192.168.3.254
local ip = 192.168.3.1
refuse chap = yes
refuse pap = yes
require authentication = yes
pppoptfile = /etc/ppp/xl2tpd-options
length bit = yes

/etc/ppp/xl2tpd-options

require-mschap-v2
ms-dns 192.168.3.1

Add to /etc/ppp/chap-secrets And

iptables -A INPUT -i wlx08beac0a6c1d -p udp --dport 1701 -j ACCEPT

Obviously, it doesn't work.

I'm setting up a VPN server with strongSwan, but I’ve hit a weird issue where the licenses aren’t loading properly. Right now, I’m using a Let’s Encrypt cert to connect from my iOS and macOS devices, and everything works fine with username and password auth. Now I’m trying to switch to public key authentication, and here’s what I’ve got in my config file:

config setup
    charondebug="ike 2, knl 2, cfg 2, net 2, dmn 2"
    uniqueids=no

conn ikev2-vpn
    auto=add
    compress=no
    type=tunnel
    keyexchange=ikev2
    fragmentation=yes
    forceencaps=yes
    dpdaction=clear
    dpddelay=300s
    rekey=no

    left=%any
    leftid=@redacted.com
    leftcert=/etc/ipsec.d/certs/server.crt # My LetsEncrypt fullchain.pem certificate
    leftsendcert=always
    leftsubnet=0.0.0.0/0

    right=%any
    rightid=%any
    rightsourceip=10.10.10.0/24
    rightdns=8.8.8.8,8.8.4.4

    rightauth=pubkey
    leftauth=pubkey
    rightca=/etc/ipsec.d/cacerts/ca-cert.pem # My self-signed CA certificate

    ike=aes256-sha1-modp2048, aes256-sha256-modp2048, aes256gcm128-sha256-modp2048, aes256gcm16-sha256-modp2048, chacha20poly1305-sha512-curve25519-prfsha512,aes256gcm16-sha384-prfsha384-ecp384,aes256-sha1-modp1024,aes128-sha1-modp1024,3des-sha1-modp1024!
    esp=aes256-sha1, aes256-sha256, aes256gcm16, aes256gcm128-sha256, chacha20poly1305-sha512,aes256gcm16-ecp384,3des-sha1!

ipsec.secrets file:

: ECDSA "server.key"

My server logs:

00[DMN] Starting IKE charon daemon (strongSwan 5.9.13, Linux 6.8.0-52-generic, x86_64)
00[LIB] providers loaded by OpenSSL: legacy default
00[CFG] install DNS servers in '/etc/resolv.conf'
00[KNL] XFRM interfaces supported by kernel
00[KNL] known interfaces and IP addresses:
00[KNL]   lo
00[KNL]     127.0.0.1
00[KNL]     ::1
00[KNL]   eth0
00[KNL]     116.203.145.16
00[KNL]     2a01:4f8:c2c:adc1::1
00[KNL]     fe80::9400:4ff:fe37:cad
00[KNL]   docker0
00[KNL]     172.17.0.1
00[KNL]     fe80::42:23ff:fec8:9e46
00[KNL]   br-4c7a050e9086
00[KNL]     172.18.0.1
00[KNL]     fe80::42:cbff:feb7:b0bd
00[KNL]   veth1dd5702
00[KNL]     fe80::8445:b8ff:feb9:730
00[CFG] loading ca certificates from '/etc/ipsec.d/cacerts'
00[CFG]   loaded ca certificate "C=US, O=Let's Encrypt, CN=E6" from '/etc/ipsec.d/cacerts/chain.pem'
00[CFG]   loaded ca certificate "CN=Redacted CA" from '/etc/ipsec.d/cacerts/ca-cert.pem'
00[CFG] loading aa certificates from '/etc/ipsec.d/aacerts'
00[CFG] loading ocsp signer certificates from '/etc/ipsec.d/ocspcerts'
00[CFG] loading attribute certificates from '/etc/ipsec.d/acerts'
00[CFG] loading crls from '/etc/ipsec.d/crls'
00[CFG] loading secrets from '/etc/ipsec.secrets'
00[CFG]   loaded ECDSA private key from '/etc/ipsec.d/private/server.key'
00[LIB] loaded plugins: charon aesni aes rc2 sha2 sha1 md5 mgf1 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs12 pgp dnskey sshkey pem openssl pkcs8 fips-prf gmp agent xcbc hmac kdf gcm drbg attr kernel-netlink resolve socket-default connmark stroke updown eap-mschapv2 xauth-generic counters
00[LIB] dropped capabilities, running as uid 0, gid 0
00[JOB] spawning 16 worker threads
04[NET] waiting for data on sockets
06[CFG] received stroke: add connection 'ikev2-vpn'
06[CFG] conn ikev2-vpn
06[CFG]   left=%any
06[CFG]   leftsubnet=0.0.0.0/0
06[CFG]   leftauth=pubkey
06[CFG]   leftid=@redacted.com
06[CFG]   leftcert=/etc/ipsec.d/certs/server.crt
06[CFG]   right=%any
06[CFG]   rightsourceip=10.10.10.0/24
06[CFG]   rightdns=8.8.8.8,8.8.4.4
06[CFG]   rightauth=pubkey
06[CFG]   rightid=%any
06[CFG]   rightca=/etc/ipsec.d/cacerts/ca-cert.pem
06[CFG]   ike=aes256-sha1-modp2048, aes256-sha256-modp2048, aes256gcm128-sha256-modp2048, aes256gcm16-sha256-modp2048, chacha20poly1305-sha512-curve25519-prfsha512,aes256gcm16-sha384-prfsha384-ecp384,aes256-sha1-modp1024,aes128-sha1-modp1024,3des-sha1-modp1024!
06[CFG]   esp=aes256-sha1, aes256-sha256, aes256gcm16, aes256gcm128-sha256, chacha20poly1305-sha512,aes256gcm16-ecp384,3des-sha1!
06[CFG]   dpddelay=300
06[CFG]   dpdtimeout=150
06[CFG]   dpdaction=1
06[CFG]   sha256_96=no
06[CFG]   mediation=no
06[CFG]   keyexchange=ikev2
06[CFG] adding virtual IP address pool 10.10.10.0/24
06[CFG]   loaded certificate "CN=redacted.com" from '/etc/ipsec.d/certs/server.crt'
06[CFG] CA certificate "/etc/ipsec.d/cacerts/ca-cert.pem" not found, discarding CA constraint
06[CFG] added configuration 'ikev2-vpn'
04[NET] received packet: from 46.99.24.33 to 116.203.145.16
04[NET] waiting for data on sockets
10[NET] received packet: from 46.99.24.33 to 116.203.145.16 (356 bytes)
10[ENC] parsed IKE_SA_INIT request 0 [ SA KE No N(REDIR_SUP) N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) ]
10[CFG] looking for an IKEv2 config for 116.203.145.16...46.99.24.33
10[CFG]   candidate: %any...%any, prio 28
10[CFG] found matching ike config: %any...%any with prio 28
10[IKE] local endpoint changed from 0.0.0.0 to 116.203.145.16
10[IKE] remote endpoint changed from 0.0.0.0 to 46.99.24.33
10[IKE] 46.99.24.33 is initiating an IKE_SA
10[IKE] IKE_SA (unnamed) state change: CREATED => CONNECTING
10[CFG] selecting proposal:
10[CFG]   no acceptable ENCRYPTION_ALGORITHM found
10[CFG] selecting proposal:
10[CFG]   no acceptable ENCRYPTION_ALGORITHM found
10[CFG] selecting proposal:
10[CFG]   no acceptable INTEGRITY_ALGORITHM found
10[CFG] selecting proposal:
10[CFG]   no acceptable INTEGRITY_ALGORITHM found
10[CFG] selecting proposal:
10[CFG]   no acceptable ENCRYPTION_ALGORITHM found
10[CFG] selecting proposal:
10[CFG]   no acceptable ENCRYPTION_ALGORITHM found
10[CFG] selecting proposal:
10[CFG]   no acceptable KEY_EXCHANGE_METHOD found
10[CFG] selecting proposal:
10[CFG]   proposal matches
10[CFG] received proposals: IKE:AES_GCM_16_256/PRF_HMAC_SHA2_256/ECP_256, IKE:AES_GCM_16_256/PRF_HMAC_SHA2_256/MODP_2048, IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_256, IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
10[CFG] configured proposals: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048, IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048, IKE:AES_GCM_16_256/PRF_HMAC_SHA2_256/MODP_2048, IKE:AES_GCM_16_256/PRF_HMAC_SHA2_256/MODP_2048, IKE:CHACHA20_POLY1305/PRF_HMAC_SHA2_512/CURVE_25519, IKE:AES_GCM_16_256/PRF_HMAC_SHA2_384/ECP_384, IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
10[CFG] selected proposal: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
10[IKE] remote host is behind NAT
10[IKE] DH group ECP_256 unacceptable, requesting MODP_2048
10[ENC] generating IKE_SA_INIT response 0 [ N(INVAL_KE) ]
10[NET] sending packet: from 116.203.145.16 to 46.99.24.33 (38 bytes)
10[IKE] IKE_SA (unnamed) state change: CONNECTING => DESTROYING
05[NET] sending packet: from 116.203.145.16 to 46.99.24.33
04[NET] received packet: from 46.99.24.33 to 116.203.145.16
04[NET] waiting for data on sockets
11[NET] received packet: from 46.99.24.33 to 116.203.145.16 (548 bytes)
11[ENC] parsed IKE_SA_INIT request 0 [ SA KE No N(REDIR_SUP) N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) ]
11[CFG] looking for an IKEv2 config for 116.203.145.16...46.99.24.33
11[CFG]   candidate: %any...%any, prio 28
11[CFG] found matching ike config: %any...%any with prio 28
11[IKE] local endpoint changed from 0.0.0.0 to 116.203.145.16
11[IKE] remote endpoint changed from 0.0.0.0 to 46.99.24.33
11[IKE] 46.99.24.33 is initiating an IKE_SA
11[IKE] IKE_SA (unnamed) state change: CREATED => CONNECTING
11[CFG] selecting proposal:
11[CFG]   no acceptable ENCRYPTION_ALGORITHM found
11[CFG] selecting proposal:
11[CFG]   no acceptable ENCRYPTION_ALGORITHM found
11[CFG] selecting proposal:
11[CFG]   no acceptable INTEGRITY_ALGORITHM found
11[CFG] selecting proposal:
11[CFG]   no acceptable INTEGRITY_ALGORITHM found
11[CFG] selecting proposal:
11[CFG]   no acceptable ENCRYPTION_ALGORITHM found
11[CFG] selecting proposal:
11[CFG]   no acceptable ENCRYPTION_ALGORITHM found
11[CFG] selecting proposal:
11[CFG]   no acceptable KEY_EXCHANGE_METHOD found
11[CFG] selecting proposal:
11[CFG]   proposal matches
11[CFG] received proposals: IKE:AES_GCM_16_256/PRF_HMAC_SHA2_256/ECP_256, IKE:AES_GCM_16_256/PRF_HMAC_SHA2_256/MODP_2048, IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_256, IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
11[CFG] configured proposals: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048, IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048, IKE:AES_GCM_16_256/PRF_HMAC_SHA2_256/MODP_2048, IKE:AES_GCM_16_256/PRF_HMAC_SHA2_256/MODP_2048, IKE:CHACHA20_POLY1305/PRF_HMAC_SHA2_512/CURVE_25519, IKE:AES_GCM_16_256/PRF_HMAC_SHA2_384/ECP_384, IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
11[CFG] selected proposal: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
11[IKE] remote host is behind NAT
11[IKE] sending cert request for "C=US, O=Let's Encrypt, CN=E6"
11[IKE] sending cert request for "CN=Redacted CA"
11[ENC] generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(FRAG_SUP) N(CHDLESS_SUP) N(MULT_AUTH) ]
11[NET] sending packet: from 116.203.145.16 to 46.99.24.33 (501 bytes)
05[NET] sending packet: from 116.203.145.16 to 46.99.24.33
04[NET] received packet: from 46.99.24.33 to 116.203.145.16
04[NET] waiting for data on sockets

I think the certificates are loaded properly based on these logs:

00[CFG] loading ca certificates from '/etc/ipsec.d/cacerts' 00[CFG]   loaded ca certificate "C=US, O=Let's Encrypt, CN=E6" from '/etc/ipsec.d/cacerts/chain.pem' 00[CFG]   loaded ca certificate "CN=Redacted CA" from '/etc/ipsec.d/cacerts/ca-cert.pem'

The weird error that I think might be causing the issue:

06[CFG] CA certificate "/etc/ipsec.d/cacerts/ca-cert.pem" not found, discarding CA constraint

Here's how I generated the certificates:

#!/bin/bash

# Paths for the certificate files
BASE_DIR="$(pwd)"
CA_CERT="$BASE_DIR/ca-cert.pem"
CA_KEY="$BASE_DIR/ca-key.pem"
SERVER_CERT="$BASE_DIR/server.crt"
SERVER_KEY="$BASE_DIR/server-key.pem"
CLIENT_CERT="$BASE_DIR/client.crt"
CLIENT_KEY="$BASE_DIR/client-key.pem"
P12_FILE="$BASE_DIR/client.p12"
P12_PASSWORD="test"  # Password for the .p12 file

# Common Name for the CA
CA_CN="Redacted CA"

# Generate the CA private key (ECDSA, no password)
openssl ecparam -name prime256v1 -genkey -noout -out "$CA_KEY"
chmod 600 "$CA_KEY"

# Generate the CA certificate
openssl req -key "$CA_KEY" -new -x509 -out "$CA_CERT" -days 3650 -subj "/CN=$CA_CN" -nodes

# Generate server private key (ECDSA, no password)
openssl ecparam -name prime256v1 -genkey -noout -out "$SERVER_KEY"
chmod 600 "$SERVER_KEY"

# Generate server certificate signing request (CSR)
openssl req -new -key "$SERVER_KEY" -out "$BASE_DIR/server.csr" -subj "/CN=redacted.com" -nodes

# Sign the server certificate with the CA
openssl x509 -req -in "$BASE_DIR/server.csr" -CA "$CA_CERT" -CAkey "$CA_KEY" -CAcreateserial -out "$SERVER_CERT" -days 3650

# Generate client private key (ECDSA, no password)
openssl ecparam -name prime256v1 -genkey -noout -out "$CLIENT_KEY"
chmod 600 "$CLIENT_KEY"

# Generate client certificate signing request (CSR)
openssl req -new -key "$CLIENT_KEY" -out "$BASE_DIR/client.csr" -subj "/CN=client.redacted.com" -nodes

# Sign the client certificate with the CA
openssl x509 -req -in "$BASE_DIR/client.csr" -CA "$CA_CERT" -CAkey "$CA_KEY" -CAcreateserial -out "$CLIENT_CERT" -days 3650

# Combine the client certificate and key into a .p12 file with password "test"
openssl pkcs12 -export -in "$CLIENT_CERT" -inkey "$CLIENT_KEY" -out "$P12_FILE" -name "client" -passout pass:"$P12_PASSWORD"

# Clean up the CSR files
rm "$BASE_DIR/server.csr" "$BASE_DIR/client.csr"

echo "ECDSA certificates and .p12 file with password 'test' generated successfully!"

When the clients try to connect to the server, it disconnects them right away. The username-password one works perfectly when I configure it. - I tried to connect to the server in iOS (using a .mobileconfig file) and MacOS but same result in both. * I gave all system users 777 permissions for the certificates directory to test if it was a permissions thing, it still showed the same error. * I disabled AppArmor fully, still the same issue. * I tried to run the server as a docker container and as a normal process in the host - same issue. Since I use a self-signed CA certificate to sign the private keys, could that cause any issues since I use a LetsEncrypt one for the server auth? The end goal is to have a secure way to connect to the VPN server using an iOS application. I read it somewhere that username-password authentication wasn't supported if you want to have your app in AppStore. Any tips would be very helpful! Meanwhile, I'll continue my research. Thank you in advance! Edit #1 Here's how I configured the certificate files on the Docker version: docker run -d --name ikev2-vpn-server \ --privileged \ --cap-add=NET_ADMIN \ --net=host \ --restart=always \ -v $VPN_CONFIG_DIR/ipsec.conf:/etc/ipsec.conf \ -v $VPN_CONFIG_DIR/ipsec.secrets:/etc/ipsec.secrets \ -v $VPN_CERTIFICATES_DIR/server/chain.pem:/etc/ipsec.d/cacerts/chain.pem \ -v $VPN_CERTIFICATES_DIR/server/fullchain.pem:/etc/ipsec.d/certs/server.crt \ -v $VPN_CERTIFICATES_DIR/server/privkey.pem:/etc/ipsec.d/private/server.key \ -v $VPN_CERTIFICATES_DIR/vpn-ca/ca-cert.pem:/etc/ipsec.d/cacerts/ca-cert.pem \ -v $VPN_CERTIFICATES_DIR/vpn-client/client-key.pem:/etc/ipsec.d/private/client-key.pem \ ermalferati/ikev2-vpn-server

I have a problem connecting to a remote server via StrongSwan IPsec. I tried connecting using FortiClient IPsec on Windows, and everything worked fine. I was able to connect! However, when I tried to connect using StrongSwan, it didn’t work. I’d be very grateful for any support. This is my code in ipsec.conf config setup charondebug="ike 2, knl 2, net 2, dmn 2, mgr 2" nat_traversal=yes conn myvpn keyexchange=ikev2 authby=xauthpsk left=%defaultroute leftid= right= rightid=@ rightsubnet=0.0.0.0/0 ikelifetime=60m keylife=20m esp=aes256-sha2_256 dpdaction=clear dpddelay=30s dpdtimeout=120s auto=start This is my cod in ipsec.secrets @ : PSK "PSK_key" @ : XAuth "password"

I'm trying to configure a new VPN client (L2TP and IPSec) on a very small AWS EC2 system running Debian 11 without a desktop. I've got as far as getting NetworkManager to work, but the VPN connection doesn't start, apparently because of an error to do with IPSec. This is what I did - in one terminal window (IP addresses etc have been changed):

root@client# /run/network/interfaces.d# /usr/lib/NetworkManager/nm-l2tp-service --debug
nm-l2tp  nm-l2tp-service (version 1.2.18) starting...
nm-l2tp   uses default --bus-name "org.freedesktop.NetworkManager.l2tp"
nm-l2tp   ipsec enable flag: yes
** Message: 13:01:51.414: Check port 1701
** Message: 13:01:51.414: Can't bind to port 1701
nm-l2tp   L2TP port 1701 is busy, using ephemeral.
connection
        autoconnect : false
        id : 'vpnname'
        interface-name : '--'
        permissions : []
        type : 'vpn'
        uuid : '542b35f3-fadc-4df1-b340-a68eec3a9c3f'

proxy

ipv6
        address-data : []
        dns : []
        dns-search : []
        method : 'auto'
        route-data : []

vpn
        data : {'gateway': '123.456.789.012', 'ipsec-enabled': 'yes', 'ipsec-psk': '0sTiFSU190ZWNobjBsMGczCg==', 'mru': '1400', 'mtu': '1400', 'password-flags': '0', 'refuse-chap': 'yes', 'refuse-mschap': 'yes', 'refuse-pap': 'yes', 'require-mppe': 'yes', 'user': 'vpntest'}
        secrets : {'password': 'vPnt35t'}
        service-type : 'org.freedesktop.NetworkManager.l2tp'

ipv4
        address-data : []
        dns : []
        dns-search : []
        method : 'auto'
        route-data : []

nm-l2tp   starting ipsec
Stopping strongSwan IPsec failed: starter is not running
Starting strongSwan 5.9.1 IPsec [starter]...
Loading config setup
Loading conn '542b35f3-fadc-4df1-b340-a68eec3a9c3f'
nm-l2tp   Spawned ipsec up script with PID 13126.
initiating Main Mode IKE_SA 542b35f3-fadc-4df1-b340-a68eec3a9c3f to 123.456.789.012
generating ID_PROT request 0 [ SA V V V V V ]
sending packet: from 111.222.333.444 to 123.456.789.012 (532 bytes)
received packet: from 123.456.789.012 to 111.222.333.444 (132 bytes)
parsed ID_PROT response 0 [ SA V V V ]
received XAuth vendor ID
received DPD vendor ID
received NAT-T (RFC 3947) vendor ID
selected proposal: IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
generating ID_PROT request 0 [ KE No NAT-D NAT-D ]
sending packet: from 111.222.333.444 to 123.456.789.012 (244 bytes)
received packet: from 123.456.789.012 to 111.222.333.444 (244 bytes)
parsed ID_PROT response 0 [ KE No NAT-D NAT-D ]
local host is behind NAT, sending keep alives
generating ID_PROT request 0 [ ID HASH ]
sending packet: from 111.222.333.444 to 123.456.789.012 (68 bytes)
received packet: from 123.456.789.012 to 111.222.333.444 (68 bytes)
invalid HASH_V1 payload length, decryption failed?
could not decrypt payloads
message parsing failed
ignore malformed INFORMATIONAL request
INFORMATIONAL_V1 request with message ID 1308603116 processing failed
sending retransmit 1 of request message ID 0, seq 3
sending packet: from 111.222.333.444 to 123.456.789.012 (68 bytes)
received packet: from 123.456.789.012 to 111.222.333.444 (68 bytes)
invalid HASH_V1 payload length, decryption failed?
could not decrypt payloads
message parsing failed
ignore malformed INFORMATIONAL request
INFORMATIONAL_V1 request with message ID 3696528349 processing failed
nm-l2tp   Timeout trying to establish IPsec connection
nm-l2tp   Terminating ipsec script with PID 13126.
Stopping strongSwan IPsec...
destroying IKE_SA in state CONNECTING without notification
nm-l2tp   Could not establish IPsec tunnel.

(nm-l2tp-service:13017): GLib-GIO-CRITICAL **: 13:02:04.565: g_dbus_method_invocation_take_error: assertion 'error != NULL' failed

and in another window:

root@client# nmcli c up vpnname
Error: Connection activation failed: Unknown reason
Hint: use 'journalctl -xe NM_CONNECTION=542b35f3-fadc-4df1-b340-a68eec3a9c3f + NM_DEVICE=eth0' to get more details.

Unfortunately I don't know IPSec well enough, and what I find through google and on this site seems to be several years old and doesn't really match what I see. What do I need to change? ***EDIT*** So, a downvote, but no comment. It would be nice to see why; I haven't simply thrown my question in here because I couldn't be asked to try to solve it myself or carry out a search. Even after some 25 years of Linux development and sysadmin, there are still plenty of things I've never worked with. There are loads of low-quality 'solutions' to be found, which mention ipsec, l2tp and other things, usually with pictures of some GUI; but very little that addresses the command line, and most of it seems to be old and irrelevant.

I’m currently having trouble setting up an IKEv2 VPN connection on an Android device using strongSwan as the VPN server. Despite having a valid certificate and key setup on both ends, I keep getting the error "NO_PROPOSAL_CHOSEN" in the logs when trying to establish the VPN connection. **Details of the Issue:** - VPN Server: strongSwan (on a Debian 12 VPS) - Client: Android 13 (using native VPN client) - Error Message: Oct 13 18:22:29 m1 charon: 12[CFG] looking for an IKEv2 config for 172.28.204.140...103.82.15.193 Oct 13 18:22:29 m1 charon: 12[IKE] no IKE config found for 172.28.204.140...103.82.15.193, sending NO_PROPOSAL_CHOSEN **VPN Server Config (simplified)** conn ikev2-vpn keyexchange=ikev2 ike=aes128-sha1-modp1024! esp=aes128-sha1! left=XXX # Server's public IP address leftcert=/etc/ipsec.d/certs/serverCert.pem leftsubnet=0.0.0.0/0 right=%any # Dynamic client IP rightdns=8.8.8.8, 8.8.4.4 rightsourceip=10.10.10.0/24 rightauth=eap-tls rightcert=/etc/ipsec.d/certs/userCert.pem leftauth=pubkey leftid=XXX auto=add **What am I missing or doing wrong?** Has anyone encountered this error or knows what might be causing the issue? Any suggestions or guidance would be greatly appreciated! Thanks in advance!

I have created a SITE-TO-SITE IPSEC tunnel between my two branches, the tunnel is up and running and I can ping bidirectional both routers, the problem is that I can't do any type of communications (like ping) from / to the hosts. Let me explain my scenario  **SITE A - Strongswan config:**

root@esxi:~# cat /etc/ipsec.conf
config setup
        charondebug="all"
        uniqueids=yes
        strictcrlpolicy=no

# connection to siteB datacenter
conn siteA-to-siteB
  authby=secret
  left=%defaultroute
  leftid=51.91.48.XX
  leftsubnet=192.168.58.0/24
  right=51.77.246.XX
  rightsubnet=192.168.60.0/24
  ike=aes256-sha2_256-modp1024!
  esp=aes256-sha2_256!
  keyingtries=0
  ikelifetime=1h
  lifetime=8h
  dpddelay=30
  dpdtimeout=120
  dpdaction=restart
  auto=start
  leftfirewall=yes

**SITE A - ipsec statusall:**

root@esxi:~# ipsec statusall
Status of IKE charon daemon (strongSwan 5.9.10, Linux 4.15.18-18-pve, x86_64):
  uptime: 28 minutes, since Jun 17 14:51:55 2024
  malloc: sbrk 3108864, mmap 0, used 975056, free 2133808
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 7
  loaded plugins: charon test-vectors ldap pkcs11 aesni aes rc2 sha2 sha1 md5 mgf1 rdrand random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs12 pgp dnskey sshkey pem openssl gcrypt pkcs8 af-alg fips-prf gmp curve25519 agent chapoly xcbc cmac hmac kdf ctr ccm gcm drbg curl attr kernel-netlink resolve socket-default connmark farp stroke vici updown eap-identity eap-aka eap-md5 eap-gtc eap-mschapv2 eap-radius eap-tls eap-ttls eap-tnc xauth-generic xauth-eap xauth-pam tnc-tnccs dhcp lookip error-notify certexpire led duplicheck addrblock unity counters
Listening IP addresses:
  51.91.48.XX
  10.0.0.1
  192.168.58.1
Connections:
siteA-to-siteB:  %any...51.77.246.XX  IKEv1/2, dpddelay=30s
siteA-to-siteB:   local:  [51.91.48.XX] uses pre-shared key authentication
siteA-to-siteB:   remote: [51.77.246.XX] uses pre-shared key authentication
siteA-to-siteB:   child:  192.168.58.0/24 === 192.168.60.0/24 TUNNEL, dpdaction=start
Security Associations (1 up, 0 connecting):
siteA-to-siteB: ESTABLISHED 24 minutes ago, 51.91.48.XX[51.91.48.XX]...51.77.246.XX[51.77.246.XX]
siteA-to-siteB: IKEv2 SPIs: b50d4c5cf4d2eda4_i ff26607335a4e302_r*, pre-shared key reauthentication in 22 minutes
siteA-to-siteB: IKE proposal: AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024
siteA-to-siteB{4}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: c88bd63c_i c895872a_o
siteA-to-siteB{4}:  AES_CBC_256/HMAC_SHA2_256_128, 62748 bytes_i (747 pkts, 718s ago), 62748 bytes_o (747 pkts, 718s ago), rekeying in 7 hours
siteA-to-siteB{4}:   192.168.58.0/24 === 192.168.60.0/24

**SITE A - iptables-save:**

root@esxi:~# iptables-save
# Generated by iptables-save v1.6.0 on Mon Jun 17 15:22:00 2024
*mangle
:PREROUTING ACCEPT [3526842015:5243135264619]
:INPUT ACCEPT [8497927:1230923546]
:FORWARD ACCEPT [3515524990:5241678882328]
:OUTPUT ACCEPT [8084473:1417568853]
:POSTROUTING ACCEPT [3519557170:5242641211859]
COMMIT
# Completed on Mon Jun 17 15:22:00 2024
# Generated by iptables-save v1.6.0 on Mon Jun 17 15:22:00 2024
*nat
:PREROUTING ACCEPT [17332:1076769]
:INPUT ACCEPT [679:26994]
:OUTPUT ACCEPT [5:532]
:POSTROUTING ACCEPT [1463:89147]
-A PREROUTING -i vmbr0 -p udp -m udp --dport 50 -j ACCEPT
-A PREROUTING -i vmbr0 -p udp -m udp --dport 500 -j ACCEPT
-A PREROUTING -i vmbr0 -p udp -m udp --dport 4500 -j ACCEPT
-A PREROUTING -i vmbr0 -p udp -m udp --dport 1701 -j ACCEPT
-A PREROUTING -i vmbr0 -p esp -j ACCEPT
-A PREROUTING -i vmbr0 -p ah -j ACCEPT
-A PREROUTING -i vmbr0 -p tcp -m multiport ! --dports 22,8006 -j DNAT --to-destination 10.0.0.2
-A PREROUTING -i vmbr0 -p udp -j DNAT --to-destination 10.0.0.2
-A PREROUTING -i vmbr0 -p tcp -m multiport ! --dports 22,8006 -j DNAT --to-destination 10.0.0.2
-A PREROUTING -i vmbr0 -p udp -j DNAT --to-destination 10.0.0.2
-A POSTROUTING -s 10.0.0.0/30 -o vmbr0 -j MASQUERADE
-A POSTROUTING -s 10.0.0.0/30 -o vmbr0 -j MASQUERADE
COMMIT
# Completed on Mon Jun 17 15:22:00 2024
# Generated by iptables-save v1.6.0 on Mon Jun 17 15:22:00 2024
*filter
:INPUT DROP [192:18886]
:FORWARD DROP [0:0]
:OUTPUT DROP [1:68]
:TCP - [0:0]
:UDP - [0:0]
-A INPUT -p esp -j ACCEPT
-A INPUT -p ah -j ACCEPT
-A INPUT -p udp -m udp --dport 50 -j ACCEPT
-A INPUT -p udp -m udp --dport 500 -j ACCEPT
-A INPUT -p udp -m udp --dport 4500 -j ACCEPT
-A INPUT -p udp -m udp --dport 1701 -j ACCEPT
-A INPUT -p udp -m conntrack --ctstate NEW -j UDP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j TCP
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 8 -m conntrack --ctstate NEW -j ACCEPT
-A INPUT -i vmbr20 -p ah -m comment --comment ArticaStrongswanVPN -j ACCEPT
-A INPUT -p udp -m udp --dport 1701 -m comment --comment ArticaStrongswanVPN -j ACCEPT
-A FORWARD -s 192.168.60.0/24 -d 192.168.58.0/24 -i vmbr0 -m policy --dir in --pol ipsec --reqid 1 --proto esp -j ACCEPT
-A FORWARD -s 192.168.58.0/24 -d 192.168.60.0/24 -o vmbr0 -m policy --dir out --pol ipsec --reqid 1 --proto esp -j ACCEPT
-A FORWARD -s 192.168.60.0/24 -d 192.168.58.0/24 -m policy --dir in --pol ipsec --reqid 1 --proto esp -j ACCEPT
-A FORWARD -s 192.168.58.0/24 -d 192.168.60.0/24 -m policy --dir out --pol ipsec --reqid 1 --proto esp -j ACCEPT
-A FORWARD -s 192.168.60.0/24 -d 192.168.58.0/24 -i vmbr0 -m policy --dir in --pol ipsec --reqid 1 --proto esp -j ACCEPT
-A FORWARD -s 192.168.58.0/24 -d 192.168.60.0/24 -o vmbr0 -m policy --dir out --pol ipsec --reqid 1 --proto esp -j ACCEPT
-A FORWARD -d 8.8.8.8/32 -p udp -j ACCEPT
-A FORWARD -d 8.8.8.8/32 -p udp -j ACCEPT
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -d 10.0.0.2/32 -i vmbr0 -o vmbr1 -p tcp -j ACCEPT
-A FORWARD -d 10.0.0.2/32 -i vmbr0 -o vmbr1 -p udp -j ACCEPT
-A FORWARD -s 10.0.0.0/30 -i vmbr1 -j ACCEPT
-A FORWARD -d 10.0.0.2/32 -i vmbr0 -o vmbr1 -p tcp -j ACCEPT
-A FORWARD -d 10.0.0.2/32 -i vmbr0 -o vmbr1 -p udp -j ACCEPT
-A FORWARD -s 10.0.0.0/30 -i vmbr1 -j ACCEPT
-A OUTPUT -p udp -m udp --dport 50 -j ACCEPT
-A OUTPUT -p udp -m udp --dport 500 -j ACCEPT
-A OUTPUT -p udp -m udp --dport 4500 -j ACCEPT
-A OUTPUT -p udp -m udp --dport 1701 -j ACCEPT
-A OUTPUT -p esp -j ACCEPT
-A OUTPUT -p ah -j ACCEPT
-A OUTPUT -d 8.8.8.8/32 -p udp -j ACCEPT
-A OUTPUT -d 8.8.8.8/32 -p udp -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -p icmp -j ACCEPT
-A OUTPUT -s 10.0.0.2/32 -d 51.91.48.XX/32 -o vmbr0 -j ACCEPT
-A OUTPUT -s 51.91.48.XX/32 -o vmbr0 -p tcp -m tcp --dport 22 -j ACCEPT
-A OUTPUT -s 51.91.48.XX/32 -o vmbr0 -p udp -m udp --dport 53 -j ACCEPT
-A OUTPUT -s 51.91.48.XX/32 -o vmbr0 -p tcp -m tcp --dport 43 -j ACCEPT
-A OUTPUT -s 51.91.48.XX/32 -o vmbr0 -p tcp -m tcp --dport 80 -j ACCEPT
-A OUTPUT -s 51.91.48.XX/32 -o vmbr0 -p tcp -m tcp --dport 443 -j ACCEPT
-A OUTPUT -s 51.91.48.XX/32 -o vmbr0 -p tcp -m tcp --sport 22 -j ACCEPT
-A OUTPUT -s 51.91.48.XX/32 -o vmbr0 -p tcp -m tcp --sport 8006 -j ACCEPT
-A OUTPUT -s 10.0.0.1/32 -o vmbr1 -p tcp -m tcp --sport 22 -j ACCEPT
-A OUTPUT -s 10.0.0.1/32 -o vmbr1 -p tcp -m tcp --sport 8006 -j ACCEPT
-A OUTPUT -s 51.91.48.XX/32 -o vmbr0 -p udp -m udp --dport 53 -j ACCEPT
-A OUTPUT -s 51.91.48.XX/32 -o vmbr0 -p tcp -m tcp --dport 43 -j ACCEPT
-A OUTPUT -s 51.91.48.XX/32 -o vmbr0 -p tcp -m tcp --dport 80 -j ACCEPT
-A OUTPUT -s 51.91.48.XX/32 -o vmbr0 -p tcp -m tcp --dport 443 -j ACCEPT
-A OUTPUT -s 51.91.48.XX/32 -o vmbr0 -p tcp -m tcp --sport 22 -j ACCEPT
-A OUTPUT -s 51.91.48.XX/32 -o vmbr0 -p tcp -m tcp --sport 8006 -j ACCEPT
-A OUTPUT -s 10.0.0.1/32 -o vmbr1 -p tcp -m tcp --sport 22 -j ACCEPT
-A OUTPUT -s 10.0.0.1/32 -o vmbr1 -p tcp -m tcp --sport 8006 -j ACCEPT
-A TCP -d 51.91.48.XX/32 -i vmbr0 -p tcp -m tcp --dport 22 -j ACCEPT
-A TCP -d 51.91.48.XX/32 -i vmbr0 -p tcp -m tcp --dport 8006 -j ACCEPT
-A TCP -d 10.0.0.1/32 -i vmbr1 -p tcp -m tcp --dport 22 -j ACCEPT
-A TCP -d 10.0.0.1/32 -i vmbr1 -p tcp -m tcp --dport 8006 -j ACCEPT
-A TCP -d 10.0.0.1/32 -i vmbr1 -p tcp -m tcp --dport 22 -j ACCEPT
-A TCP -d 10.0.0.1/32 -i vmbr1 -p tcp -m tcp --dport 8006 -j ACCEPT
COMMIT
# Completed on Mon Jun 17 15:22:00 2024

**SITE A - ip route list table 220:**

root@esxi:~# ip route list table 220
192.168.60.0/24 via 51.91.48.XX dev vmbr0 proto static src 192.168.58.1

**SITE A - Ping from Router to site SITE B Router:**

root@esxi:~# ping 192.168.60.1
PING 192.168.60.1 (192.168.60.1) 56(84) bytes of data.
64 bytes from 192.168.60.1: icmp_seq=1 ttl=64 time=1.80 ms
64 bytes from 192.168.60.1: icmp_seq=2 ttl=64 time=1.84 ms

**SITE A - Ping from Router to site SITE B Host:**

root@esxi:~# ping 192.168.60.254
PING 192.168.60.254 (192.168.60.254) 56(84) bytes of data.
64 bytes from 192.168.60.254: icmp_seq=1 ttl=63 time=2.03 ms
64 bytes from 192.168.60.254: icmp_seq=2 ttl=63 time=2.03 ms
64 bytes from 192.168.60.254: icmp_seq=3 ttl=63 time=2.09 ms

**SITE A - Ping from Host to site SITE B Router (NOT WORK):**

root@esxi:~# ping 192.168.60.1
PING 192.168.60.1 (192.168.60.1) 56(84) bytes of data.

**SITE A - Ping from Host to site SITE B Host(NOT WORK):**

root@esxi:~# ping 192.168.60.254
PING 192.168.60.254 (192.168.60.254 ) 56(84) bytes of data.

**SITE B - Strongswan config:**

root@ns3141268:~# cat /etc/ipsec.conf
config setup
        charondebug="all"
        uniqueids=yes
        strictcrlpolicy=no

# connection to siteB datacenter
conn siteA-to-siteB
  authby=secret
  left=%defaultroute
  leftid=51.77.246.XX
  leftsubnet=192.168.60.0/24
  right=51.91.48.XX
  rightsubnet=192.168.58.0/24
  ike=aes256-sha2_256-modp1024!
  esp=aes256-sha2_256!
  keyingtries=0
  ikelifetime=1h
  lifetime=8h
  dpddelay=30
  dpdtimeout=120
  dpdaction=restart
  auto=start
  leftfirewall=yes

**SITE B - ipsec statusall:**

root@ns3141268:~# ipsec statusall
Status of IKE charon daemon (strongSwan 5.9.14, Linux 5.4.128-1-pve, x86_64):
  uptime: 39 minutes, since Jun 17 14:49:48 2024
  malloc: sbrk 3141632, mmap 0, used 1169600, free 1972032
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 7
  loaded plugins: charon test-vectors ldap pkcs11 aesni aes rc2 sha2 sha1 md5 mgf1 rdrand random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs12 pgp dnskey sshkey pem openssl gcrypt pkcs8 af-alg fips-prf gmp curve25519 agent chapoly xcbc cmac hmac kdf ctr ccm gcm drbg curl attr kernel-netlink resolve socket-default connmark farp stroke vici updown eap-identity eap-aka eap-md5 eap-gtc eap-mschapv2 eap-radius eap-tls eap-ttls eap-tnc xauth-generic xauth-eap xauth-pam tnc-tnccs dhcp lookip error-notify certexpire led duplicheck addrblock unity counters
Listening IP addresses:
  51.77.246.XX
  10.0.0.1
  192.168.60.1
Connections:
siteA-to-siteB:  %any...51.91.48.XX  IKEv1/2, dpddelay=30s
siteA-to-siteB:   local:  [51.77.246.XX] uses pre-shared key authentication
siteA-to-siteB:   remote: [51.91.48.XX] uses pre-shared key authentication
siteA-to-siteB:   child:  192.168.60.0/24 === 192.168.58.0/24 TUNNEL, dpdaction=start
Security Associations (1 up, 0 connecting):
siteA-to-siteB: ESTABLISHED 36 minutes ago, 51.77.246.XX[51.77.246.XX]...51.91.48.XX[51.91.48.XX]
siteA-to-siteB: IKEv2 SPIs: b50d4c5cf4d2eda4_i* ff26607335a4e302_r, pre-shared key reauthentication in 14 minutes
siteA-to-siteB: IKE proposal: AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024
siteA-to-siteB{3}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: c895872a_i c88bd63c_o
siteA-to-siteB{3}:  AES_CBC_256/HMAC_SHA2_256_128, 63420 bytes_i (755 pkts, 244s ago), 63420 bytes_o (755 pkts, 244s ago), rekeying in 7 hours
siteA-to-siteB{3}:   192.168.60.0/24 === 192.168.58.0/24

**SITE B - iptables-save:**

root@ns3141268:~# iptables-save
# Generated by iptables-save v1.8.2 on Mon Jun 17 15:30:48 2024
*mangle
:PREROUTING ACCEPT [801039226:571904713622]
:INPUT ACCEPT [5900102:843948109]
:FORWARD ACCEPT [724318127:567209958529]
:OUTPUT ACCEPT [5571837:852600977]
:POSTROUTING ACCEPT [726071655:567771378583]
COMMIT
# Completed on Mon Jun 17 15:30:48 2024
# Generated by iptables-save v1.8.2 on Mon Jun 17 15:30:48 2024
*nat
:PREROUTING ACCEPT [71190:4120186]
:INPUT ACCEPT [565:23428]
:OUTPUT ACCEPT [306:23214]
:POSTROUTING ACCEPT [639:35976]
-A PREROUTING -i vmbr0 -p udp -m udp --dport 50 -j ACCEPT
-A PREROUTING -i vmbr0 -p udp -m udp --dport 500 -j ACCEPT
-A PREROUTING -i vmbr0 -p udp -m udp --dport 4500 -j ACCEPT
-A PREROUTING -i vmbr0 -p udp -m udp --dport 1701 -j ACCEPT
-A PREROUTING -i vmbr0 -p esp -j ACCEPT
-A PREROUTING -i vmbr0 -p ah -j ACCEPT
-A PREROUTING -p udp -m udp --dport 50 -j ACCEPT
-A PREROUTING -i vmbr0 -p tcp -m multiport ! --dports 22,8006 -j DNAT --to-destination 10.0.0.2
-A PREROUTING -i vmbr0 -p udp -j DNAT --to-destination 10.0.0.2
-A POSTROUTING -s 10.0.0.0/30 -o vmbr0 -j MASQUERADE
COMMIT
# Completed on Mon Jun 17 15:30:48 2024
# Generated by iptables-save v1.8.2 on Mon Jun 17 15:30:48 2024
*raw
:PREROUTING ACCEPT [801041124:571905068039]
:OUTPUT ACCEPT [5573811:853003835]
COMMIT
# Completed on Mon Jun 17 15:30:48 2024
# Generated by iptables-save v1.8.2 on Mon Jun 17 15:30:48 2024
*filter
:INPUT DROP [437:33822]
:FORWARD DROP [4200:279708]
:OUTPUT DROP [42:3192]
:TCP - [0:0]
:UDP - [0:0]
:f2b-sshd - [0:0]
-A INPUT -p esp -j ACCEPT
-A INPUT -p ah -j ACCEPT
-A INPUT -p udp -m udp --dport 50 -j ACCEPT
-A INPUT -p udp -m udp --dport 500 -j ACCEPT
-A INPUT -p udp -m udp --dport 4500 -j ACCEPT
-A INPUT -p udp -m udp --dport 1701 -j ACCEPT
-A INPUT -p tcp -m multiport --dports 22 -j f2b-sshd
-A INPUT -p udp -m conntrack --ctstate NEW -j UDP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j TCP
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 8 -m conntrack --ctstate NEW -j ACCEPT
-A FORWARD -s 192.168.58.0/24 -d 192.168.60.0/24 -i vmbr0 -m policy --dir in --pol ipsec --reqid 1 --proto esp -j ACCEPT
-A FORWARD -s 192.168.60.0/24 -d 192.168.58.0/24 -o vmbr0 -m policy --dir out --pol ipsec --reqid 1 --proto esp -j ACCEPT
-A FORWARD -s 192.168.58.0/24 -d 192.168.60.0/24 -i vmbr0 -m policy --dir in --pol ipsec --reqid 1 --proto esp -j ACCEPT
-A FORWARD -s 192.168.60.0/24 -d 192.168.58.0/24 -o vmbr0 -m policy --dir out --pol ipsec --reqid 1 --proto esp -j ACCEPT
-A FORWARD -s 192.168.58.0/24 -d 192.168.60.0/24 -i vmbr0 -m policy --dir in --pol ipsec --reqid 1 --proto esp -j ACCEPT
-A FORWARD -s 192.168.60.0/24 -d 192.168.58.0/24 -o vmbr0 -m policy --dir out --pol ipsec --reqid 1 --proto esp -j ACCEPT
-A FORWARD -s 192.168.58.0/24 -d 192.168.60.0/24 -i vmbr0 -m policy --dir in --pol ipsec --reqid 1 --proto esp -j ACCEPT
-A FORWARD -s 192.168.60.0/24 -d 192.168.58.0/24 -o vmbr0 -m policy --dir out --pol ipsec --reqid 1 --proto esp -j ACCEPT
-A FORWARD -s 192.168.58.0/24 -d 192.168.60.0/24 -i vmbr0 -m policy --dir in --pol ipsec --reqid 1 --proto esp -j ACCEPT
-A FORWARD -s 192.168.60.0/24 -d 192.168.58.0/24 -o vmbr0 -m policy --dir out --pol ipsec --reqid 1 --proto esp -j ACCEPT
-A FORWARD -s 192.168.58.0/24 -d 192.168.60.0/24 -i vmbr0 -m policy --dir in --pol ipsec --reqid 1 --proto esp -j ACCEPT
-A FORWARD -s 192.168.60.0/24 -d 192.168.58.0/24 -o vmbr0 -m policy --dir out --pol ipsec --reqid 1 --proto esp -j ACCEPT
-A FORWARD -s 192.168.58.0/24 -d 192.168.60.0/24 -i vmbr0 -m policy --dir in --pol ipsec --reqid 1 --proto esp -j ACCEPT
-A FORWARD -s 192.168.60.0/24 -d 192.168.58.0/24 -o vmbr0 -m policy --dir out --pol ipsec --reqid 1 --proto esp -j ACCEPT
-A FORWARD -s 192.168.58.0/24 -d 192.168.60.0/24 -i vmbr0 -m policy --dir in --pol ipsec --reqid 1 --proto esp -j ACCEPT
-A FORWARD -s 192.168.60.0/24 -d 192.168.58.0/24 -o vmbr0 -m policy --dir out --pol ipsec --reqid 1 --proto esp -j ACCEPT
-A FORWARD -s 192.168.58.0/24 -d 192.168.60.0/24 -i vmbr0 -m policy --dir in --pol ipsec --reqid 1 --proto esp -j ACCEPT
-A FORWARD -s 192.168.60.0/24 -d 192.168.58.0/24 -o vmbr0 -m policy --dir out --pol ipsec --reqid 1 --proto esp -j ACCEPT
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -d 10.0.0.2/32 -i vmbr0 -o vmbr1 -p tcp -j ACCEPT
-A FORWARD -d 10.0.0.2/32 -i vmbr0 -o vmbr1 -p udp -j ACCEPT
-A FORWARD -s 10.0.0.0/30 -i vmbr1 -j ACCEPT
-A OUTPUT -p udp -m udp --dport 50 -j ACCEPT
-A OUTPUT -p udp -m udp --dport 500 -j ACCEPT
-A OUTPUT -p udp -m udp --dport 4500 -j ACCEPT
-A OUTPUT -p udp -m udp --dport 1701 -j ACCEPT
-A OUTPUT -p esp -j ACCEPT
-A OUTPUT -p ah -j ACCEPT
-A OUTPUT -p ah -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -p icmp -j ACCEPT
-A OUTPUT -s 10.0.0.2/32 -d 51.77.246.XX/32 -o vmbr0 -j ACCEPT
-A OUTPUT -s 51.77.246.XX/32 -o vmbr0 -p tcp -m tcp --dport 22 -j ACCEPT
-A OUTPUT -s 51.77.246.XX/32 -o vmbr0 -p udp -m udp --dport 53 -j ACCEPT
-A OUTPUT -s 51.77.246.XX/32 -o vmbr0 -p tcp -m tcp --dport 43 -j ACCEPT
-A OUTPUT -s 51.77.246.XX/32 -o vmbr0 -p tcp -m tcp --dport 80 -j ACCEPT
-A OUTPUT -s 51.77.246.XX/32 -o vmbr0 -p tcp -m tcp --dport 443 -j ACCEPT
-A OUTPUT -s 51.77.246.XX/32 -o vmbr0 -p tcp -m tcp --sport 22 -j ACCEPT
-A OUTPUT -s 51.77.246.XX/32 -o vmbr0 -p tcp -m tcp --sport 8006 -j ACCEPT
-A OUTPUT -s 10.0.0.1/32 -o vmbr1 -p tcp -m tcp --sport 22 -j ACCEPT
-A OUTPUT -s 10.0.0.1/32 -o vmbr1 -p tcp -m tcp --sport 8006 -j ACCEPT
-A TCP -d 51.77.246.XX/32 -i vmbr0 -p tcp -m tcp --dport 22 -j ACCEPT
-A TCP -d 51.77.246.XX/32 -i vmbr0 -p tcp -m tcp --dport 8006 -j ACCEPT
-A TCP -d 10.0.0.1/32 -i vmbr1 -p tcp -m tcp --dport 22 -j ACCEPT
-A TCP -d 10.0.0.1/32 -i vmbr1 -p tcp -m tcp --dport 8006 -j ACCEPT
-A f2b-sshd -j RETURN
COMMIT
# Completed on Mon Jun 17 15:30:48 2024

**SITE B - ip route list table 220:**

root@ns3141268:~# ip route list table 220
192.168.58.0/24 via 51.77.246.XX dev vmbr0 proto static src 192.168.60.1

**SITE B - Ping from Router to site SITE A Router:**

root@esxi:~# ping 192.168.58.1
PING 192.168.58.1 (192.168.58.1) 56(84) bytes of data.
64 bytes from 192.168.58.1: icmp_seq=1 ttl=64 time=1.80 ms
64 bytes from 192.168.58.1: icmp_seq=2 ttl=64 time=1.84 ms

**SITE B - Ping from Router to site SITE A Host:**

root@esxi:~# ping 192.168.58.254
PING 192.168.58.254 (192.168.58.254) 56(84) bytes of data.
64 bytes from 192.168.58.254: icmp_seq=1 ttl=63 time=2.03 ms
64 bytes from 192.168.58.254: icmp_seq=2 ttl=63 time=2.03 ms
64 bytes from 192.168.58.254: icmp_seq=3 ttl=63 time=2.09 ms

**SITE B - Ping from Host to site SITE A Router (NOT WORK):**

root@esxi:~# ping 192.168.58.1
PING 192.168.58.1 (192.168.58.1) 56(84) bytes of data.

**SITE B - Ping from Host to site SITE A Host(NOT WORK):**

root@esxi:~# ping 192.168.58.254
PING 192.168.58.254 (192.168.58.254 ) 56(84) bytes of data.

Anyone can help to understand why there is no communication from the hosts of each site? Best regards EDIT 1 - Added tcpdump capture tcpdump capture **from** Host Site B (192.168.60.254) to Host on site A (192.168.58.254) during ping **Ping output Host site B** root@fwprod:~# ping 192.168.58.254 PING 192.168.58.254 (192.168.58.254) 56(84) bytes of data. 0/70 packets, 100% loss **tcpdump capture Host Site B** tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes 00:42:02.458474 IP 192.168.60.254 > 192.168.58.254: ICMP echo request, id 15773, seq 1, length 64 00:42:02.460644 IP 192.168.58.254 > 192.168.60.254: ICMP echo reply, id 15773, seq 1, l ength 64 00:42:03.470239 IP 192.168.60.254 > 192.168.58.254: ICMP echo request, id 15773, seq 2, length 64 00:42:03.472375 IP 192.168.58.254 > 192.168.60.254: ICMP echo reply, id 15773, seq 2, l ength 64 00:42:04.490231 IP 192.168.60.254 > 192.168.58.254: ICMP echo request, id 15773, seq 3, length 64 00:42:04.492287 IP 192.168.58.254 > 192.168.60.254: ICMP echo reply, id 15773, seq 3, l ength 64 00:42:05.514251 IP 192.168.60.254 > 192.168.58.254: ICMP echo request, id 15773, seq 4, length 64 00:42:05.516320 IP 192.168.58.254 > 192.168.60.254: ICMP echo reply, id 15773, seq 4, l ength 64 **tcpdump capture Router Site B** tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes 22:44:17.553083 IP 192.168.60.254 > 192.168.58.254: ICMP echo request, id 15773, seq 1, length 64 22:44:17.553154 IP 192.168.60.254 > 192.168.58.254: ICMP echo request, id 15773, seq 1, length 64 22:44:17.553158 IP 192.168.60.254 > 192.168.58.254: ICMP echo request, id 15773, seq 1, length 64 22:44:17.553227 IP 192.168.58.254 > 192.168.60.254: ICMP echo reply, id 15773, seq 1, length 64 22:44:17.553227 IP 192.168.58.254 > 192.168.60.254: ICMP echo reply, id 15773, seq 1, length 64 22:44:18.564858 IP 192.168.60.254 > 192.168.58.254: ICMP echo request, id 15773, seq 2, length 64 22:44:18.564924 IP 192.168.60.254 > 192.168.58.254: ICMP echo request, id 15773, seq 2, length 64 22:44:18.564928 IP 192.168.60.254 > 192.168.58.254: ICMP echo request, id 15773, seq 2, length 64 22:44:18.565002 IP 192.168.58.254 > 192.168.60.254: ICMP echo reply, id 15773, seq 2, length 64 22:44:18.565002 IP 192.168.58.254 > 192.168.60.254: ICMP echo reply, id 15773, seq 2, length 64 22:44:19.584836 IP 192.168.60.254 > 192.168.58.254: ICMP echo request, id 15773, seq 3, length 64 22:44:19.584904 IP 192.168.60.254 > 192.168.58.254: ICMP echo request, id 15773, seq 3, length 64 22:44:19.584909 IP 192.168.60.254 > 192.168.58.254: ICMP echo request, id 15773, seq 3, length 64 22:44:19.584977 IP 192.168.58.254 > 192.168.60.254: ICMP echo reply, id 15773, seq 3, length 64 22:44:19.584977 IP 192.168.58.254 > 192.168.60.254: ICMP echo reply, id 15773, seq 3, length 64 22:44:20.608902 IP 192.168.60.254 > 192.168.58.254: ICMP echo request, id 15773, seq 4, length 64 22:44:20.608965 IP 192.168.60.254 > 192.168.58.254: ICMP echo request, id 15773, seq 4, length 64 22:44:20.608970 IP 192.168.60.254 > 192.168.58.254: ICMP echo request, id 15773, seq 4, length 64 22:44:20.609031 IP 192.168.58.254 > 192.168.60.254: ICMP echo reply, id 15773, seq 4, length 64 22:44:20.609031 IP 192.168.58.254 > 192.168.60.254: ICMP echo reply, id 15773, seq 4, length 64 22:44:21.632920 IP 192.168.60.254 > 192.168.58.254: ICMP echo request, id 15773, seq 5, length 64 22:44:21.632979 IP 192.168.60.254 > 192.168.58.254: ICMP echo request, id 15773, seq 5, length 64 22:44:21.632984 IP 192.168.60.254 > 192.168.58.254: ICMP echo request, id 15773, seq 5, length 64 22:44:21.633052 IP 192.168.58.254 > 192.168.60.254: ICMP echo reply, id 15773, seq 5, length 64 22:44:21.633052 IP 192.168.58.254 > 192.168.60.254: ICMP echo reply, id 15773, seq 5, length 64 22:44:22.657009 IP 192.168.60.254 > 192.168.58.254: ICMP echo request, id 15773, seq 6, length 64 **tcpdump capture Router Site A** tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes 22:44:17.553083 IP 192.168.60.254 > 192.168.58.254: ICMP echo request, id 15773, seq 1, length 64 22:44:17.553154 IP 192.168.60.254 > 192.168.58.254: ICMP echo request, id 15773, seq 1, length 64 22:44:17.553158 IP 192.168.60.254 > 192.168.58.254: ICMP echo request, id 15773, seq 1, length 64 22:44:17.553227 IP 192.168.58.254 > 192.168.60.254: ICMP echo reply, id 15773, seq 1, length 64 22:44:17.553227 IP 192.168.58.254 > 192.168.60.254: ICMP echo reply, id 15773, seq 1, length 64 22:44:18.564858 IP 192.168.60.254 > 192.168.58.254: ICMP echo request, id 15773, seq 2, length 64 22:44:18.564924 IP 192.168.60.254 > 192.168.58.254: ICMP echo request, id 15773, seq 2, length 64 22:44:18.564928 IP 192.168.60.254 > 192.168.58.254: ICMP echo request, id 15773, seq 2, length 64 22:44:18.565002 IP 192.168.58.254 > 192.168.60.254: ICMP echo reply, id 15773, seq 2, length 64 22:44:18.565002 IP 192.168.58.254 > 192.168.60.254: ICMP echo reply, id 15773, seq 2, length 64 22:44:19.584836 IP 192.168.60.254 > 192.168.58.254: ICMP echo request, id 15773, seq 3, length 64 22:44:19.584904 IP 192.168.60.254 > 192.168.58.254: ICMP echo request, id 15773, seq 3, length 64 22:44:19.584909 IP 192.168.60.254 > 192.168.58.254: ICMP echo request, id 15773, seq 3, length 64 22:44:19.584977 IP 192.168.58.254 > 192.168.60.254: ICMP echo reply, id 15773, seq 3, length 64 22:44:19.584977 IP 192.168.58.254 > 192.168.60.254: ICMP echo reply, id 15773, seq 3, length 64 22:44:20.608902 IP 192.168.60.254 > 192.168.58.254: ICMP echo request, id 15773, seq 4, length 64 22:44:20.608965 IP 192.168.60.254 > 192.168.58.254: ICMP echo request, id 15773, seq 4, length 64 22:44:20.608970 IP 192.168.60.254 > 192.168.58.254: ICMP echo request, id 15773, seq 4, length 64 22:44:20.609031 IP 192.168.58.254 > 192.168.60.254: ICMP echo reply, id 15773, seq 4, length 64 22:44:20.609031 IP 192.168.58.254 > 192.168.60.254: ICMP echo reply, id 15773, seq 4, length 64 22:44:21.632920 IP 192.168.60.254 > 192.168.58.254: ICMP echo request, id 15773, seq 5, length 64 22:44:21.632979 IP 192.168.60.254 > 192.168.58.254: ICMP echo request, id 15773, seq 5, length 64 22:44:21.632984 IP 192.168.60.254 > 192.168.58.254: ICMP echo request, id 15773, seq 5, length 64 22:44:21.633052 IP 192.168.58.254 > 192.168.60.254: ICMP echo reply, id 15773, seq 5, length 64 22:44:21.633052 IP 192.168.58.254 > 192.168.60.254: ICMP echo reply, id 15773, seq 5, length 64 22:44:22.657009 IP 192.168.60.254 > 192.168.58.254: ICMP echo request, id 15773, seq 6, length 64 **tcpdump capture Host Site A** listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes 00:44:16.587371 IP 192.168.60.254 > fw.artica.local: ICMP echo request, id 15773, seq 1 , length 64 00:44:16.587410 IP fw.artica.local > 192.168.60.254: ICMP echo reply, id 15773, seq 1, length 64 00:44:17.599143 IP 192.168.60.254 > fw.artica.local: ICMP echo request, id 15773, seq 2 , length 64 00:44:17.599179 IP fw.artica.local > 192.168.60.254: ICMP echo reply, id 15773, seq 2, length 64 00:44:18.619118 IP 192.168.60.254 > fw.artica.local: ICMP echo request, id 15773, seq 3 , length 64 00:44:18.619155 IP fw.artica.local > 192.168.60.254: ICMP echo reply, id 15773, seq 3, length 64 00:44:19.643177 IP 192.168.60.254 > fw.artica.local: ICMP echo request, id 15773, seq 4 , length 64 00:44:19.643208 IP fw.artica.local > 192.168.60.254: ICMP echo reply, id 15773, seq 4, length 64

Previously it was in ipsec statusall. Now with swanctl I can only see swanctl --list-conns but it only shows the configuration details, not the runtime statistics: eg bytes transferred, negotiated ciphersuites, reauth/rekeying stats, and so on and so forth. So, is there any similar command in the "new" strongswan configuration?

For some reason OpenVPN is working on my local machine very well, But IPSec IKEV2 VPN not & it only works when OpenVPN is connect. I have a domain for IPSec IKEV2 VPN & in local machine vpn is using port 443. Tell what should i do to force vpn workable on my local machine without OpenVPN. Should i change port 443 on server or change ports 500 & 4500? I followed the link below for setup IKEv2 VPN Using Strongswan and Let's encrypt on CentOS 7 With Some Changes. How to Setup IKEv2 VPN Using Strongswan and Let's encrypt on CentOS 7 My Let's encrypt commands is like this : curl https://get.acme.sh | sh ~/.acme.sh/acme.sh --set-default-ca --server letsencrypt ~/.acme.sh/acme.sh --register-account -m helius.dev@gmail.com ~/.acme.sh/acme.sh --issue -d my_domain.com --keylength 4096 --standalone --force service httpd stop ~/.acme.sh/acme.sh --issue -d my_domain.com --keylength 4096 --standalone --force Your cert is in: /root/.acme.sh/my_domain.com/my_domain.com.cer Your cert key is in: /root/.acme.sh/my_domain.com/my_domain.com.key The intermediate CA cert is in: /root/.acme.sh/my_domain.com/ca.cer And the full chain certs is there: /root/.acme.sh/my_domain.com/fullchain.cer ~/.acme.sh/acme.sh --installcert -d my_domain.com --keylength 4096 --key-file /root/private.key --fullchain-file /root/cert.crt service httpd start service httpd status Certificate Copy : sudo cp /root/private.key /etc/strongswan/ipsec.d/private/ sudo cp /root/cert.crt /etc/strongswan/ipsec.d/certs/ sudo cp /root/.acme.sh/p02.artemis-art.buzz/ca.cer /etc/strongswan/ipsec.d/cacerts/ StrongSwan config : #global configuration IPsec #chron logger config setup charondebug="ike 1, knl 1, cfg 0" uniqueids=no #define new ipsec connection conn hakase-vpn auto=add compress=no type=tunnel keyexchange=ikev2 ike=aes128-sha1-modp1024,aes128-sha1-modp1536,aes128-sha1-modp2048,aes128-sha256-ecp256,aes128-sha256-modp1024,aes128-sha256-modp1536,aes128-sha256-modp2048,aes256-aes128-sha256-sha1-modp2048-modp4096-modp1024,aes256-sha1-modp1024,aes256-sha256-modp1024,aes256-sha256-modp1536,aes256-sha256-modp2048,aes256-sha256-modp4096,aes256-sha384-ecp384,aes256-sha384-modp1024,aes256-sha384-modp1536,aes256-sha384-modp2048,aes256-sha384-modp4096,aes256gcm16-aes256gcm12-aes128gcm16-aes128gcm12-sha256-sha1-modp2048-modp4096-modp1024,3des-sha1-modp1024! esp=aes128-aes256-sha1-sha256-modp2048-modp4096-modp1024,aes128-sha1,aes128-sha1-modp1024,aes128-sha1-modp1536,aes128-sha1-modp2048,aes128-sha256,aes128-sha256-ecp256,aes128-sha256-modp1024,aes128-sha256-modp1536,aes128-sha256-modp2048,aes128gcm12-aes128gcm16-aes256gcm12-aes256gcm16-modp2048-modp4096-modp1024,aes128gcm16,aes128gcm16-ecp256,aes256-sha1,aes256-sha256,aes256-sha256-modp1024,aes256-sha256-modp1536,aes256-sha256-modp2048,aes256-sha256-modp4096,aes256-sha384,aes256-sha384-ecp384,aes256-sha384-modp1024,aes256-sha384-modp1536,aes256-sha384-modp2048,aes256-sha384-modp4096,aes256gcm16,aes256gcm16-ecp384,3des-sha1! fragmentation=yes forceencaps=yes dpdaction=clear dpddelay=300s rekey=no left=%any leftid=@my_domain.com leftcert=cert.crt leftsendcert=always leftsubnet=0.0.0.0/0 right=%any rightid=%any rightauth=eap-mschapv2 rightsourceip=10.15.1.0/24 rightdns=1.1.1.1,8.8.8.8 rightsendcert=never eap_identity=%identity And here is secrets file : nano -K /etc/strongswan/ipsec.secrets : RSA "private.key" test : EAP "123" Let explain problem again. Some firewall rules on my wi-fi internet provider are blocking vpn (ikev2 - l2tp - pptp) But openvps works like a charm. When openvpn is working i can connect to ikev2 vpn by upper config. Tell me what should i change about ikev2 to work whithout openvpn. Fist step i think i should chanage ports 500 & 4500 on server. I am right? But how? **/etc/strongswan/ipsec.d/** This file has no place for define custom ports!!!

I am testing FRR DMVPN using Strongswan IPSec + GRE. Tunnels work great and they are easily established between the branch offices. Tunnels work great and they are easily established between the branch offices. circuit. I tried to use AES-GCM encapsulation and tweak the TCP-MSS & MTU. however, I am not getting the desired results. CPU: Xeon 2nd Generation scalable. 6 cores per VM. 4 GB RAM - Ubuntu 20.04 I tried to use AES-GCM encapsulation and tweak the TCP-MSS & MTU. however, I am getting 30-50 Mb/s speed instead of 400 Mb/s which I get without IPsec. Here are my sample IPsec configs for reference

conn dmvpn
authby=secret
auto=add
keyexchange=ikev1
ike=aes128gcm16-aesxcbc-modp2048
esp=aes128gcm16-modp1024
dpdaction=clear
dpddelay=300s
left=%any
leftid=%any
right=%any
rightid=%any
leftprotoport=gre
rightprotoport=gre
type=transport
keyingtries=%forever

Would someone be able to help me with this? Let me know if I am missing anything or need more details.

## Context I have set up a site-to-site IPSec tunnel between a Raspberry Pi located in an office and a pfSense firewall in the cloud. I am using Strongswan for the Raspberry Pi side. ## Issue My tunnel establishes and works fine for a while, but when it has to rekey itself, the negotiation fails. Is there something obvious I am missing? ### Logs (Raspberry side) #### Initial connection

raspberrypi charon: 09[IKE] received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
raspberrypi charon: 09[CFG] selected proposal: ESP:AES_CBC_128/HMAC_SHA2_256_128/NO_EXT_SEQ
raspberrypi charon: 09[IKE] CHILD_SA net-net{1} established with SPIs c3eaa3c7_i c944ab71_o and TS RASPI_NET/24 === PFSENSE_NET/16
raspberrypi charon: 09[IKE] CHILD_SA net-net{1} established with SPIs c3eaa3c7_i c944ab71_o and TS RASPI_NET/24 === PFSENSE_NET/16

#### Rekeying (that's where it goes wrong)

raspberrypi charon: 11[NET] received packet: from PFSENSE_IP to RASPI_LOCAL_IP (80 bytes)
raspberrypi charon: 11[ENC] parsed INFORMATIONAL request 153 [ D ]
raspberrypi charon: 11[IKE] received DELETE for ESP CHILD_SA with SPI ce632e5b
raspberrypi charon: 11[IKE] closing CHILD_SA net-net{1} with SPIs ccc38dd0_i (94042284 bytes) ce632e5b_o (5169556 bytes) and TS RASPI_NET/24 === PFSENSE_NET/16
raspberrypi charon: 11[IKE] closing CHILD_SA net-net{1} with SPIs ccc38dd0_i (94042284 bytes) ce632e5b_o (5169556 bytes) and TS RASPI_NET/24 === PFSENSE_NET/16
raspberrypi charon: 11[IKE] sending DELETE for ESP CHILD_SA with SPI ccc38dd0
raspberrypi charon: 11[IKE] CHILD_SA closed
raspberrypi charon: 11[ENC] generating INFORMATIONAL response 153 [ D ]
raspberrypi charon: 11[NET] sending packet: from RASPI_LOCAL_IP to PFSENSE_IP (80 bytes)
raspberrypi charon: 12[NET] received packet: from PFSENSE_IP to RASPI_LOCAL_IP (80 bytes)
raspberrypi charon: 12[ENC] parsed INFORMATIONAL request 154 [ ]
raspberrypi charon: 12[ENC] generating INFORMATIONAL response 154 [ ]
raspberrypi charon: 12[NET] sending packet: from RASPI_LOCAL_IP to PFSENSE_IP (80 bytes)
raspberrypi charon: 06[NET] received packet: from PFSENSE_IP to RASPI_LOCAL_IP (640 bytes)
raspberrypi charon: 06[ENC] parsed CREATE_CHILD_SA request 155 [ N(ESP_TFC_PAD_N) SA No KE TSi TSr ]
raspberrypi charon: 06[IKE] received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
raspberrypi charon: 06[CFG] received proposals: ESP:AES_GCM_16_256/MODP_2048/NO_EXT_SEQ, ESP:AES_GCM_12_256/MODP_2048/NO_EXT_SEQ, ESP:AES_GCM_8_256/MODP_2048/NO_EXT_SEQ, ESP:AES_GCM_16_128/MODP_2048/NO_EXT_SEQ, ESP:AES_CBC_128/HMAC_SHA2_256_128/MODP_2048/NO_EXT_SEQ
raspberrypi charon: 06[CFG] configured proposals: ESP:AES_GCM_16_128/AES_GCM_16_192/AES_GCM_16_256, ESP:AES_CBC_128/AES_CBC_192/AES_CBC_256/HMAC_SHA2_256_128/HMAC_SHA2_384_192/HMAC_SHA2_512_256/HMAC_SHA1_96/AES_XCBC_96/NO_EXT_SEQ
raspberrypi charon: 06[IKE] no acceptable proposal found
raspberrypi charon: 06[IKE] failed to establish CHILD_SA, keeping IKE_SA
raspberrypi charon: 06[ENC] generating CREATE_CHILD_SA response 155 [ N(NO_PROP) ]
raspberrypi charon: 06[NET] sending packet: from RASPI_LOCAL_IP to PFSENSE_IP (80 bytes)
raspberrypi charon: 01[JOB] CHILD_SA ESP/0xccc38dd0/RASPI_LOCAL_IP not found for rekey
raspberrypi charon: 08[JOB] CHILD_SA ESP/0xccc38dd0/RASPI_LOCAL_IP not found for rekey

## What I have tried to do If I SSH to the Raspberry and run ipsec restart, the tunnel establishes again and works fine until the next rekeying. I am having trouble understanding why the proposals do not match on rekeying if they do for the initial connection. Furthermore, I did ask for different algorithms inside of my swanctl configuration file. I tried changing the configuration both sides, but it seems that the issue is always located on the side of the Raspberry (by the way, the pfSense is responder-only). ## Configuration files ### /etc/swanctl/conf.d/myfile.conf

connections {
  gw-gw {
    local_addrs = RASPI_LAN_IP
    remote_addrs = PFSENSE_IP
    local {
      auth = psk
      id = RASPI_PUBLIC_IP
    }
    remote {
      auth = psk
      id = PFSENSE_IP
    }
    children {
      net-net {
        local_ts = RASPI_NET/24
        remote_ts = PFSENSE_NET/16
        start_action = start
        dpd_action = restart
      }
    }
    version = 2
    dpd_delay = 60
    mobike = no
    proposals = aes128-sha256-modp2048,default
  }
}

secrets {
  ike-1 {
    id-1 = RASPI_PUBLIC_IP
    id-2 = PFSENSE_IP
    secret = "MYPSK"
  }
}

### pfSense #### Phase 1 #### Phase 2

Environment: Debian 10, KDE, Full desktop # ipsec --version Linux strongSwan U5.7.2/K4.19.0-6-amd64 # swanctl --version strongSwan swanctl 5.7.2 # systemctl status strongswan ● strongswan.service - strongSwan IPsec IKEv1/IKEv2 daemon using ipsec.conf Loaded: loaded (/lib/systemd/system/strongswan.service; enabled; vendor preset: enabled) Active: inactive (dead) since Fri 2019-12-13 09:35:03 -03; 4h 34min ago Process: 6067 ExecStart=/usr/sbin/ipsec start --nofork (code=exited, status=0/SUCCESS) Main PID: 6067 (code=exited, status=0/SUCCESS) # systemctl status strongswan-swanctl ● strongswan-swanctl.service - strongSwan IPsec IKEv1/IKEv2 daemon using swanctl Loaded: loaded (/lib/systemd/system/strongswan-swanctl.service; enabled; vendor preset: enabled) Active: active (running) since Fri 2019-12-13 09:11:34 -03; 4h 56min ago Main PID: 6373 (charon-systemd) Status: "charon-systemd running, strongSwan 5.7.2, Linux 4.19.0-6-amd64, x86_64" Tasks: 17 (limit: 4915) Memory: 8.5M CGroup: /system.slice/strongswan-swanctl.service └─6373 /usr/sbin/charon-systemd After spending almost two days learning and poking around IPSec and IKEv2 I managed to connect to the company gateway (Lancom LCOS, IKEv2 PSK, User-FQDN identities) using strongswan and swanctl. After a reboot I have to run the following commands:

sudo /usr/sbin/swanctl --load-all

no files found matching '/etc/swanctl/conf.d/*.conf'
loaded ike secret 'ike'
no authorities found, 0 unloaded
no pools found, 0 unloaded
loaded connection 'IKEv2PSK'
successfully loaded 1 connections, 0 unloaded

and then sudo /usr/sbin/swanctl --initiate --child myVpn [IKE] establishing CHILD_SA myVpn{2} ... lots of log lines ... initiate completed successfully I'd like to have the tunnel started automatically, maybe using a systemd unit something like

sudo systemctl swanctl-myVpn start

However I don't find any documentation how to achieve this, which also makes me wonder if this is a bad idea?

I am trying to build a site-to-site IPSec VPN based on Ubuntu 20.04.1 and StrongSwan. My goal is to interconnect the two sites without using NAT on the gateways. In my lab I have: I could get IPSec working. From the Ubuntu on the left site I can ping 172.16.1.254 (the internal Site B gateway IP address). However, if I try to ping a machine on Site B other than 172.16.1.254 address it fails. Following some tutorials I have: - enabled routing at /etc/sysctl.conf by includding net.ipv4.ip_forward = 1; then run sysctl -p. - added IPSec services to the public zone by firewall-cmd --permanent --zone=public --add-service=ipsec and firewall-cmd --reload. - in both sites the internal interface is bound to the trusted native zone and external interfaces are bound to the "public" native zone. What am I missing? Can someone help me?

Im trying to establish a vpn connection with a self signed certificate between 2 virtual machines in my M1 mac and it seems that its impossible to create the keys and the certificate due to the titles error. ive tried almost anything can anyone drop any ideas? thx a lot Idomeneas i updated ipsec(Linux strongSwan U5.9.8/K6.0.0-kali3-arm64 ) openssl (openssl is already the newest version (3.0.7-1).) kali linux 2022.2 arm 64

I have a linux (currently centos 8 but I can change it to anything) server running as l2tp VPN Server which has two network interfaces as below: NIC1: 192.168.1.4/24 NIC2: 192.168.3.2/24 Default gateway for server is 192.168.1.1 but I want to set 192.168.3.1 as vpn users default gateway. 192.168.3.1 is another router in my network. I currently use libreswan but I am open to change it to anything that does the job! Tried to read ipsec.conf file but couldn't find any related line.

For some reason, my network encountered "Destination unreachable no route" error, this error happened periodicly, later I found that was a bug of my program. But during that time, I found a werid problem: if I started a ping when network worked, then ping could work continuously even later the network had route problem. I use iptables trace and found those iptables rules were applied when the ping process were working:

raw:PREROUTING:policy:2
nat:PREROUTING:policy:1
filter:FORWARD:rule:1
filter:FABEDGE-FORWARD:rule:1
nat:POSTROUTING:rule:1
nat:FABEDGE-NAT-OUTGOING:rule:2
nat:POSTROUTING:policy:2
raw:PREROUTING:policy:2
filter:FORWARD:rule:1
filter:FABEDGE-FORWARD:rule:1
raw:PREROUTING:policy:2
filter:FORWARD:rule:1
filter:FABEDGE-FORWARD:rule:1
raw:PREROUTING:policy:2
filter:FORWARD:rule:1
filter:FABEDGE-FORWARD:rule:1

As you can see, when the first ICMP6 packet is handled, those rules are applied:

raw:PREROUTING:policy:2
nat:PREROUTING:policy:1
filter:FORWARD:rule:1
filter:FABEDGE-FORWARD:rule:1
nat:POSTROUTING:rule:1
nat:FABEDGE-NAT-OUTGOING:rule:2
nat:POSTROUTING:policy:2

the following ICMP6 packets were handled with different rules:

raw:PREROUTING:policy:2
filter:FORWARD:rule:1
filter:FABEDGE-FORWARD:rule:1

It looks like all nat tables rules are skipped, I don't known why this happened. Shouldn't each ICMP6 packet go through the same rules? I should metion that these packets will pass through a VPN tunnel created by a strongswan process which I don't think will affect the iptables. These are my iptables rules:

ip6tables -t raw -S
-P PREROUTING ACCEPT
-P OUTPUT ACCEPT
-A PREROUTING -s fd96:ee88:2:2::/64 -j TRACE

[root@edge1 ~]# ip6tables  -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-N FABEDGE-FORWARD
-A FORWARD -j FABEDGE-FORWARD
-A FABEDGE-FORWARD -s fd96:ee88:2:2::/64 -j ACCEPT
-A FABEDGE-FORWARD -d fd96:ee88:2:2::/64 -j ACCEPT

ip6tables -t nat -S
-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
-N FABEDGE-NAT-OUTGOING
-A POSTROUTING -j FABEDGE-NAT-OUTGOING
-A FABEDGE-NAT-OUTGOING -m set --match-set FABEDGE-LOOP-BACK6 dst,dst,src -j MASQUERADE
-A FABEDGE-NAT-OUTGOING -s fd96:ee88:2:2::/64 -m set --match-set FABEDGE-PEER-CIDR6 dst -j RETURN
-A FABEDGE-NAT-OUTGOING -s fd96:ee88:2:2::/64 -d fd96:ee88:2:2::/64 -j RETURN
-A FABEDGE-NAT-OUTGOING -s fd96:ee88:2:2::/64 -j MASQUERADE

More detailed iptables trace:

[505397.327144] TRACE: raw:PREROUTING:policy:2 IN=br-fabedge OUT= PHYSIN=veth74551420 MAC=ce:3f:04:b1:31:31:ee:13:75:3e:4c:14:86:dd SRC=fd96:ee88:0002:0002:0000:0000:0000:000e DST=fd96:ee88:0000:0001:0000:0000:0000:0025 LEN=104 TC=0 HOPLIMIT=64 FLOWLBL=0 PROTO=ICMPv6 TYPE=128 CODE=0 ID=3889 SEQ=1
[505397.327183] TRACE: nat:PREROUTING:policy:1 IN=br-fabedge OUT= PHYSIN=veth74551420 MAC=ce:3f:04:b1:31:31:ee:13:75:3e:4c:14:86:dd SRC=fd96:ee88:0002:0002:0000:0000:0000:000e DST=fd96:ee88:0000:0001:0000:0000:0000:0025 LEN=104 TC=0 HOPLIMIT=64 FLOWLBL=0 PROTO=ICMPv6 TYPE=128 CODE=0 ID=3889 SEQ=1
[505397.327207] TRACE: filter:FORWARD:rule:1 IN=br-fabedge OUT=eth0 PHYSIN=veth74551420 MAC=ce:3f:04:b1:31:31:ee:13:75:3e:4c:14:86:dd SRC=fd96:ee88:0002:0002:0000:0000:0000:000e DST=fd96:ee88:0000:0001:0000:0000:0000:0025 LEN=104 TC=0 HOPLIMIT=63 FLOWLBL=0 PROTO=ICMPv6 TYPE=128 CODE=0 ID=3889 SEQ=1
[505397.327215] TRACE: filter:FABEDGE-FORWARD:rule:1 IN=br-fabedge OUT=eth0 PHYSIN=veth74551420 MAC=ce:3f:04:b1:31:31:ee:13:75:3e:4c:14:86:dd SRC=fd96:ee88:0002:0002:0000:0000:0000:000e DST=fd96:ee88:0000:0001:0000:0000:0000:0025 LEN=104 TC=0 HOPLIMIT=63 FLOWLBL=0 PROTO=ICMPv6 TYPE=128 CODE=0 ID=3889 SEQ=1
[505397.327223] TRACE: nat:POSTROUTING:rule:1 IN= OUT=eth0 PHYSIN=veth74551420 SRC=fd96:ee88:0002:0002:0000:0000:0000:000e DST=fd96:ee88:0000:0001:0000:0000:0000:0025 LEN=104 TC=0 HOPLIMIT=63 FLOWLBL=0 PROTO=ICMPv6 TYPE=128 CODE=0 ID=3889 SEQ=1
[505397.327241] TRACE: nat:FABEDGE-NAT-OUTGOING:rule:2 IN= OUT=eth0 PHYSIN=veth74551420 SRC=fd96:ee88:0002:0002:0000:0000:0000:000e DST=fd96:ee88:0000:0001:0000:0000:0000:0025 LEN=104 TC=0 HOPLIMIT=63 FLOWLBL=0 PROTO=ICMPv6 TYPE=128 CODE=0 ID=3889 SEQ=1
[505397.327246] TRACE: nat:POSTROUTING:policy:2 IN= OUT=eth0 PHYSIN=veth74551420 SRC=fd96:ee88:0002:0002:0000:0000:0000:000e DST=fd96:ee88:0000:0001:0000:0000:0000:0025 LEN=104 TC=0 HOPLIMIT=63 FLOWLBL=0 PROTO=ICMPv6 TYPE=128 CODE=0 ID=3889 SEQ=1
[505398.328257] TRACE: raw:PREROUTING:policy:2 IN=br-fabedge OUT= PHYSIN=veth74551420 MAC=ce:3f:04:b1:31:31:ee:13:75:3e:4c:14:86:dd SRC=fd96:ee88:0002:0002:0000:0000:0000:000e DST=fd96:ee88:0000:0001:0000:0000:0000:0025 LEN=104 TC=0 HOPLIMIT=64 FLOWLBL=0 PROTO=ICMPv6 TYPE=128 CODE=0 ID=3889 SEQ=2
[505398.328290] TRACE: filter:FORWARD:rule:1 IN=br-fabedge OUT=eth0 PHYSIN=veth74551420 MAC=ce:3f:04:b1:31:31:ee:13:75:3e:4c:14:86:dd SRC=fd96:ee88:0002:0002:0000:0000:0000:000e DST=fd96:ee88:0000:0001:0000:0000:0000:0025 LEN=104 TC=0 HOPLIMIT=63 FLOWLBL=0 PROTO=ICMPv6 TYPE=128 CODE=0 ID=3889 SEQ=2
[505398.328299] TRACE: filter:FABEDGE-FORWARD:rule:1 IN=br-fabedge OUT=eth0 PHYSIN=veth74551420 MAC=ce:3f:04:b1:31:31:ee:13:75:3e:4c:14:86:dd SRC=fd96:ee88:0002:0002:0000:0000:0000:000e DST=fd96:ee88:0000:0001:0000:0000:0000:0025 LEN=104 TC=0 HOPLIMIT=63 FLOWLBL=0 PROTO=ICMPv6 TYPE=128 CODE=0 ID=3889 SEQ=2
[505399.329386] TRACE: raw:PREROUTING:policy:2 IN=br-fabedge OUT= PHYSIN=veth74551420 MAC=ce:3f:04:b1:31:31:ee:13:75:3e:4c:14:86:dd SRC=fd96:ee88:0002:0002:0000:0000:0000:000e DST=fd96:ee88:0000:0001:0000:0000:0000:0025 LEN=104 TC=0 HOPLIMIT=64 FLOWLBL=0 PROTO=ICMPv6 TYPE=128 CODE=0 ID=3889 SEQ=3
[505399.329431] TRACE: filter:FORWARD:rule:1 IN=br-fabedge OUT=eth0 PHYSIN=veth74551420 MAC=ce:3f:04:b1:31:31:ee:13:75:3e:4c:14:86:dd SRC=fd96:ee88:0002:0002:0000:0000:0000:000e DST=fd96:ee88:0000:0001:0000:0000:0000:0025 LEN=104 TC=0 HOPLIMIT=63 FLOWLBL=0 PROTO=ICMPv6 TYPE=128 CODE=0 ID=3889 SEQ=3
[505399.329440] TRACE: filter:FABEDGE-FORWARD:rule:1 IN=br-fabedge OUT=eth0 PHYSIN=veth74551420 MAC=ce:3f:04:b1:31:31:ee:13:75:3e:4c:14:86:dd SRC=fd96:ee88:0002:0002:0000:0000:0000:000e DST=fd96:ee88:0000:0001:0000:0000:0000:0025 LEN=104 TC=0 HOPLIMIT=63 FLOWLBL=0 PROTO=ICMPv6 TYPE=128 CODE=0 ID=3889 SEQ=3
[505400.329280] TRACE: raw:PREROUTING:policy:2 IN=br-fabedge OUT= PHYSIN=veth74551420 MAC=ce:3f:04:b1:31:31:ee:13:75:3e:4c:14:86:dd SRC=fd96:ee88:0002:0002:0000:0000:0000:000e DST=fd96:ee88:0000:0001:0000:0000:0000:0025 LEN=104 TC=0 HOPLIMIT=64 FLOWLBL=0 PROTO=ICMPv6 TYPE=128 CODE=0 ID=3889 SEQ=4
[505400.329315] TRACE: filter:FORWARD:rule:1 IN=br-fabedge OUT=eth0 PHYSIN=veth74551420 MAC=ce:3f:04:b1:31:31:ee:13:75:3e:4c:14:86:dd SRC=fd96:ee88:0002:0002:0000:0000:0000:000e DST=fd96:ee88:0000:0001:0000:0000:0000:0025 LEN=104 TC=0 HOPLIMIT=63 FLOWLBL=0 PROTO=ICMPv6 TYPE=128 CODE=0 ID=3889 SEQ=4
[505400.329324] TRACE: filter:FABEDGE-FORWARD:rule:1 IN=br-fabedge OUT=eth0 PHYSIN=veth74551420 MAC=ce:3f:04:b1:31:31:ee:13:75:3e:4c:14:86:dd SRC=fd96:ee88:0002:0002:0000:0000:0000:000e DST=fd96:ee88:0000:0001:0000:0000:0000:0025 LEN=104 TC=0 HOPLIMIT=63 FLOWLBL=0 PROTO=ICMPv6 TYPE=128 CODE=0 ID=3889 SEQ=4

I have a Raspberry Pi 4B with Raspbian arm64 on it running a Strongswan VPN server alongside multiple services that I can access frow WAN via my external IP/my domain name. I use NAT reflection on my router so that I can use those same services from my LAN. The VPN routing seems to be working correctly, as I can access the internet and any devices on the LAN from any VPN device. Similarly, I can also ping any VPN device from my LAN. The problem arises when I try to access my web services via my domain name. The same services that I am normally able to access from both LAN and WAN are inaccessible for my VPN devices. If I forward a port of a different device on the LAN and try to access that on a VPN device via the domain name then that works just fine. As such, the routing and NAT reflection of my network setup both seem to be fine. It's only when I try to access websites hosted on the same server as the VPN via the domain name/external IP (accessing websites via the local IP works fine) that things don't work as expected. I conclude that something goes wrong on the routing side of things of my Raspberry Pi, however I am clueless as to where to begin debugging. As such, I'm not sure which configuration files would by useful to post here. I'll be happy to send any furter information that is necessary to help me solve this issue. My Strongswan config: conn ikev2-rsa auto=add compress=no type=tunnel keyexchange=ikev2 fragmentation=yes forceencaps=yes dpdaction=clear dpddelay=300s left=%any leftid=@example.com (this is set to my real domain name) leftcert=strongswan-cert.pem leftsendcert=always leftsubnet=0.0.0.0/0,::/0 right=%any rightid=%any rightauth=pubkey rightsourceip=10.2.1.0/24 rightdns=10.0.0.4 rightsendcert=never

I am running into something interesting which I am not able to explain well. I brought up a simple Ubuntu 20.04 box and attempting to protect all traffic via an IPSec tunnel. I am not using VTI or xfrm interface and simply negotiating 0.0.0.0 as TS each end. Without Ipsec tunnel, everything works fine. Now when I initiate the tunnel, tunnels comes up fine. Now when I run iperf TCP test, it works fine. Packets flow over tunnel, come back and hit the application and I get expected throughput. When I run ping test, they work well as well. The problem is WebTraffic. When I do wget or try using a browser, I see traffic flowing well and coming back to my Ubuntu 20 node, however it never reaches the application. So wget never sees the replies, however TCP connection as expected gets ESTAB and in wireshark I do see the replies both over Tunnel and post decryption. But for inexplicable reason, its only when I try with web traffic that I notice that the traffic is not reaching the intended application. Any clue. My Ipsec config isn't anything interesting vtewari@vtewari-ububtu:~$ sudo swanctl --list-sas [sudo] password for vtewari: tenant-13543-1010: #9, ESTABLISHED, IKEv2, 43319062223514a3_i* 2927ffc3801b0fa2_r local 'vtewari-bom2@vtewari.com' @ 10.0.2.15 remote 'vtewari-remote' @ vtewari-remote AES_CBC-128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048 established 2622s ago, reauth in 24647s tenant-13543-1010: #13, reqid 11, INSTALLED, TUNNEL-in-UDP, ESP:AES_CBC-256/HMAC_SHA1_96 installed 2623s ago, rekeying in 68598s, expires in 69378s in c6fce0ab, 600 bytes, 7 packets, 381s ago out c13ce846, 127082 bytes, 96 packets, 381s ago local 0.0.0.0/0 remote 0.0.0.0/0 vtewari@vtewari-ububtu:~$ sudo swanctl --list-conns tenant-13543-1010: IKEv2, reauthentication every 215460s, no rekeying local: %any remote: vtewari-remote local pre-shared key authentication: id: vtewari-bom2@vtewari.com remote pre-shared key authentication: tenant-13543-1010: TUNNEL, rekeying every 71460s local: 0.0.0.0/0 remote: 0.0.0.0/0 Ping/Iperf successful test over tunnel vtewari@vtewari-ububtu:~$ iperf3 -c paris.testdebit.info -p 9237 -R Connecting to host paris.testdebit.info, port 9237 Reverse mode, remote host paris.testdebit.info is sending [ 5] local 10.0.2.15 port 33296 connected to 89.84.1.194 port 9237 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 37.1 KBytes 304 Kbits/sec [ 5] 1.00-2.00 sec 102 KBytes 830 Kbits/sec ^C[ 5] 2.00-2.54 sec 131 KBytes 2.01 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate [ 5] 0.00-2.54 sec 0.00 Bytes 0.00 bits/sec sender [ 5] 0.00-2.54 sec 270 KBytes 871 Kbits/sec receiver iperf3: interrupt - the client has terminated However though TCP gets connected, wget never sees the response vtewari@vtewari-ububtu:~$ wget http://google.com --verbose -O index.html --2022-06-05 15:10:00-- http://google.com/ Resolving google.com (google.com)... 142.250.77.46, 2404:6800:4009:81c::200e Connecting to google.com (google.com)|142.250.77.46|:80... connected. HTTP request sent, awaiting response... 301 Moved Permanently Location: http://www.google.com/ [following] --2022-06-05 15:10:01-- http://www.google.com/ Resolving www.google.com (www.google.com)... 142.251.42.4, 2404:6800:4009:82f::2004 Connecting to www.google.com (www.google.com)|142.251.42.4|:80... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [text/html] Saving to: ‘index.html’ index.html [ ] 0 --.-KB/s I see the same with browser as well. If I disable tunnel, everything is fine. When I enable the tunnel, browser fails to reach servers. Thank you for your insights into this.

I'm having problems with my client-to-server config. I only edited this file /etc/ipsec.conf I can only edit this file on Client side, but not server side. On server I have an interface program where I can create certs and other stuff.

config setup
        charondebug="all"
        uniqueids=yes
conn devgateway-to-prodgateway
        type=tunnel
        auto=start
        keyexchange=ikev2
        authby=rsasig
        left=externalIP-A
        leftsubnet=InternalIP-A/24
        leftcert=myServerPem.pem
        right=ExternalIP-B
        rightsubnet=InternalIP-B/24
        rightcert=myServerPem.pem (downloaded this cert, created by my server)
        ike=aes256-sha1-modp1024!
        esp=aes256-sha1-modp1024!
        aggressive=no
        keyingtries=%forever
        ikelifetime=36000s
        lifetime=10800s
        dpddelay=30s
        dpdtimeout=120s
        dpdaction=restart

I can ping from my A client to B server IP, but when using

status

I receive the next message:

Security Associations (0 up, 1 connecting):
devgateway-to-prodgateway: CONNECTING, ExternalIp-A[%any]...ExternalIp-B[%any]

So it's not properly working as desired. Any suggestions?

So I am using Strongswan to connect to remote Fortigate since native Fortinet VPN client does not support IPsec. I also have hardware FortiToken 200 that provides a OTP. My current config is the following: **/etc/ipsec.conf** conn my-config keyexchange=ikev1 aggressive=yes ike = aes256-sha256-modp1536 esp = aes256-sha1-modp1536 right=remote_ip rightid=%any rightsubnet=0.0.0.0/0 rightauth=psk leftsourceip=%config leftauth=psk leftauth2=xauth xauth_identity="username" auto=add **/etc/ipsec.secrets** remote_ip : PSK "passphrase_here" username : XAUTH "password_here" When I run: > ipsec up my-config initiating Aggressive Mode IKE_SA german to remote_ip generating AGGRESSIVE request 0 [ SA KE No ID V V V V V ] sending packet: from 10.0.2.15 to remote_ip (460 bytes) received packet: from remote_ip to 10.0.2.15 (536 bytes) parsed AGGRESSIVE response 0 [ SA KE No ID HASH V NAT-D NAT-D V V V V V ] received NAT-T (RFC 3947) vendor ID received DPD vendor ID received XAuth vendor ID received unknown vendor ID: 82:99:03:17:57:a3:60:82:c6:a6:21:de:00:00:00:00 received FRAGMENTATION vendor ID received FRAGMENTATION vendor ID selected proposal: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1536 local host is behind NAT, sending keep alives generating AGGRESSIVE request 0 [ HASH NAT-D NAT-D ] sending packet: from 10.0.2.15 to remote_ip (140 bytes) received packet: from remote_ip to 10.0.2.15 (92 bytes) parsed TRANSACTION request 1581697690 [ HASH CPRQ(X_TYPE X_USER X_PWD) ] no XAuth method found generating TRANSACTION response 1581697690 [ HASH CP ] sending packet: from 10.0.2.15 to remote_ip (76 bytes) Obviously, it is necessary to edit the config somehow so it would prompt for OTP at some point. ***The question is: how do I it?***

We have successfully set up a strongswan vpn on our network to communicate with Google Cloud VPN. Sometimes we leave it idle for a while, let's say a night, that's when the issue appear. If I try to ping from Google to our network, it doesn't work, no packets are transmitted. If I try to ping from our side to Google, it works, and then the ping which was blocked on Google side starts working fine. It looks like StrongSwan enters in sleep mode on our side and wakes up only when I manually ping out, not when receiving packets. But I can't find any option in the doc to fix this, has anyone got this issue and fixed it somehow? EDIT: there is no firewall on our side which could explain this behaviour and on google side we can only set the IP range allowed to go through the firewall, nothing else. But since it uses their own VPN service to communicate with our strongswan server, I strongly doubt it comes from them. Here is what ipsec status returns before the issue on our side: net-net: ESTABLISHED 113 minutes ago, 79.xxx.xxx.xxx[79.xxx.xxx.xxx]...146.xxx.xxx.xxx[146.xxx.xxx.xxx] net-net{255}: INSTALLED, TUNNEL, reqid 24, ESP SPIs: c5xxxxxx 4exxxxxx net-net{255}: 192.168.0.0/24 192.168.17.0/24 === 10.132.0.0/20 Here is what ipsec statusall returns after: Status of IKE charon daemon (strongSwan 5.3.5, Linux 4.4.0-64-generic, x86_64): uptime: 22 days, since Feb 27 15:21:33 2017 malloc: sbrk 2568192, mmap 0, used 370288, free 2197904 worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 11 loaded plugins: charon aes agent attr connmark constraints dnskey fips-prf gcm md4 openssl pem pgp pkcs1 pkcs12 pkcs7 pkcs8 pubkey rc2 resolve revocation sshkey test-vectors x509 xcbc sha1 sha2 md5 gmp random nonce hmac stroke kernel-netlink socket-default updown Listening IP addresses: 192.168.17.205 79.xxx.xxx.xxx Connections: net-net: 79.xxx.xxx.xxx...146.xxx.xxx.xxx IKEv2, dpddelay=30s net-net: local: [79.xxx.xxx.xxx] uses pre-shared key authentication net-net: remote: [146.xxx.xxx.xxx] uses pre-shared key authentication net-net: child: 192.168.17.0/24 192.168.0.0/24 === 10.132.0.0/20 TUNNEL, dpdaction=restart Security Associations (1 up, 0 connecting): net-net: ESTABLISHED 2 hours ago, 79.xxx.xxx.xxx[79.xxx.xxx.xxx]...146.xxx.xxx.xxx[146.xxx.xxx.xxx] net-net: IKEv2 SPIs: 0fd4efxxxxxx 17ed000axxxxxx*, pre-shared key reauthentication in 108 minutes net-net: IKE proposal: AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048 net-net{255}: INSTALLED, TUNNEL, reqid 24, ESP SPIs: c5b822fe_i 4ed83bd8_o net-net{255}: AES_GCM_16_128, 3916 bytes_i (47 pkts, 1020s ago), 3956 bytes_o (47 pkts, 1020s ago), rekeying in 7 hours net-net{255}: 192.168.0.0/24 192.168.17.0/24 === 10.132.0.0/20 And the ipsec.conf: config setup conn %default ikelifetime=24h keylife=8h rekeymargin=9m keyingtries=1 authby=psk keyexchange=ikev2 mobike=no esp=aes128gcm16-modp2048! dpdaction=restart conn net-net left=79.xxx.xxx.xxx leftsubnet=192.168.17.0/24,192.168.0.0/24 leftid=79.xxx.xxx.xxx leftfirewall=yes leftdns=xxx.... right=146.xxx.xxx.xxx rightsubnet=10.132.0.0/20 rightid=146.xxx.xxx.xxx auto=start And on the logs from the google side I noticed that at the moment I send the ping test, it sends some requests to recreate CHILD_SA: "creating rekey job for CHILD_SA ESP/0xxxxxxxxx/79.xxx.xxx.xxx" ... Once the CHILD_SA is established with its SPI the ping goes through. Though the ESP SPI didn't change before and after. I also see rekeying in 7 hours on ipsec statusall. Could it be the issue that during the night there is no activity during more than 7 hours? Here is charon log: Mar 22 07:56:43 vpn07 charon: 11[ENC] parsed CREATE_CHILD_SA request 223 [ N(REKEY_SA) SA No KE TSi TSr ] Mar 22 07:56:43 vpn07 charon: 11[IKE] CHILD_SA net-net{255} established with SPIs c5b8xxxxxxx_o and TS 192.168.0.0/24 192.168.17.0/24 === 10.132.0.0/20 Mar 22 07:56:43 vpn07 charon: 11[ENC] generating CREATE_CHILD_SA response 223 [ SA No KE TSi TSr ] Mar 22 07:56:43 vpn07 charon: 05[IKE] received DELETE for ESP CHILD_SA with SPI 7dd6xxxx Mar 22 07:56:43 vpn07 charon: 05[IKE] closing CHILD_SA net-net{254} with SPIs ce7xxxx (95264 bytes) 7ddxxxxx (4885433 bytes) and TS 192.168.0.0/24 192.168.17.0/24 === 10.132.0.0/20 Mar 22 07:56:43 vpn07 charon: 05[IKE] sending DELETE for ESP CHILD_SA with SPI ce75xxxxx Mar 22 07:56:43 vpn07 charon: 05[IKE] CHILD_SA closed And google logs: D sending DPD request D CHILD_SA closed D received DELETE for ESP CHILD_SA with SPI cexxxxx D parsed INFORMATIONAL response 224 [ D ] D received packet: from 79.xxx.xxx.xxx to 146.xxx.xxx.xxx (76 bytes) D sending packet: from 146.xxx.xxx.xxx to 79.xxx.xxx.xxx (76 bytes) D generating INFORMATIONAL request 224 [ D ] D sending DELETE for ESP CHILD_SA with SPI 7dxxxxxx I closing CHILD_SA vpn_79.xxx.xxx.xxx{33} with SPIs 7dxxxxx (5073648 bytes) cexxxxxx (95264 bytes) and TS 10.132.0.0/20 === 192.168.0.0/24 192.168.17.0/24 I CHILD_SA vpn_79.xxx.xxx.xxx{34} established with SPIs 4exxxxxx c5xxxxxx and TS 10.132.0.0/20 === 192.168.0.0/24 192.168.17.0/24 D handling HA CHILD_SA vpn_79.xxx.xxx.xxx{34} 10.132.0.0/20 === 192.168.0.0/24 192.168.17.0/24 (segment in: 1*, out: 1*) D parsed CREATE_CHILD_SA response 223 [ SA No KE TSi TSr ] D received packet: from 79.xxx.xxx.xxx to 146.xxx.xxx.xxx (476 bytes) D sending packet: from 146.xxx.xxx.xxx to 79.xxx.xxx.xxx (620 bytes) D generating CREATE_CHILD_SA request 223 [ N(REKEY_SA) SA No KE TSi TSr ] I establishing CHILD_SA vpn_79.xxx.xxx.xxx{1} D creating rekey job for CHILD_SA ESP/0xxxxxxx/79.xxx.xxx.xxx D parsed INFORMATIONAL response 222 [ ] D received packet: from 79.xxx.xxx.xxx to 146.xxx.xxx.xxx (76 bytes) D sending packet: from 146.xxx.xxx.xxx to 79.xxx.xxx.xxx (76 bytes) D generating INFORMATIONAL request 222 [ ] D sending DPD request