Sample Header Ad - 728x90

Unix & Linux Stack Exchange

Q&A for users of Linux, FreeBSD and other Unix-like operating systems

Latest Questions

2 votes
2 answers
2017 views
L2TP over IPSec on Debian 10
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...
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.
Richard Barraclough (550 rep)
Nov 10, 2020, 05:37 PM • Last activity: Jul 2, 2025, 12:03 PM
4 votes
1 answers
3077 views
Routing traffic through VPN using Raspberry PI
I have a setup like this: - Raspberry Pi connected to router via LAN cable - Created a bridged connection between eth0 and wlan0 - Using `hostapd` for Wi-Fi hotstop - Configured l2tp/ipsec connection with one of my servers online An Issue I am having & goal: - Goal is to have this Raspberry Pi as a...
I have a setup like this: - Raspberry Pi connected to router via LAN cable - Created a bridged connection between eth0 and wlan0 - Using hostapd for Wi-Fi hotstop - Configured l2tp/ipsec connection with one of my servers online An Issue I am having & goal: - Goal is to have this Raspberry Pi as a Wi-Fi router that would route all traffic coming via Wi-Fi through my VPN - **Issue I am having** is that Raspberry Pi is using the VPN tunnel when I do curl, but all Wi-Fi guests connected do not get the VPN IP. Interface example: 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: mtu 1500 qdisc pfifo_fast master br0 state UP group default qlen 1000 link/ether b8:27:eb:21:2b:9a brd ff:ff:ff:ff:ff:ff 3: br0: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether b8:27:eb:21:2b:9a brd ff:ff:ff:ff:ff:ff inet 192.168.1.7/24 brd 192.168.1.255 scope global br0 valid_lft forever preferred_lft forever inet6 fe80::ba27:ebff:fe21:2b9a/64 scope link valid_lft forever preferred_lft forever 4: wlan0: mtu 1500 qdisc pfifo_fast master br0 state UP group default qlen 1000 link/ether b8:27:eb:74:7e:cf brd ff:ff:ff:ff:ff:ff 6: ppp0: mtu 1280 qdisc pfifo_fast state UNKNOWN group default qlen 3 link/ppp inet 192.168.42.11 peer 192.168.42.1/32 scope global ppp0 valid_lft forever preferred_lft forever Routing table: Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 ppp0 0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 br0 45.36.81.212 192.168.1.1 255.255.255.255 UGH 0 0 0 br0 63.126.53.74 192.168.1.1 255.255.255.255 UGH 0 0 0 br0 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 br0 192.168.42.1 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0 45.36.81.212 is my VPN 63.126.53.74 is my own local public IP (ips have been slightly changed for obvious reasons). OS: Raspbian Would forwarding wlan0 to ppp0 do the trick, or do I need to tamper with br0?
py9 (141 rep)
Nov 8, 2018, 12:43 AM • Last activity: Jun 26, 2025, 09:07 AM
1 votes
1 answers
35 views
Traffic not passed to the local TCP/IP stack for ipsec tun made with ip xfrm over netns
I have a simple netns setup ``` ip netns del ns1 ip netns del ns2 ip netns add ns1 ip netns add ns2 ip link add veth1 type veth peer name veth2 ip link set veth1 netns ns1 ip link set veth2 netns ns2 ip netns exec ns1 ip addr add 10.1.1.1/24 dev veth1 ip netns exec ns2 ip addr add 10.1.1.2/24 dev ve...
I have a simple netns setup
ip netns del ns1
ip netns del ns2

ip netns add ns1
ip netns add ns2

ip link add veth1 type veth peer name veth2
ip link set veth1 netns ns1
ip link set veth2 netns ns2

ip netns exec ns1 ip addr add 10.1.1.1/24 dev veth1
ip netns exec ns2 ip addr add 10.1.1.2/24 dev veth2

ip netns exec ns1 ip addr add 10.1.2.1/24 dev veth1
ip netns exec ns2 ip addr add 10.1.2.2/24 dev veth2

ip netns exec ns1 ip link set veth1 up
ip netns exec ns2 ip link set veth2 up

ip netns exec ns1 ip link set lo up
ip netns exec ns2 ip link set lo up
I need to send ICMP requests/replies over an IPsec tunnel I create with netlink socket apis (or equivalently ip xfrm):
ns2                             || ns1
                                ||
             10.1.2.2 TUN end   || 10.1.2.1 TUN end     
              |                 ||  |
10.1.1.2 ---> |=====================|----ICMP echo req----> 10.1.1.1
                                ||
                                ||
10.1.1.2  sudo ip netns exec ns1 tcpdump -nli veth1
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on veth1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
17:23:53.374316 IP 10.1.2.2 > 10.1.2.1: ESP(spi=0x00000001,seq=0x11), length 132
17:23:53.374316 IP 10.1.1.2 > 10.1.1.1: ICMP echo request, id 52684, seq 1, length 64
Unfortunately I can't see the ICMP echo reply, no matter what I do. I've also made the same attempts over TCP with netcat: again I see the incoming decoded "syn" packet, but this is not propagated locally to the application listening socket whatsoever. Can you help me figure what might be going wrong? I've checked all the forwarding flags in proc in either of the two net namespaces and the default one; everything seems ok so far. EDIT: I with the command sudo ip netns exec ns1 ip xfrm monitor, for every packet sent I see the following:
Async event  (0x20)  timer expired 
	src 10.1.2.2 dst 10.1.2.1  reqid 0x1 protocol esp  SPI 0x1
The xfrm_lifetime_cfg is configured like follows for both policy and sa:
pol->lft.soft_byte_limit = XFRM_INF;
    pol->lft.hard_byte_limit = XFRM_INF;
    pol->lft.soft_packet_limit = XFRM_INF;
    pol->lft.hard_packet_limit = XFRM_INF;
    pol->lft.soft_add_expires_seconds = 0;
    pol->lft.hard_add_expires_seconds = 0;
    pol->lft.soft_use_expires_seconds = 0;
    pol->lft.hard_use_expires_seconds = 0;
    
    sa->lft.soft_byte_limit = XFRM_INF;
    sa->lft.hard_byte_limit = XFRM_INF;
    sa->lft.soft_packet_limit = XFRM_INF;
    sa->lft.hard_packet_limit = XFRM_INF;
    sa->lft.soft_add_expires_seconds = 0;
    sa->lft.hard_add_expires_seconds = 0;
    sa->lft.soft_use_expires_seconds = 0;
    sa->lft.hard_use_expires_seconds = 0;
EDIT2: After trial and error, I managed to make it work by installing the policy with
sudo ip netns exec ns1 ip xfrm policy add dir in     src 10.1.1.2/32 dst 10.1.1.1/32     tmpl src 10.1.2.2 dst 10.1.2.1 proto esp mode tunnel reqid 1
The fun fact is that the resulting policy is IDENTICAL:
src 10.1.1.2/32 dst 10.1.1.1/32
        dir in priority 0 flag icmp
        tmpl src 10.1.2.2 dst 10.1.2.1
                proto esp reqid 1 mode tunnel
Riccardo Manfrin (111 rep)
Jun 16, 2025, 09:36 AM • Last activity: Jun 23, 2025, 08:34 PM
2 votes
2 answers
3109 views
Restart specific racoon tunnel
I have several **gif*** interfaces on my FreeBSD box. They are representing tunnels, encrypted using `racoon`+`ipsec`. If, at some moment, one of the tunnels hangs up, I am forced to reset `racoon` this way: /usr/local/etc/rc.d/racoon restart But in that case all tunnels are reset, which leads to a...
I have several **gif*** interfaces on my FreeBSD box. They are representing tunnels, encrypted using racoon+ipsec. If, at some moment, one of the tunnels hangs up, I am forced to reset racoon this way: /usr/local/etc/rc.d/racoon restart But in that case all tunnels are reset, which leads to a short absence of connectivity on all my tunnels (3-5 seconds, but nevertheless). Is there any method to reset one specific gif tunnel, while not touching any other tunnels?
Alexander Tarasov (121 rep)
Sep 14, 2014, 12:53 PM • Last activity: May 24, 2025, 10:06 PM
0 votes
1 answers
28 views
Run a VPN server alongside a website served by Docker
I have a server running this [CMS](https://github.com/mediacms-io/mediacms) as a website by running a Docker file like [this](https://github.com/mediacms-io/mediacms/blob/main/docker-compose-letsencrypt.yaml) by `docker-compose` which internally uses `nginxproxy/nginx-proxy` and `nginxproxy/acme-com...
I have a server running this [CMS](https://github.com/mediacms-io/mediacms) as a website by running a Docker file like [this](https://github.com/mediacms-io/mediacms/blob/main/docker-compose-letsencrypt.yaml) by docker-compose which internally uses nginxproxy/nginx-proxy and nginxproxy/acme-companion Docker images. Now, I intend to follow the instructions given [here](https://www.euro-space.net/blog/virtual-server-for-vpn/tutorial/how-to-setup-ikev2-vpn-using-strongswan-and-letsencrypt-on-centos-8.php) to set up a VPN on the same server which uses Let's Encrypt. # Question Can I run the VPN alongside the previous CMS? Would I run into any trouble?
Megidd (1579 rep)
Oct 21, 2024, 10:10 AM • Last activity: May 14, 2025, 02:00 PM
0 votes
0 answers
67 views
StrongSwan says certificate not found but loads it when it boots up
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 au...
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
Ermal Ferati (1 rep)
Apr 13, 2025, 01:01 AM • Last activity: Apr 13, 2025, 01:07 AM
5 votes
1 answers
2327 views
How to fix this eth0 and eth1, where traffic going out via eth0 is failing?
I have two public IPs. One's connected to eth0 and one to eth1, from 2 separate routers as complete DMZ towards the LAN IP. I added this following: ip rule add from 10.0.0.108/32 table 1 # outbound ip rule add to 10.0.0.108/32 table 1 # inbound ip route add default via 10.0.0.1 dev eth0 table 1 ip r...
I have two public IPs. One's connected to eth0 and one to eth1, from 2 separate routers as complete DMZ towards the LAN IP. I added this following: ip rule add from 10.0.0.108/32 table 1 # outbound ip rule add to 10.0.0.108/32 table 1 # inbound ip route add default via 10.0.0.1 dev eth0 table 1 ip rule add from 10.0.0.100/32 table 2 # outbound ip rule add to 10.0.0.100/32 table 2 # inbound ip route add default via 10.0.0.1 dev eth1 table 2 Since adding this above, I've been having problems sending traffic correctly for inbound and outbound. For example: $ ping -I eth0 8.8.8.8 PING 8.8.8.8 (8.8.8.8) from 10.0.0.108 eth0: 56(84) bytes of data. From 10.0.0.108 icmp_seq=2 Destination Host Unreachable From 10.0.0.108 icmp_seq=3 Destination Host Unreachable From 10.0.0.108 icmp_seq=4 Destination Host Unreachable $ ping -I eth1 8.8.8.8 PING 8.8.8.8 (8.8.8.8) from 10.0.0.28 eth1: 56(84) bytes of data. 64 bytes from 8.8.8.8: icmp_seq=1 ttl=48 time=14.6 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=48 time=14.6 ms ^C --- 8.8.8.8 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1233ms rtt min/avg/max/mdev = 14.611/14.639/14.667/0.028 ms How do I use ip rule add from/to method to fix the eth0 (from/to), but without breaking the eth1 (eth1 is working perfect).
user11085
Jul 31, 2013, 10:33 AM • Last activity: Apr 11, 2025, 01:06 PM
0 votes
0 answers
51 views
unable to connect to the remote server via StrongSwan IPSec. Linux Debian 12
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 i...
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"
Max (1 rep)
Mar 29, 2025, 04:56 PM • Last activity: Mar 29, 2025, 05:06 PM
0 votes
0 answers
772 views
Debian 11: setting up L2TP + IPSec - IPSec fails?
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...
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.
j4nd3r53n (779 rep)
Jun 8, 2023, 01:26 PM • Last activity: Mar 18, 2025, 11:33 AM
0 votes
0 answers
37 views
Ipsec vpn connected but cant ping the other router
I have two OpenWRT routers set up with an IPSec VPN tunnel between them. The tunnel is successfully established, but the traffic is not passing through the tunnel, and I'm unable to ping local devices on the other side. Here is my network setup: OpenWRT Router (Youssef) -> Router with DMZ -> Interne...
I have two OpenWRT routers set up with an IPSec VPN tunnel between them. The tunnel is successfully established, but the traffic is not passing through the tunnel, and I'm unable to ping local devices on the other side. Here is my network setup: OpenWRT Router (Youssef) -> Router with DMZ -> Internet -> OpenWRT Router (Martin) Router Configurations Youssef's Router - Route Config:
root@turris:/etc/swanctl/conf.d# ip route show
default via 192.168.1.1 dev eth2 
10.10.90.0/24 via 10.0.0.1 dev vti1 
192.168.1.0/24 dev eth2 proto kernel scope link src 192.168.1.26 
192.168.2.0/24 dev br-lan proto kernel scope link src 192.168.2.1
Martin's Router - Route Config:
root@turris:/etc/swanctl/conf.d# ip route show
default via 62.155.x.y dev pppoe-wan proto static 
62.155.x.y dev pppoe-wan proto kernel scope link src 80.133.x.y 
192.168.1.0/24 dev br-lan proto kernel scope link src 192.168.1.1
IPSec Configuration (Youssef's Router) connections { martinyoussef { version = 2 local_addrs = %any remote_addrs = X.X.X.X local { id = @youssef auth = psk } remote { id = @Martin auth = psk } children { net { local_ts = 192.168.2.0/24 remote_ts = 192.168.1.0/24 start_action = start mode = tunnel } } proposals = aes256gcm16-sha512-modp4096 } } secrets { ike-martinyoussef { secret = "secrekey" } } IPSec Configuration (Martin's Router) connections { martinyoussef { version = 2 local_addrs = %any remote_addrs = X.X.X.X local { id = @Martin auth = psk } remote { id = @youssef auth = psk } children { net { local_ts = 192.168.1.0/24 remote_ts = 192.168.2.0/24 start_action = start mode = tunnel } } proposals = aes256gcm16-sha512-modp4096 } } secrets { ike-martinyoussef { secret = "secrekey" } } Problem: The VPN IPSec tunnel is successfully established between the two routers, but traffic is not passing through the tunnel, and I cannot ping devices on the remote side.
Youssef ARRASSEN (1 rep)
Mar 6, 2025, 07:37 AM • Last activity: Mar 6, 2025, 08:49 AM
0 votes
0 answers
142 views
What are the correct iptables rules for an ipsec site to site?
I am trying to configure an IPSEC site to site using strongswan on Debian 12. The VPN is UP, as shown below Status of IKE charon daemon (strongSwan 5.9.8, Linux 6.1.0-30-cloud-amd64, x86_64): uptime: 18 hours, since Jan 22 14:58:17 2025 malloc: sbrk 2125824, mmap 0, used 1366096, free 759728 worker...
I am trying to configure an IPSEC site to site using strongswan on Debian 12. The VPN is UP, as shown below Status of IKE charon daemon (strongSwan 5.9.8, Linux 6.1.0-30-cloud-amd64, x86_64): uptime: 18 hours, since Jan 22 14:58:17 2025 malloc: sbrk 2125824, mmap 0, used 1366096, free 759728 worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 5 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 forecast farp stroke 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 addrblock unity counters Listening IP addresses: Connections: server: ... IKEv2, dpddelay=30s server: local: [] uses pre-shared key authentication server: remote: [] uses pre-shared key authentication server: child: === TUNNEL, dpdaction=start Security Associations (1 up, 0 connecting): server: ESTABLISHED 2 hours ago, []...[] server: IKEv2 SPIs: , pre-shared key reauthentication in 4 hours server: IKE proposal: AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048 server{27}: INSTALLED, TUNNEL, reqid 1, ESP SPIs: server{27}: AES_CBC_128/HMAC_SHA2_256_128, 0 bytes_i, 0 bytes_o, rekeying in 42 minutes server{27}: === But I believe I am having issues configuring the correct IPTables rules. I tried following the recommendations shown here , as well as the steps from multiple tutorials (I reached page 2 of google). I have route to the client VPN range dev vti0 scope link The interface is UP 4: vti0@NONE: mtu 1480 qdisc noqueue state UNKNOWN group default qlen 1000 link/ipip peer inet6 /64 scope link valid_lft forever preferred_lft forever What I noticed is: when I configure an snat to translate the VPN traffic going out my vti interface, the traffic does not reach the interface, as the TCPDump cannot capture anything. Any other rule (or no rule at all), I get traffic in the TCPDump tcpdump -i vti0 -n tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on vti0, link-type RAW (Raw IP), snapshot length 262144 bytes 13:41:14.939880 IP .43140 > .22: Flags [S], seq 3230932500, win 64800, options [mss 1440,sackOK,TS val 2922516277 ecr 0,nop,wscale 7], length 0 13:41:15.942056 IP .43140 > .22: Flags [S], seq 3230932500, win 64800, options [mss 1440,sackOK,TS val 2922517280 ecr 0,nop,wscale 7], length 0 But get the errors "No route to host" when trying to access a server that I know is available on the other site. I understand that the issue with "no route to host" **could be** that the IP of my outbound traffic is using my internal IP and not one on my VPN range, but as I explained before, once I apply SNAT, the traffic stops and I get a timeout in the connection. A few of the rules I tried applying (not all at the same time, of course) iptables -A FORWARD -i eth0 -o vti0 -j ACCEPT iptables -A FORWARD -i vti0 -o eth0 -j ACCEPT iptables -t nat -A POSTROUTING -o eth0 -d -j SNAT --to-source iptables -t nat -A POSTROUTING -o vti0 -j MASQUERADE iptables -t nat -A POSTROUTING -o eth0 -s -j SNAT --to-source iptables -t nat -A POSTROUTING -o vti0 -d -j SNAT --to-source iptables -t nat -A POSTROUTING -o vti0 -d 0.0.0.0/0 -j SNAT --to-source iptables -t nat -A POSTROUTING -s -d -J MASQUERADE iptables -t nat -I POSTROUTING -m policy --pol ipsec --dir out -j ACCEPT iptables -t nat -A POSTROUTING -o vti0 -m policy --dir out --pol ipsec -j ACCEPT iptables -t mangle -A FORWARD -m policy --pol ipsec --dir in -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1361:1536 -j TCPMSS --set-mss 1360 iptables -t mangle -A FORWARD -m policy --pol ipsec --dir out -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1361:1536 -j TCPMSS --set-mss 1360 iptables -t nat -A POSTROUTING -o vti0 -d -j SNAT --to-source iptables -t nat -A POSTROUTING -o eth0 -d -j SNAT --to-source iptables -t nat -A POSTROUTING -s -o vti0 -m policy --dir out --pol ipsec -j ACCEPT iptables -t nat -A POSTROUTING -s -o vti0 -j MASQUERADE iptables -t nat -A POSTROUTING -o vti0 -j SNAT --to-source iptables -t nat -A POSTROUTING -o vti0 -j SNAT --to-source iptables -t nat -A POSTROUTING -s -o vti0 -m policy --dir out --pol ipsec -j ACCEPT iptables -t nat -A POSTROUTING -s -o eth0 -j MASQUERADE iptables -t nat -A POSTROUTING -o vti0 -j SNAT --to-source iptables -t nat -A POSTROUTING -d -j ACCEPT iptables -t mangle -A OUTPUT -d -j MARK --set-mark 1 iptables -t nat -A POSTROUTING -m mark --mark 1 -j SNAT --to-source iptables -t nat -A POSTROUTING -o vti0 -s -d -j SNAT --to-source iptables -t nat -A POSTROUTING -o vti0 -s -d -j SNAT --to-source I don't know whether is relevant, but my server is in Azure, with IP forwarding enabled both in Azure and in Debian. There's no outbound rules in Azure.
Tammy (1 rep)
Jan 23, 2025, 09:58 AM • Last activity: Jan 23, 2025, 02:10 PM
0 votes
1 answers
15 views
How to know Solaris ipsec keys for ike in pkcs12 format?
I want to convert Solaris ipsec ike keys in a format suitable for Libreswan. With the command ikecert I export the public key ikecert certdb -e 0 > public.pem and private key ikecert certlocal -e 0 > public.pem Now with openssl I try to convert in pkcs12 format and.. openssl pkcs12 -export -in chiav...
I want to convert Solaris ipsec ike keys in a format suitable for Libreswan. With the command ikecert I export the public key ikecert certdb -e 0 > public.pem and private key ikecert certlocal -e 0 > public.pem Now with openssl I try to convert in pkcs12 format and.. openssl pkcs12 -export -in chiavepubblica.pem -inkey chiaveprivata.pem -out YourName.p12 return this error 4274747236:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:707:Expecting: ANY PRIVATE KEY someone know a way to export it or convert in suitable format for libreswan? Thanks
elbarna (13690 rep)
Dec 30, 2024, 07:20 PM • Last activity: Dec 31, 2024, 07:18 AM
0 votes
1 answers
201 views
Ipsec tunnel with solaris10..what I miss?
I want to create a two Solaris10 tunnel encrypted with ipsec.Configuration is simple: 2 solaris10 nodes,lan not encrypted,tunnel encrypted. Lan is e1000g0 and tunnel is ip.tun0 Ip "clear" for node1 is 192.168.0.21 Ip "clear" for node2 is 192.168.0.199 I do this procedure a)Enabled ipv4 forwaring and...
I want to create a two Solaris10 tunnel encrypted with ipsec.Configuration is simple: 2 solaris10 nodes,lan not encrypted,tunnel encrypted. Lan is e1000g0 and tunnel is ip.tun0 Ip "clear" for node1 is 192.168.0.21 Ip "clear" for node2 is 192.168.0.199 I do this procedure a)Enabled ipv4 forwaring and routing in both nodes routeadm -u -e ipv4-routing routeadm -u -e ipv4-forwarding b)Edited /etc/inet/ike/config on both nodes p1_xform { auth_method preshared oakley_group 5 auth_alg sha encr_alg 3des } p2_pfs 2 c)Edited /etc/inet/secret/ike.preshared on both nodes,of course with reverse local/remote { localidtype IP localid 192.168.0.21 remoteidtype IP remoteid 192.168.0.119 } d)Enable IKE on both nodes,svcs confirm is working svcadm enable ike svcs ike e)Edit file /etc/inet/ipsecinit.conf # LAN traffic to and from this host can bypass IPsec. {laddr 192.168.0.0 dir both} bypass {} # WAN traffic uses ESP with AES and SHA-1. {tunnel ip.tun0 negotiate tunnel} ipsec {encr_algs aes encr_auth_algs sha1 sa shared} f)Refresh.. svcadm refresh ipsec/policy g)Seems all ok,so I create the tunnel svcs -a|grep -i ipsec disabled 9:35:34 svc:/network/ipsec/manual-key:default online 9:35:53 svc:/network/ipsec/ipsecalgs:default online 9:35:53 svc:/network/ipsec/ike:default online 9:54:38 svc:/network/ipsec/policy:default On HostA ifconfig ip.tun0 plumb ifconfig ip.tun0 192.168.192.24 192.168.192.40 tsrc 192.168.0.21 tdst 192.168.0.199 router up On HostB ifconfig ip.tun0 plumb ifconfig ip.tun0 192.168.192.40 192.168.192.24 tsrc 192.168.0.199 tdst 192.168.0.21 router up Seems all OK but..don't work. HostA can ping HostB ping 192.168.0.199 192.168.0.199 is alive HostB can ping HostA ping 192.168.0.2 192.168.0.2 is alive But If I ping the tunnel... From HostA to HostB ping -s 192.168.192.40 PING 192.168.192.40: 56 data bytes ----192.168.192.40 PING Statistics---- 25 packets transmitted, 0 packets received, 100% packet loss From HostB to HostA ping -s 192.168.192.24 PING 192.168.192.24: 56 data bytes ----192.168.192.24 PING Statistics---- 25 packets transmitted, 0 packets received, 100% packet loss on hostA netstat -rn said netstat -rn Routing Table: IPv4 Destination Gateway Flags Ref Use Interface -------------------- -------------------- ----- ----- ---------- --------- default 192.168.0.1 UG 1 1 192.168.0.0 192.168.0.21 U 1 3 e1000g0 192.168.192.40 192.168.192.24 UH 1 0 ip.tun0 224.0.0.0 192.168.0.21 U 1 0 e1000g0 127.0.0.1 127.0.0.1 UH 1 48 lo0 On HostB netstat -rn said Routing Table: IPv4 Destination Gateway Flags Ref Use Interface -------------------- -------------------- ----- ----- ---------- --------- default 192.168.0.1 UG 1 2 e1000g0 192.168.0.0 192.168.0.199 U 1 7 e1000g0 192.168.192.24 192.168.192.40 UH 1 1 ip.tun0 127.0.0.1 127.0.0.1 UH 3 122 lo0 What I miss?Firewall is disabled on both nodes.
elbarna (13690 rep)
Feb 17, 2019, 09:04 AM • Last activity: Dec 25, 2024, 10:43 AM
0 votes
0 answers
335 views
Help with IKEv2 VPN Connection Error: NO_PROPOSAL_CHOSEN
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...
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!
EM Farih (1 rep)
Oct 13, 2024, 11:02 AM
0 votes
0 answers
55 views
Strongswan - Communication doesn't work between hosts
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 ![strongswan1 drawio](https://github.com/s...
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 ![strongswan1 drawio](https://github.com/strongswan/strongswan/assets/3245485/9fcd2cf1-d1d7-4310-9ecc-3c795e9d71f1) **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
André Bolinhas (21 rep)
Jun 17, 2024, 03:44 PM • Last activity: Jun 17, 2024, 11:40 PM
3 votes
1 answers
556 views
What's the "new" way of checking the established connections in strongswan
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...
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?
zerkms (839 rep)
Apr 16, 2024, 09:55 PM • Last activity: Apr 17, 2024, 10:20 AM
0 votes
1 answers
872 views
Connect IPSEC VPN to network interface
I have a StrongSwan IPSEC VPN configured on my Ubuntu 22.04.4 LTS server. The VPN starts up and connects to the primary interface (eno1) successfully. Using qBittorrent, I bind to the IP Address that is assigned to the VPN connection so that torrent traffic is directed through the VPN. (I don't send...
I have a StrongSwan IPSEC VPN configured on my Ubuntu 22.04.4 LTS server. The VPN starts up and connects to the primary interface (eno1) successfully. Using qBittorrent, I bind to the IP Address that is assigned to the VPN connection so that torrent traffic is directed through the VPN. (I don't send any other network traffic through the VPN.) This works successfully so that if the VPN drops, the torrent traffic is halted. The issue is that upon reconnection, I may get assigned a different IP address by the VPN. And so the torrent traffic never resumes. I was hoping to solve this by setting up a tun interface (tun0) and having the VPN connect directly to that interface. Then I could have qBittorrent always stay connected to the tun0 interface rather than a specific IP address. But I can't get data to flow through the VPN connected to the tun0 interface. Any assistance would be appreciated. Here's what I have so far:
sudo tunctl -t tun0        # create tun0 interface
sudo ip link set tun0 up   # enable tun0 interface
Edit /etc/strongswan.d/vtun.conf:
charon {
  install_routes = no
  install_virtual_ip_on = tun0  # Connect VPN to tun0 interface
  if_id_in = 1
  if_id_out = 1
  remote_ts = 10.128.0.0/16
}
Restart VPN:
sudo ipsec down vpn-ca-torrent  # shut down VPN
sudo ipsec restart              # restart ipsec 
sudo ipsec up vpn-ca-torrent    # start VPN
VPN is now connected to tun0:
> ip a
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eno1:  mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 98:90:96:c0:1b:8c brd ff:ff:ff:ff:ff:ff
    altname enp0s25
    inet 192.168.0.5/24 metric 100 brd 192.168.0.255 scope global dynamic eno1
       valid_lft 84935sec preferred_lft 84935sec
    inet6 fe80::9a90:96ff:fec0:1b8c/64 scope link
       valid_lft forever preferred_lft forever
3: tun0:  mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
    link/ether 8a:2d:38:87:5d:5c brd ff:ff:ff:ff:ff:ff
    inet 10.128.0.2/32 scope global tun0
       valid_lft forever preferred_lft forever
I now connect qBittorrent to the tun0 interface, but no data flows. Here is additional information:
> sudo iptables -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -i lo -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 tcp -m tcp --dport 32400 -j ACCEPT
-A INPUT -s 192.168.0.0/24 -j ACCEPT
-A INPUT -j DROP
-A FORWARD -j DROP

> cat /etc/ipsec.conf
  conn vpn-ca-torrent
        keyexchange=ikev2
        dpdaction=clear
        dpddelay=300s
        eap_identity=xxxxx@xxx.com
        leftauth=eap-mschapv2
        left=%defaultroute
        leftsourceip=%config
        right=ca-tr.vpnunlimitedapp.com
        rightauth=pubkey
        rightsubnet=0.0.0.0/0
        rightid=ironnodes.com
        type=tunnel
        auto=add
        leftupdown=/usr/lib/ipsec/_updown

> ip r
default via 192.168.0.1 dev eno1 proto dhcp src 192.168.0.5 metric 100
192.168.0.0/24 dev eno1 proto static
192.168.0.0/24 dev eno1 proto kernel scope link src 192.168.0.5 metric 100
192.168.0.1 dev eno1 proto dhcp scope link src 192.168.0.5 metric 100

> resolvectl
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub

Link 2 (eno1)
    Current Scopes: DNS
         Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.168.0.1
       DNS Servers: 192.168.0.1

Link 3 (tun0)
Current Scopes: none
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
**UPDATE:** I've added the changes as suggested: /etc/strongswan.d/vtun.conf:
charon {
  install_routes = no
  install_virtual_ip_on = tun0
  if_id_in = 1
  if_id_out = 1
  remote_ts = 10.128.0.0/16

  leftfirewall=yes
  leftsourceip=%config
  leftsubnet=10.128.0.2/32
  rightsubnet=10.128.0.0/16
}
Once the vpn comes up and attaches to the tun0 interface I add a route to the assigned IP: > sudo ip route add 10.128.0.0/16 dev tun0 via 10.128.0.XX I can ping the remote ip at 10.128.0.XX, but qBittorrent still cannot send traffic over it. When I look through the charon logs, I see these errors:
11[IKE] scheduling reauthentication in 9950s
  11[IKE] maximum IKE_SA lifetime 10490s
  11[IKE] adding DNS server failed
  11[IKE] adding DNS server failed
  11[CFG] handling INTERNAL_IP4_DNS attribute failed
  11[IKE] installing new virtual IP 10.128.0.2
  11[CFG] selected proposal: ESP:AES_CBC_256/HMAC_SHA2_256_128/NO_EXT_SEQ
  11[IKE] CHILD_SA vpn-ca-torrent{3} established with SPIs ca04de43_i ce23bdaf_o and TS 10.128.0.2/32 === 0.0.0.0/0
ip r:
default via 192.168.0.1 dev eno1 proto dhcp src 192.168.0.5 metric 100
10.128.0.0/16 via 10.128.0.2 dev tun0 linkdown
192.168.0.0/24 dev eno1 proto static
192.168.0.0/24 dev eno1 proto kernel scope link src 192.168.0.5 metric 100
192.168.0.1 dev eno1 proto dhcp scope link src 192.168.0.5 metric 100
ip a:
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eno1:  mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 98:90:96:c0:1b:8c brd ff:ff:ff:ff:ff:ff
    altname enp0s25
    inet 192.168.0.5/24 metric 100 brd 192.168.0.255 scope global dynamic eno1
       valid_lft 66730sec preferred_lft 66730sec
    inet6 fe80::9a90:96ff:fec0:1b8c/64 scope link
       valid_lft forever preferred_lft forever
3: tun0:  mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
    link/ether 8a:2d:38:87:5d:5c brd ff:ff:ff:ff:ff:ff
    inet 10.128.0.2/32 scope global tun0
       valid_lft forever preferred_lft forever
furnaceX (51 rep)
Feb 24, 2024, 11:31 PM • Last activity: Feb 29, 2024, 06:28 PM
0 votes
0 answers
182 views
Gre over IPsec Throuput performance
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...
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.
Isravel Raja (1 rep)
Jan 5, 2024, 08:30 PM • Last activity: Jan 8, 2024, 10:13 PM
0 votes
1 answers
2467 views
Fix "unmanaged" network interface if it worked before
**TL;DR;** Maybe I clicked vpn connect wrong and got disconnected from the network. That's why the answer is easy. As usual I wanted to connect to my work network using ipsec via network manager applet. Previously it worked ok but this time after I press "connect" - networking stopped working comple...
**TL;DR;** Maybe I clicked vpn connect wrong and got disconnected from the network. That's why the answer is easy. As usual I wanted to connect to my work network using ipsec via network manager applet. Previously it worked ok but this time after I press "connect" - networking stopped working completely. All my network interfaces are "unmanaged". I tried restarting my laptop - didn't help. I see only solution to reinstall my NixOs (and not even sure if this will help). I tried: * Manually "managed yes" my wlp59s0 interface. * Restarting services: NetworkManager, wpa-supplicant, strongswan. * Add unmanaged=no to the 10-globally-managed-devices.conf I checked journalctl and didn't see anything strange. System info: * Linux 6.6.6 * Network controller: Qualcomm Atheros QCA6174. * Os: NixOs unstable. nmcli device: wlp59s0 wifi unmanaged -- ip a:
wlp59s0:  mtu 1500 qdisc noop state DOWN group default qlen 1000
...
I tried up it - didn't help. I'll repeat one more time that wifi and tunnel worked fine for several days (before I used openvpn, also Ok), then one click - nothing works. Only ping localhost works :( How this even possible?
woojiq (21 rep)
Dec 24, 2023, 10:45 AM • Last activity: Dec 25, 2023, 06:05 PM
1 votes
0 answers
114 views
OPNsense as an IPsec client
I want to setup a permanent VPN connection from one site to another. I already correctly set up an IPsec server on one site, reachable with a fixed IPv4 and IPv6, and domain. What I want to do now, is to set up one of my OPNsense box interfaces (let's say OPT1) to be permanently connected to this IP...
I want to setup a permanent VPN connection from one site to another. I already correctly set up an IPsec server on one site, reachable with a fixed IPv4 and IPv6, and domain. What I want to do now, is to set up one of my OPNsense box interfaces (let's say OPT1) to be permanently connected to this IPsec VPN, so I don't have to configure anything VPN-related on the connected computers/clients inside the network of OPT1. Is this possible? And if yes, how? I already tried to find guidance in this type of VPN, but I couldn't find an exact guide for my use case. Most guides are about how to set up an IPsec SERVER in OPNsense, but what I need is an IPsec CLIENT, which will provide the connection to a physical interface.
Fluttershy (11 rep)
Dec 5, 2023, 05:16 PM
Showing page 1 of 20 total questions