Setting up VPN on Fedora

Ask Fedora
, , , ,
1

I am not sure if this is the right place to ask but I was hoping someone out there might be able to help me. If there is a more appropriate platform for this question please do let me know.

I am trying to set up my work VPN on Fedora. So far I have been unsuccessful. As a test that the VPN actually works I set it up on Ubuntu with success. First I will outline how I setup the VPN on Ubuntu successfully and then outline my attempt on Fedora.

Ubuntu

  1. In console run the following command:
    sudo apt install network-manager-strongswan libcharon-extra-plugins
  2. Go to Settings>Network>VPN
  3. Click +
  4. Select “IPsec/IKEv2 (strongswan)”
  5. I left everything as default accept for:
    Server Address: set to vpn address
    Client Authentication: EAP (Username/Password)
    Client Identity: the username provided by work
    Client Password: the password provided by work
    Options Request an inner IP address: tick
  6. Press Add
  7. Successfully turn on VPN

Fedora

  1. In console run the following command:
    sudo dnf install NetworkManager-strongswan-gnome
  2. Steps 2–6 from Ubuntu attempt
  3. VPN fails to turn on

In an attempt to debug I when to the console and ran:

$ nmcli conn
NAME     UUID                                  TYPE      DEVICE
...
testvpn  e2b2f9d1-15f0-4fd6-930e-4c3d5e62fc41  vpn       --
$ nmcli conn up testvpn
Error: Connection activation failed: Unknown reason
Hint: use 'journalctl -xe NM_CONNECTION=e2b2f9d1-15f0-4fd6-930e-4c3d5e62fc41 + NM_DEVICE=wlo1' to get more details.
$ journalctl -xe NM_CONNECTION=e2b2f9d1-15f0-4fd6-930e-4c3d5e62fc41 + NM_DEVICE=wlo1
...
Aug 18 16:05:44 fedora NetworkManager[1435]: <info>  [1755529544.7784] vpn[0x556bf6adf320,e2b2f9d1-15f0-4fd6-930e-4c3d5e62fc41,"testvpn"]: starting strongswan
Aug 18 16:05:44 fedora NetworkManager[1435]: <warn>  [1755529544.8517] vpn[0x556bf6adf320,e2b2f9d1-15f0-4fd6-930e-4c3d5e62fc41,"testvpn"]: dbus: failure: connect-failed (1)
Aug 18 16:05:44 fedora NetworkManager[1435]: <warn>  [1755529544.8518] vpn[0x556bf6adf320,e2b2f9d1-15f0-4fd6-930e-4c3d5e62fc41,"testvpn"]: dbus: failure: connect-failed (1)
Aug 18 16:05:44 fedora NetworkManager[1435]: <warn>  [1755529544.8520] vpn[0x556bf6adf320,e2b2f9d1-15f0-4fd6-930e-4c3d5e62fc41,"testvpn"]: dbus: failure: login-failed (0)

where ... indicates omitted lines.

After many hours of searching the web I have made no progress on this so hoped someone here might be able to help me.

In case it is helpful, my system details are as follows:

System Details Report

Report details

  • Date generated: 2025-08-18 16:10:47

Hardware Information:

  • Hardware Model: HP HP Envy x360 2-in-1 Laptop 16-ac0xxx
  • Memory: 16.0 GiB
  • Processor: Intel® Core™ Ultra 7 155U Ă— 14
  • Graphics: Intel® Graphics (MTL)
  • Disk Capacity: (null)

Software Information:

  • Firmware Version: F.04
  • OS Name: Fedora Linux 42 (Workstation Edition)
  • OS Build: (null)
  • OS Type: 64-bit
  • GNOME Version: 48
  • Windowing System: Wayland
  • Kernel Version: Linux 6.15.9-201.fc42.x86_64
3

Hi @christopher-k-long - and welcome to :fedora:

I do not use strongswan myself, but have succesfully used both OpenVPN and now Wireguard with Fedora. I guess it being your work VPN means you have to stick with it, though.

I don’t know much about strongswan, but many VPN protocols support multiple algorithms and options, and you did install a “charon” plugin in Ubuntu. There is a Fedora package strongswan-charon-nm - do you have that installed? If the server requires a plugin you don’t have installed, the connection will typically be refused? Just a thought…

Good luck :+1:

/Jaybe

1 Like
4

Hi @jaybe, thank you for taking the time to respond! I believe strongswan-charon-nm is a dependency of NetworkManager-strongswan-gnome. To double check I had it installed I ran:

$ sudo dnf list --installed | grep strongswan
NetworkManager-strongswan.x86_64                     1.6.0-9.fc42                        fedora
NetworkManager-strongswan-gnome.x86_64               1.6.0-9.fc42                        fedora
strongswan.x86_64                                    5.9.14-5.fc41                       fedora
strongswan-charon-nm.x86_64                          5.9.14-5.fc41                       fedora

I will try setting the VPN up with OpenVPN and Wireguard and see if I have any luck.

Thanks
Chris

5

After a bit of searching (I might be wrong but) it appears that OpenVPN don’t support the IPsec with IKEv2 protocol that my work VPN uses.

1 Like
6

To use those you would have to have your employer switch VPN server, you can’t just switch on the client side…

Not sure what the difference is between Ubuntu and Fedora then. Do you still have the Ubuntu machine and can compare logs?

/Jaybe

1 Like
7

I have an Ubuntu virtual machine using Boxes. (My work would be to use the VPN from the virtual machine as it is not something I need everyday. Obviously, it would be more convenient to have the VPN in Fedora.)

Which logs would be of interest?

8

There is no device for the VPN. You need to have it pointed to a device I think

edit:
For instance mine looks like …

[jakfrost ~]$ nmcli conn
NAME UUID TYPE DEVICE
TP-Link_6E40 UUIDnnnnnnnnnnnn wifi wlp3s0
wg0 UUIDxxxxxxxx wireguard wg0

1 Like
9

Thank you for the suggestion. I tried to set the device using the following command:
nmcli con modify testvpn connection.interface-name wlo1 as suggested by centos - how do I attach devices to connections using nmcli? - Unix & Linux Stack Exchange (wlo1 is the device listed for my WiFi so I figured this is what it should be set to). This appeared not to change the output of nmcli conn. But I can see it changed the interface-name when I run:

$ nmcli conn show testvpn
connection.id:                          testvpn
connection.uuid:                        e2b2f9d1-15f0-4fd6-930e-4c3d5e62fc41
connection.stable-id:                   --
connection.type:                        vpn
connection.interface-name:              wlo1
connection.autoconnect:                 no
connection.autoconnect-priority:        0
connection.autoconnect-retries:         -1 (default)
connection.multi-connect:               0 (default)
connection.auth-retries:                -1
connection.timestamp:                   0
connection.permissions:                 user:ckl
connection.zone:                        --
connection.controller:                  --
connection.master:                      --
connection.slave-type:                  --
connection.port-type:                   --
connection.autoconnect-slaves:          -1 (default)
connection.autoconnect-ports:           -1 (default)
connection.down-on-poweroff:            -1 (default)
connection.secondaries:                 --
connection.gateway-ping-timeout:        0
connection.ip-ping-timeout:             0
connection.ip-ping-addresses:           --
connection.ip-ping-addresses-require-all:-1 (default)
connection.metered:                     unknown
connection.lldp:                        default
connection.mdns:                        -1 (default)
connection.llmnr:                       -1 (default)
connection.dns-over-tls:                -1 (default)
connection.mptcp-flags:                 0x0 (default)
connection.wait-device-timeout:         -1
connection.wait-activation-delay:       -1
ipv4.method:                            auto
ipv4.dns:                               --
ipv4.dns-search:                        --
ipv4.dns-options:                       --
ipv4.dns-priority:                      0
ipv4.addresses:                         --
ipv4.gateway:                           --
ipv4.routes:                            --
ipv4.route-metric:                      -1
ipv4.route-table:                       0 (unspec)
ipv4.routing-rules:                     --
ipv4.replace-local-rule:                -1 (default)
ipv4.dhcp-send-release:                 -1 (default)
ipv4.routed-dns:                        -1 (default)
ipv4.ignore-auto-routes:                no
ipv4.ignore-auto-dns:                   no
ipv4.dhcp-client-id:                    --
ipv4.dhcp-iaid:                         --
ipv4.dhcp-dscp:                         --
ipv4.dhcp-timeout:                      0 (default)
ipv4.dhcp-send-hostname-deprecated:     yes
ipv4.dhcp-send-hostname:                -1 (default)
ipv4.dhcp-hostname:                     --
ipv4.dhcp-fqdn:                         --
ipv4.dhcp-hostname-flags:               0x0 (none)
ipv4.never-default:                     no
ipv4.may-fail:                          yes
ipv4.required-timeout:                  -1 (default)
ipv4.dad-timeout:                       -1 (default)
ipv4.dhcp-vendor-class-identifier:      --
ipv4.dhcp-ipv6-only-preferred:          -1 (default)
ipv4.dhcp-ipv6-only-preferred:          -1 (default)
ipv4.link-local:                        0 (default)
ipv4.dhcp-reject-servers:               --
ipv4.auto-route-ext-gw:                 -1 (default)
ipv4.shared-dhcp-range:                 --
ipv4.shared-dhcp-lease-time:            0 (default)
ipv6.method:                            auto
ipv6.dns:                               --
ipv6.dns-search:                        --
ipv6.dns-options:                       --
ipv6.dns-priority:                      0
ipv6.addresses:                         --
ipv6.gateway:                           --
ipv6.routes:                            --
ipv6.route-metric:                      -1
ipv6.route-table:                       0 (unspec)
ipv6.routing-rules:                     --
ipv6.replace-local-rule:                -1 (default)
ipv6.dhcp-send-release:                 -1 (default)
ipv6.routed-dns:                        -1 (default)
ipv6.ignore-auto-routes:                no
ipv6.ignore-auto-dns:                   no
ipv6.never-default:                     no
ipv6.may-fail:                          yes
ipv6.required-timeout:                  -1 (default)
ipv6.ip6-privacy:                       -1 (default)
ipv6.temp-valid-lifetime:               0 (default)
ipv6.temp-preferred-lifetime:           0 (default)
ipv6.addr-gen-mode:                     default
ipv6.ra-timeout:                        0 (default)
ipv6.mtu:                               auto
ipv6.dhcp-pd-hint:                      --
ipv6.dhcp-duid:                         --
ipv6.dhcp-iaid:                         --
ipv6.dhcp-timeout:                      0 (default)
ipv6.dhcp-send-hostname-deprecated:     yes
ipv6.dhcp-send-hostname:                -1 (default)
ipv6.dhcp-hostname:                     --
ipv6.dhcp-hostname-flags:               0x0 (none)
ipv6.auto-route-ext-gw:                 -1 (default)
ipv6.token:                             --
vpn.service-type:                       org.freedesktop.NetworkManager.strongswan
vpn.user-name:                          --
vpn.data:                               address = ..., encap = no, ipcomp = no, method = eap, password-flags = 0, proposal = no, user = ..., virtual = yes
vpn.secrets:                            <hidden>
vpn.persistent:                         no
vpn.timeout:                            0
proxy.method:                           none
proxy.browser-only:                     no
proxy.pac-url:                          --
proxy.pac-script:                       --

I also tried toggling connection.autoconnect but this did not help. I have left connection.interface-name as -- and connection.autoconnect as no. After setting these back I checked that the working Ubuntu VPN outputs exactly the same for nmcli conn show testvpn as the Fedora VPN other than connection.uuid and connection.timestamp. Could it be due to connection.timestamp differing?

10

I don’t use nmcli much, but as I understand it nmcli conn lists connections defined in Network Manager. So VPN connections don’t have devices shown until they are connected. As long as my VPN is not connected, the device is shown as -- for me as well.

It’s the same if you have multiple wifi’s defined. The ones that are not active show -- because they are not connected to a device.

/Jaybe

1 Like
11

There is no device for strongswan, it takes the device needed to contact the server and encrypts the data,

This is a simple setup without certificates and so on, so no idea why it fails.

The main component logging is not NetworkManager, but charon-nm.
May be “journalctl -b -t charon-nm” gives some more information about the problem.

2 Likes
12

Running the following commands:

sudo journalctl --rotate; sudo journalctl --vacuum-time=1s; nmcli conn up testvpn; journalctl -b -t charon-nm

The first two should clear the log (systemd - How to clear journalctl - Unix & Linux Stack Exchange). The next attempts to start the VPN. The third is the log suggested by @hmmsjan. The output is as follows:

Deleted archived journal /var/log/journal/7cbb005d8f8d4894840a2bf0426824e8/system@9a3c62b4ce5547daab7ec3ce4ae35abd-0000000000025165-00063ca93373c97c.journal (3.7M).
Deleted archived journal /var/log/journal/7cbb005d8f8d4894840a2bf0426824e8/user-1000@9a3c62b4ce5547daab7ec3ce4ae35abd-000000000002516c-00063ca9337455a1.journal (3.5M).
Vacuuming done, freed 7.3M of archived journals from /var/log/journal/7cbb005d8f8d4894840a2bf0426824e8.
Vacuuming done, freed 0B of archived journals from /run/log/journal.
Vacuuming done, freed 0B of archived journals from /var/log/journal.
Error: Connection activation failed: Unknown reason
Hint: use 'journalctl -xe NM_CONNECTION=e2b2f9d1-15f0-4fd6-930e-4c3d5e62fc41 + NM_DEVICE=wlo1' to get more details.
Aug 18 21:01:47 fedora charon-nm[27947]: 05[CFG] received initiate for NetworkManager connection testvpn
Aug 18 21:01:47 fedora charon-nm[27947]: 05[CFG] using gateway identity '...'
Aug 18 21:01:47 fedora charon-nm[27947]: 11[KNL] interface -- activated
Aug 18 21:01:47 fedora charon-nm[27947]: 05[CFG] created XFRM interface -- for NetworkManager connection testvpn
Aug 18 21:01:47 fedora charon-nm[27947]: 13[KNL] fe80::e01d:e13d:f6bc:1a3b appeared on --
Aug 18 21:01:47 fedora charon-nm[27947]: 05[IKE] initiating IKE_SA testvpn[2] to 131.111.2.3
Aug 18 21:01:47 fedora charon-nm[27947]: 05[ENC] generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
Aug 18 21:01:47 fedora charon-nm[27947]: 05[NET] sending packet: from 10.30.8.50[55948] to 131.111.2.3[500] (1096 bytes)
Aug 18 21:01:47 fedora charon-nm[27947]: 08[NET] received packet: from 131.111.2.3[500] to 10.30.8.50[55948] (38 bytes)
Aug 18 21:01:47 fedora charon-nm[27947]: 08[ENC] parsed IKE_SA_INIT response 0 [ N(INVAL_KE) ]
Aug 18 21:01:47 fedora charon-nm[27947]: 08[IKE] peer didn't accept DH group ECP_256, it requested CURVE_25519
Aug 18 21:01:47 fedora charon-nm[27947]: 08[IKE] initiating IKE_SA testvpn[2] to 131.111.2.3
Aug 18 21:01:47 fedora charon-nm[27947]: 08[ENC] generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
Aug 18 21:01:47 fedora charon-nm[27947]: 08[NET] sending packet: from 10.30.8.50[55948] to 131.111.2.3[500] (1064 bytes)
Aug 18 21:01:47 fedora charon-nm[27947]: 10[NET] received packet: from 131.111.2.3[500] to 10.30.8.50[55948] (305 bytes)
Aug 18 21:01:47 fedora charon-nm[27947]: 10[ENC] parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(FRAG_SUP) N(HASH_ALG) N(CHDLESS_SUP) N(MULT_AUTH) ]
Aug 18 21:01:47 fedora charon-nm[27947]: 10[CFG] selected proposal: IKE:AES_GCM_16_128/PRF_HMAC_SHA2_256/CURVE_25519
Aug 18 21:01:47 fedora charon-nm[27947]: 10[IKE] local host is behind NAT, sending keep alives
Aug 18 21:01:47 fedora charon-nm[27947]: 10[IKE] remote host is behind NAT
Aug 18 21:01:47 fedora charon-nm[27947]: 10[IKE] received 3 cert requests for an unknown ca
Aug 18 21:01:47 fedora charon-nm[27947]: 10[IKE] establishing CHILD_SA testvpn{2}
Aug 18 21:01:47 fedora charon-nm[27947]: 10[ENC] generating IKE_AUTH request 1 [ IDi N(INIT_CONTACT) CPRQ(ADDR ADDR6 DNS NBNS DNS6) SA TSi TSr N(MOBIKE_SUP) N(ADD_4_ADDR) N(MULT_AUTH) N(EAP_ONLY) N(MSG_ID_SYN_SU>
Aug 18 21:01:47 fedora charon-nm[27947]: 10[NET] sending packet: from 10.30.8.50[58976] to 131.111.2.3[4500] (458 bytes)
Aug 18 21:01:47 fedora charon-nm[27947]: 09[NET] received packet: from 131.111.2.3[4500] to 10.30.8.50[58976] (627 bytes)
Aug 18 21:01:47 fedora charon-nm[27947]: 09[ENC] parsed IKE_AUTH response 1 [ IDr AUTH EAP/REQ/ID ]
Aug 18 21:01:47 fedora charon-nm[27947]: 09[IKE] no trusted RSA public key found for '...'
Aug 18 21:01:47 fedora charon-nm[27947]: 09[ENC] generating INFORMATIONAL request 2 [ N(AUTH_FAILED) ]
Aug 18 21:01:47 fedora charon-nm[27947]: 09[NET] sending packet: from 10.30.8.50[58976] to 131.111.2.3[4500] (65 bytes)
Aug 18 21:01:47 fedora charon-nm[27947]: 07[KNL] interface -- deactivated
Aug 18 21:01:47 fedora charon-nm[27947]: 14[KNL] fe80::e01d:e13d:f6bc:1a3b disappeared from --
Aug 18 21:01:47 fedora charon-nm[27947]: 16[KNL] interface -- deleted
13

I just tried setting up the VPN on a Debian-13 virtual machine wondering if this would work as Debian is closer to Ubuntu than Fedora. Interestingly the VPN also fails to connect on Debian-13.

14

use nm-connection-editor (in terminal to run app) to set it up VPN

Screenshot From 2025-08-19 08-18-31
Screenshot From 2025-08-19 08-18-31536Ă—896 62.9 KB

1 Like
15

There is a chance that this is caused by a certificate on the VPN server which does not contain it’s DNS name as “Subject Alternative Name”. However, at the moment I’m not able to setup a connection too in this way from VM to own Fedora strongswan server, but may be I’m doing something wrong, it’s complex to fit everything together. I hope to be able to look into it further these days.

You can also try to swap strongswan with libreswan and see whether you have more luck with that version.

1 Like
16

Thank you @ledeni for the suggestion. Unfortunately, nm-connection-editor yields the same results.

Here is my test:

$ nm-connection-editor # Setting up the `vpntest_nm_connection_editor` in GUI
$
$ nmcli conn
NAME                          UUID                                  TYPE      DEVICE 
...
testvpn                       e2b2f9d1-15f0-4fd6-930e-4c3d5e62fc41  vpn       --     
vpntest_nm_connection_editor  585efa58-213b-4c5b-aa17-ea76e9fdf212  vpn       -- 
$
$ nmcli conn up vpntest_nm_connection_editor
Error: Connection activation failed: Unknown reason
Hint: use 'journalctl -xe NM_CONNECTION=585efa58-213b-4c5b-aa17-ea76e9fdf212 + NM_DEVICE=wlo1' to get more details.
$
$ journalctl -xe NM_CONNECTION=585efa58-213b-4c5b-aa17-ea76e9fdf212 + NM_DEVICE=wlo1
Aug 19 07:49:21 fedora NetworkManager[1434]: <info>  [1755586161.6085] vpn[0x56171cab8810,585efa58-213b-4c5b-aa17-ea76e9fdf212,"vpntest_nm_connection_editor"]: starting strongswan
Aug 19 07:49:21 fedora NetworkManager[1434]: <warn>  [1755586161.8852] vpn[0x56171cab8810,585efa58-213b-4c5b-aa17-ea76e9fdf212,"vpntest_nm_connection_editor"]: dbus: failure: connect-failed (1)
Aug 19 07:49:21 fedora NetworkManager[1434]: <warn>  [1755586161.8852] vpn[0x56171cab8810,585efa58-213b-4c5b-aa17-ea76e9fdf212,"vpntest_nm_connection_editor"]: dbus: failure: connect-failed (1)
Aug 19 07:49:21 fedora NetworkManager[1434]: <warn>  [1755586161.8857] vpn[0x56171cab8810,585efa58-213b-4c5b-aa17-ea76e9fdf212,"vpntest_nm_connection_editor"]: dbus: failure: login-failed (0)
$
$ sudo journalctl --rotate; sudo journalctl --vacuum-time=1s; nmcli conn up vpntest_nm_connection_editor; journalctl -b -t charon-nm
Vacuuming done, freed 0B of archived journals from /var/log/journal.
Deleted archived journal /var/log/journal/7cbb005d8f8d4894840a2bf0426824e8/system@9a3c62b4ce5547daab7ec3ce4ae35abd-0000000000027a45-00063cb248a7ede3.journal (3.6M).
Deleted archived journal /var/log/journal/7cbb005d8f8d4894840a2bf0426824e8/user-1000@9a3c62b4ce5547daab7ec3ce4ae35abd-0000000000027a4c-00063cb248a8d5f6.journal (3.5M).
Vacuuming done, freed 7.2M of archived journals from /var/log/journal/7cbb005d8f8d4894840a2bf0426824e8.
Vacuuming done, freed 0B of archived journals from /run/log/journal.
Error: Connection activation failed: Unknown reason
Hint: use 'journalctl -xe NM_CONNECTION=585efa58-213b-4c5b-aa17-ea76e9fdf212 + NM_DEVICE=wlo1' to get more details.
Aug 19 07:51:55 fedora charon-nm[7956]: 05[CFG] received initiate for NetworkManager connection vpntest_nm_connection_editor
Aug 19 07:51:55 fedora charon-nm[7956]: 05[CFG] using gateway identity '...'
Aug 19 07:51:55 fedora charon-nm[7956]: 05[CFG] created XFRM interface nm-xfrm-1979834 for NetworkManager connection vpntest_nm_connection_editor
Aug 19 07:51:55 fedora charon-nm[7956]: 07[KNL] interface nm-xfrm-1979834 activated
Aug 19 07:51:55 fedora charon-nm[7956]: 15[KNL] fe80::a20a:f84e:ed91:62f0 appeared on nm-xfrm-1979834
Aug 19 07:51:55 fedora charon-nm[7956]: 05[IKE] initiating IKE_SA vpntest_nm_connection_editor[2] to 131.111.2.3
Aug 19 07:51:55 fedora charon-nm[7956]: 05[ENC] generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
Aug 19 07:51:55 fedora charon-nm[7956]: 05[NET] sending packet: from 10.30.8.50[55358] to 131.111.2.3[500] (1096 bytes)
Aug 19 07:51:55 fedora charon-nm[7956]: 08[NET] received packet: from 131.111.2.3[500] to 10.30.8.50[55358] (38 bytes)
Aug 19 07:51:55 fedora charon-nm[7956]: 08[ENC] parsed IKE_SA_INIT response 0 [ N(INVAL_KE) ]
Aug 19 07:51:55 fedora charon-nm[7956]: 08[IKE] peer didn't accept DH group ECP_256, it requested CURVE_25519
Aug 19 07:51:55 fedora charon-nm[7956]: 08[IKE] initiating IKE_SA vpntest_nm_connection_editor[2] to 131.111.2.3
Aug 19 07:51:55 fedora charon-nm[7956]: 08[ENC] generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
Aug 19 07:51:55 fedora charon-nm[7956]: 08[NET] sending packet: from 10.30.8.50[55358] to 131.111.2.3[500] (1064 bytes)
Aug 19 07:51:55 fedora charon-nm[7956]: 13[NET] received packet: from 131.111.2.3[500] to 10.30.8.50[55358] (305 bytes)
Aug 19 07:51:55 fedora charon-nm[7956]: 13[ENC] parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(FRAG_SUP) N(HASH_ALG) N(CHDLESS_SUP) N(MULT_AUTH) ]
Aug 19 07:51:55 fedora charon-nm[7956]: 13[CFG] selected proposal: IKE:AES_GCM_16_128/PRF_HMAC_SHA2_256/CURVE_25519
Aug 19 07:51:55 fedora charon-nm[7956]: 13[IKE] local host is behind NAT, sending keep alives
Aug 19 07:51:55 fedora charon-nm[7956]: 13[IKE] remote host is behind NAT
Aug 19 07:51:55 fedora charon-nm[7956]: 13[IKE] received 3 cert requests for an unknown ca
Aug 19 07:51:55 fedora charon-nm[7956]: 13[IKE] establishing CHILD_SA vpntest_nm_connection_editor{2}
Aug 19 07:51:55 fedora charon-nm[7956]: 13[ENC] generating IKE_AUTH request 1 [ IDi N(INIT_CONTACT) CPRQ(ADDR ADDR6 DNS NBNS DNS6) SA TSi TSr N(MOBIKE_SUP) N(NO_ADD_ADDR) N(MULT_AUTH) N(EAP_ONLY) N(MSG_ID_SYN_SU>
Aug 19 07:51:55 fedora charon-nm[7956]: 13[NET] sending packet: from 10.30.8.50[58580] to 131.111.2.3[4500] (454 bytes)
Aug 19 07:51:55 fedora charon-nm[7956]: 06[NET] received packet: from 131.111.2.3[4500] to 10.30.8.50[58580] (627 bytes)
Aug 19 07:51:55 fedora charon-nm[7956]: 06[ENC] parsed IKE_AUTH response 1 [ IDr AUTH EAP/REQ/ID ]
Aug 19 07:51:55 fedora charon-nm[7956]: 06[IKE] no trusted RSA public key found for '...'
Aug 19 07:51:55 fedora charon-nm[7956]: 06[ENC] generating INFORMATIONAL request 2 [ N(AUTH_FAILED) ]
Aug 19 07:51:55 fedora charon-nm[7956]: 06[NET] sending packet: from 10.30.8.50[58580] to 131.111.2.3[4500] (65 bytes)
Aug 19 07:51:55 fedora charon-nm[7956]: 09[KNL] interface nm-xfrm-1979834 deactivated
Aug 19 07:51:55 fedora charon-nm[7956]: 15[KNL] fe80::a20a:f84e:ed91:62f0 disappeared from nm-xfrm-1979834
Aug 19 07:51:55 fedora charon-nm[7956]: 14[KNL] interface nm-xfrm-1979834 deleted
$
$ nmcli conn show vpntest_nm_connection_editor
connection.id:                          vpntest_nm_connection_editor
connection.uuid:                        585efa58-213b-4c5b-aa17-ea76e9fdf212
connection.stable-id:                   --
connection.type:                        vpn
connection.interface-name:              --
connection.autoconnect:                 no
connection.autoconnect-priority:        0
connection.autoconnect-retries:         -1 (default)
connection.multi-connect:               0 (default)
connection.auth-retries:                -1
connection.timestamp:                   0
connection.permissions:                 user:ckl
connection.zone:                        --
connection.controller:                  --
connection.master:                      --
connection.slave-type:                  --
connection.port-type:                   --
connection.autoconnect-slaves:          -1 (default)
connection.autoconnect-ports:           -1 (default)
connection.down-on-poweroff:            -1 (default)
connection.secondaries:                 --
connection.gateway-ping-timeout:        0
connection.ip-ping-timeout:             0
connection.ip-ping-addresses:           --
connection.ip-ping-addresses-require-all:-1 (default)
connection.metered:                     unknown
connection.lldp:                        default
connection.mdns:                        -1 (default)
connection.llmnr:                       -1 (default)
connection.dns-over-tls:                -1 (default)
connection.mptcp-flags:                 0x0 (default)
connection.wait-device-timeout:         -1
connection.wait-activation-delay:       -1
ipv4.method:                            auto
ipv4.dns:                               --
ipv4.dns-search:                        --
ipv4.dns-options:                       --
ipv4.dns-priority:                      0
ipv4.addresses:                         --
ipv4.gateway:                           --
ipv4.routes:                            --
ipv4.route-metric:                      -1
ipv4.route-table:                       0 (unspec)
ipv4.routing-rules:                     --
ipv4.replace-local-rule:                -1 (default)
ipv4.dhcp-send-release:                 -1 (default)
ipv4.routed-dns:                        -1 (default)
ipv4.ignore-auto-routes:                no
ipv4.ignore-auto-dns:                   no
ipv4.dhcp-client-id:                    --
ipv4.dhcp-iaid:                         --
ipv4.dhcp-dscp:                         --
ipv4.dhcp-timeout:                      0 (default)
ipv4.dhcp-send-hostname-deprecated:     yes
ipv4.dhcp-send-hostname:                -1 (default)
ipv4.dhcp-hostname:                     --
ipv4.dhcp-fqdn:                         --
ipv4.dhcp-hostname-flags:               0x0 (none)
ipv4.never-default:                     no
ipv4.may-fail:                          yes
ipv4.required-timeout:                  -1 (default)
ipv4.dad-timeout:                       -1 (default)
ipv4.dhcp-vendor-class-identifier:      --
ipv4.dhcp-ipv6-only-preferred:          -1 (default)
ipv4.link-local:                        0 (default)
ipv4.dhcp-reject-servers:               --
ipv4.auto-route-ext-gw:                 -1 (default)
ipv4.shared-dhcp-range:                 --
ipv4.shared-dhcp-lease-time:            0 (default)
ipv6.method:                            auto
ipv6.dns:                               --
ipv6.dns-search:                        --
ipv6.dns-options:                       --
ipv6.dns-priority:                      0
ipv6.addresses:                         --
ipv6.gateway:                           --
ipv6.routes:                            --
ipv6.route-metric:                      -1
ipv6.route-table:                       0 (unspec)
ipv6.routing-rules:                     --
ipv6.replace-local-rule:                -1 (default)
ipv6.dhcp-send-release:                 -1 (default)
ipv6.routed-dns:                        -1 (default)
ipv6.ignore-auto-routes:                no
ipv6.ignore-auto-dns:                   no
ipv6.never-default:                     no
ipv6.may-fail:                          yes
ipv6.required-timeout:                  -1 (default)
ipv6.ip6-privacy:                       -1 (default)
ipv6.temp-valid-lifetime:               0 (default)
ipv6.temp-preferred-lifetime:           0 (default)
ipv6.addr-gen-mode:                     stable-privacy
ipv6.ra-timeout:                        0 (default)
ipv6.mtu:                               auto
ipv6.dhcp-pd-hint:                      --
ipv6.dhcp-duid:                         --
ipv6.dhcp-iaid:                         --
ipv6.dhcp-timeout:                      0 (default)
ipv6.dhcp-send-hostname-deprecated:     yes
ipv6.dhcp-send-hostname:                -1 (default)
ipv6.dhcp-hostname:                     --
ipv6.dhcp-hostname-flags:               0x0 (none)
ipv6.auto-route-ext-gw:                 -1 (default)
ipv6.token:                             --
vpn.service-type:                       org.freedesktop.NetworkManager.strongswan
vpn.user-name:                          --
vpn.data:                               address = ..., encap = no, ipcomp = no, method = eap, password-flags = 0, proposal = no, user = ..., virtual = yes
vpn.secrets:                            <hidden>
vpn.persistent:                         no
vpn.timeout:                            0
proxy.method:                           none
proxy.browser-only:                     no
proxy.pac-url:                          --
proxy.pac-script:                       --

Comparing the output of nmcli conn show for both testvpn and vpntest_nm_connection_editor There are a few differing entries which I summarise here by only showing the differing lines:

$ nmcli conn show testvpn
connection.id:                          testvpn
connection.uuid:                        e2b2f9d1-15f0-4fd6-930e-4c3d5e62fc41
ipv4.dhcp-ipv6-only-preferred:          -1 (default)
ipv6.addr-gen-mode:                     default
$
$ nmcli conn show vpntest_nm_connection_editor
connection.id:                          vpntest_nm_connection_editor
connection.uuid:                        585efa58-213b-4c5b-aa17-ea76e9fdf212

ipv6.addr-gen-mode:                     stable-privacy
17

Thank you for looking into this @hmmsjan!

I have attempted to setup libreswan. Luckily, work have a ipsec.conf for strongswan that I can use. I assume this ipsec.conf is old as some online searching appears to show strongswan moved to a new config format. I had to remove a few options that were not supported by libreswan. I am currently stuck at the following error though:

$ sudo ipsec restart
Redirecting to: systemctl restart ipsec.service
$ sudo ipsec up libreswan_testvpn
"libreswan_testvpn": we cannot identify ourselves with either end of this connection.  0.0.0.0 or 131.111.2.3 are not usable
$ journalctl -xeu ipsec.service
Aug 19 09:15:01 fedora pluto[19477]: SELinux support is enabled in ENFORCING mode.
Aug 19 09:15:01 fedora pluto[19477]: systemd watchdog for ipsec service configured with timeout of 200000000 usecs
Aug 19 09:15:01 fedora pluto[19477]: watchdog: sending probes every 100 secs
Aug 19 09:15:01 fedora pluto[19477]: kernel: directional SA supported by kernel
Aug 19 09:15:01 fedora pluto[19477]: kernel: IPTFS ipsec SA error: requires option CONFIG_XFRM_IPTFS
Aug 19 09:15:01 fedora pluto[19477]: kernel: MIGRATE SA supported by kernel
Aug 19 09:15:01 fedora systemd[1]: Started ipsec.service - Internet Key Exchange (IKE) Protocol Daemon for IPsec.
â–‘â–‘ Subject: A start job for unit ipsec.service has finished successfully
â–‘â–‘ Defined-By: systemd
â–‘â–‘ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
â–‘â–‘ 
â–‘â–‘ A start job for unit ipsec.service has finished successfully.
â–‘â–‘ 
â–‘â–‘ The job identifier is 40497.
Aug 19 09:15:01 fedora pluto[19477]: seccomp security is not enabled
Aug 19 09:15:01 fedora pluto[19477]: "libreswan_testvpn": IKE SA proposals (connection add):
Aug 19 09:15:01 fedora pluto[19477]: "libreswan_testvpn":   1:IKE=AES_GCM_16_256-HMAC_SHA2_512+HMAC_SHA2_256-NONE-ECP_256+ECP_384+ECP_521+CURVE25519+MODP4096+MODP3072+MODP2048+>
Aug 19 09:15:01 fedora pluto[19477]: "libreswan_testvpn":   2:IKE=AES_GCM_16_128-HMAC_SHA2_512+HMAC_SHA2_256-NONE-ECP_256+ECP_384+ECP_521+CURVE25519+MODP4096+MODP3072+MODP2048+>
Aug 19 09:15:01 fedora pluto[19477]: "libreswan_testvpn":   3:IKE=CHACHA20_POLY1305-HMAC_SHA2_512+HMAC_SHA2_256-NONE-ECP_256+ECP_384+ECP_521+CURVE25519+MODP4096+MODP3072+MODP20>
Aug 19 09:15:01 fedora pluto[19477]: "libreswan_testvpn":   4:IKE=AES_CBC_256-HMAC_SHA2_512+HMAC_SHA2_256-HMAC_SHA2_512_256+HMAC_SHA2_256_128-ECP_256+ECP_384+ECP_521+CURVE25519>
Aug 19 09:15:01 fedora pluto[19477]: "libreswan_testvpn":   5:IKE=AES_CBC_128-HMAC_SHA2_512+HMAC_SHA2_256-HMAC_SHA2_512_256+HMAC_SHA2_256_128-ECP_256+ECP_384+ECP_521+CURVE25519>
Aug 19 09:15:01 fedora pluto[19477]: "libreswan_testvpn": Child SA proposals (connection add):
Aug 19 09:15:01 fedora pluto[19477]: "libreswan_testvpn":   1:ESP=AES_GCM_16_256-NONE-NONE-ESN:YES+NO
Aug 19 09:15:01 fedora pluto[19477]: "libreswan_testvpn":   2:ESP=AES_GCM_16_128-NONE-NONE-ESN:YES+NO
Aug 19 09:15:01 fedora pluto[19477]: "libreswan_testvpn":   3:ESP=CHACHA20_POLY1305-NONE-NONE-ESN:YES+NO
Aug 19 09:15:01 fedora pluto[19477]: "libreswan_testvpn":   4:ESP=AES_CBC_256-HMAC_SHA2_512_256+HMAC_SHA2_256_128-NONE-ESN:YES+NO
Aug 19 09:15:01 fedora pluto[19477]: "libreswan_testvpn":   5:ESP=AES_CBC_128-HMAC_SHA2_512_256+HMAC_SHA2_256_128-NONE-ESN:YES+NO
Aug 19 09:15:01 fedora pluto[19477]: "libreswan_testvpn": warning: keyingtries=1 ignored, UP connection will attempt to establish until marked DOWN
Aug 19 09:15:01 fedora pluto[19477]: "libreswan_testvpn": added IKEv2 connection
Aug 19 09:15:01 fedora pluto[19477]: addconn: "libreswan_testvpn": warning: keyingtries=1 ignored, UP connection will attempt to establish until marked DOWN
Aug 19 09:15:01 fedora pluto[19477]: addconn: "libreswan_testvpn": added IKEv2 connection
Aug 19 09:15:01 fedora pluto[19477]: addconn:
Aug 19 09:15:01 fedora pluto[19477]: listening for IKE messages
Aug 19 09:15:01 fedora pluto[19477]: Kernel supports NIC esp-hw-offload
Aug 19 09:15:01 fedora pluto[19477]: adding interface virbr0 192.168.122.1:UDP/500
Aug 19 09:15:01 fedora pluto[19477]: adding interface virbr0 192.168.122.1:UDP/4500 (NAT)
Aug 19 09:15:01 fedora pluto[19477]: adding interface wlo1 10.30.8.50:UDP/500
Aug 19 09:15:01 fedora pluto[19477]: adding interface wlo1 10.30.8.50:UDP/4500 (NAT)
Aug 19 09:15:01 fedora pluto[19477]: adding interface lo 127.0.0.1:UDP/500
Aug 19 09:15:01 fedora pluto[19477]: adding interface lo 127.0.0.1:UDP/4500 (NAT)
Aug 19 09:15:01 fedora pluto[19477]: adding interface lo [::1]:UDP/500
Aug 19 09:15:01 fedora pluto[19477]: adding interface lo [::1]:UDP/4500 (NAT)
Aug 19 09:15:01 fedora pluto[19477]: loading secrets from "/etc/ipsec.secrets"
Aug 19 09:15:01 fedora pluto[19477]: "/etc/ipsec.secrets" line 2: WARNING: ignored unrecognized keyword: EAP
Aug 19 09:15:01 fedora pluto[19477]: addconn: listening for IKE messages
Aug 19 09:15:01 fedora pluto[19477]: addconn: Kernel supports NIC esp-hw-offload
Aug 19 09:15:01 fedora pluto[19477]: addconn: adding interface virbr0 192.168.122.1:UDP/500
Aug 19 09:15:01 fedora pluto[19477]: addconn: adding interface virbr0 192.168.122.1:UDP/4500 (NAT)
Aug 19 09:15:01 fedora pluto[19477]: addconn: adding interface wlo1 10.30.8.50:UDP/500
Aug 19 09:15:01 fedora pluto[19477]: addconn: adding interface wlo1 10.30.8.50:UDP/4500 (NAT)
Aug 19 09:15:01 fedora pluto[19477]: addconn: adding interface lo 127.0.0.1:UDP/500
Aug 19 09:15:01 fedora pluto[19477]: addconn: adding interface lo 127.0.0.1:UDP/4500 (NAT)
Aug 19 09:15:01 fedora pluto[19477]: addconn: adding interface lo [::1]:UDP/500
Aug 19 09:15:01 fedora pluto[19477]: addconn: adding interface lo [::1]:UDP/4500 (NAT)
Aug 19 09:15:01 fedora pluto[19477]: addconn: loading secrets from "/etc/ipsec.secrets"
Aug 19 09:15:01 fedora pluto[19477]: addconn: "/etc/ipsec.secrets" line 2: WARNING: ignored unrecognized key
Aug 19 09:15:01 fedora pluto[19477]: addconn: word: EAP
Aug 19 09:15:01 fedora pluto[19477]: addconn:
Aug 19 09:15:04 fedora pluto[19477]: |   initiate: remote_host=<null> (using host from connection) (initiate_connection() +69 programs/pluto/initiate.c)
Aug 19 09:15:04 fedora pluto[19477]: |     connection $1: "libreswan_testvpn"
Aug 19 09:15:04 fedora pluto[19477]: |       host: 0.0.0.0->131.111.2.3
Aug 19 09:15:04 fedora pluto[19477]: |       id: ... -> C=GB, ST=..., O=..., CN=...
Aug 19 09:15:04 fedora pluto[19477]: |       routing+kind: UNROUTED TEMPLATE
Aug 19 09:15:04 fedora pluto[19477]: |       selectors: <unset-selector> -> 0.0.0.0/0 ->; lease: -> ->
Aug 19 09:15:04 fedora pluto[19477]: |       spds:
Aug 19 09:15:04 fedora pluto[19477]: |       policy: IKEv2+RSASIG+ECDSA+RSASIG_v1_5+ENCRYPT+TUNNEL+PFS+IKE_FRAG_ALLOW+ESN_NO+ESN_YES
Aug 19 09:15:04 fedora pluto[19477]: "libreswan_testvpn": we cannot identify ourselves with either end of this connection.  0.0.0.0 or 131.111.2.3 are not usable

Here is my /etc/ipsec.conf:

# @@CONFDIR@@/ipsec.conf - Libreswan 4.x configuration file
#
# see 'man ipsec.conf' and 'man pluto' for more information
#
# For example configurations and documentation, see https://libreswan.org/wiki/

config setup
        # If logfile= is unset, syslog is used to send log messages too.
        # Note that on busy VPN servers, the amount of logging can trigger
        # syslogd (or journald) to rate limit messages.
        #logfile=/var/log/pluto.log

        # Debugging should only be used to find bugs, not configuration issues!
        # "base" regular debug, "tmi" is excessive (!) and "private" will log
        # sensitive key material (not available in FIPS mode). The "cpu-usage"
        # value logs timing information and should not be used with other
        # debug options as it will defeat getting accurate timing information.
        # Default is "none"
        # plutodebug="base"
        # plutodebug="tmi"
        #plutodebug="none"

        # Whether to log IP addresses of incoming connections. Disable when
        # logfile privacy is required.
        #logip=yes

        # The startup mode of the DDoS defense mechanism. Acceptable values
        # are busy, unlimited or auto (the default). This option can also be
        # given to the IKE daemon while running, for example by issuing ipsec
        # whack --ddos--busy. When in busy mode, pluto activates the IKEv2
        # anti-DDoS # counter measures.
        #ddos-mode=auto

        # DDoS defense mechanism threshold
        # The number of half-open IKE SAs before the pluto IKE daemon will be
        # placed in (anti-ddos) busy mode. The default is 25000.

        # IKEv1 policy (accept, reject or drop)
        # See RFC XXX - Deprecation of IKEv1 and obsoleted algorithms
        #ikev1-policy=accept

        # IKEv2 global redirect (during IKE_SA_INIT)
        # Whether to send requests for the remote peer to redirect IKE/IPsec
        # SA's during IKE_SA_INIT. Valid options are no (the default), yes
        # and auto, where auto means that the requests will be sent if DDoS
        # mode is active (see ddos-mode). If set, the option
        # global-redirect-to= must also be set to indicate where to redirect
        # peers to. this can be given to the IKE daemon while running using
        # ipsec whack --global-redirect{-to}
        #global-redirect=no
        #global-redirect-to=<ip or hostname>, ...

        # The number of half-open IKE SAs before the IKE daemon starts
        # refusing all new IKE attempts. Established IKE peers are not
        # affected.
        #max-halfopen-ike=5000

        # Whether pluto performs DNSSEC validation.
        #dnssec-enable=yes

        # To accept IKE and IPsec encapsulation over TCP. Requires at least
        # Linux 5.7 kernel or a kernel with TCP backport (like RHEL8 4.18.0-291)
        # To enable IKE and IPsec over TCP for VPN client, also specify
        # tcp-remote-port=4500 in the client's conn section.
        #listen-tcp=no

        # SECCOMP syscall filtering (enabled,disabled or tolerant)
        # Whether to log (when tolerant) or restart (when enabled) when
        # a rogue syscall is attempted by pluto indicating a remote code
        # exploit attempt.  # If using custom _updown scripts, this might
        # trigger false positives.
        #seccomp=disabled

# if it exists, include system wide crypto-policy defaults
#include /etc/crypto-policies/back-ends/libreswan.config

# It is best to add your IPsec connections as separate files
# in /etc/ipsec.d/
#include /etc/ipsec.d/*.conf

conn libreswan_testvpn
        keyexchange=ikev2
        ikelifetime=60m
        keylife=20m
        rekeymargin=3m
        keyingtries=1
        # eap_identity=%any
        reauth=no
        left=%any
        leftid=...
        # leftauth=eap
        leftautheap=tls
        # leftsourceip=%config
        # leftfirewall=yes
        rightid="C=GB, ST=..., O=..., CN=..."
        rightca="C=US, ST=..., L=..., O=..., CN=..."
        rightsubnet=0.0.0.0/0
        auto=add

and my /etc/ipsec.secrets:

... : EAP "..."

Any ideas?

18

Libreswan looks as complicated as strongswan or worse… Could it be that 0.0.0.0/0 is not supported but “%any” instead?

From your charon-nm log:

I assume this is edited to hide company info?

At the moment, I have a working strongswan-strongswan connection without NetworkManger, both F42. I got the same message for a server certificate without SAN (“Subject Alternative Name”). But after correction, I also definitively needed the (self-signed) CA certificate in place on the client. If your company has a certificate with known authority, this might not be needed as strongswan can find it in the sytem store.

The actual connection I have is like the EAP-MSCHAP example in the strongswan examples, with certificate on the server. The “no RSA public key” error in your case suggests the same. Not yet tested with NM.

1 Like
19

I got it working in NetworkManager/Strongswan
Server: The server certificate must have it’s ID in SAN of certificate

NetworkManager Client:
CA certificate in ~/.cert and entered in “Certificate” field.
Identity: server identity as in the SAN field
Client identity: == username
Username/password.

This might be dependent of the actual server configuration, but in principle it should be able to work.
Take care of SELinux, test with “setenforce 0”

Correction: Do not store certificates under ~/.cert, you will get unexplainable “Permission Denied” . Explanation: charon-nm lacks homedir capabilities.
Better in /etc/strongswan/swanctl/x509 or x509ca.
But that requires “sudo nm-connection-editor” and store password for all users.

1 Like
20

@hmmsjan, yes throughout my logs posted here I have used ... to remove company information and anything I thought should be kept private.

I am unsure where to set the identities. The form nm-connection-editor presents is:

Screenshot From 2025-08-19 16-07-06
Screenshot From 2025-08-19 16-07-06823Ă—1282 99.7 KB

I tried setting server identity to C=GB, ST=..., O=..., CN=... (i.e., the value for rightid in the ipsec.conf file from above) and client identity to my username (again the same as in the ipsec.conf file from above). However, this did not work.

I am unsure where I would get a certificate as it is not something work seems to provide nor something I have needed to use this VPN on Ubuntu (or windows in the past). Further the certificate fields are all greyed out for the client side anyway.

I am not sure I really understand what SAN is so I will have to read a bit more tonight.

21

It might be interesting to see Ubuntus charon-nm log entries for comparison.
I do not know the Debian version Ubuntu is based on, Debian 13 is brand new.

The ipsec.conf you got introduces something I did never use: autheap=tls. I understood this authenticates via TLS both peers by certificate, but a Win client can override this and force MSCHap authentication.

Your ipsec.conf refers to a server certificate and server ca by the certicate’s parameters.
The rightsubnet=0.0.0.0/0 means that all traffic goes via VPN, hoping that all routing is correct.

In the NM setup form, the client certificate/certificate file/private key are greyed out by selecting EAP for authentication, but you can select EAP-TLS. In that case the username is greyed out and apperently the password is then the private key password.
This is without exact knowledge of what the server expects a complex matter and I’m very surprised that Ubuntu works out-of-the box.

Linux mint 22: works too after adding CA certificate and specifying server ID. What’s interesting: it sends certifcate requests to all OS CA’s, (but receives only my own), which I do not see in Fedora. Could your company’s CA be in this commercial CA list?

1 Like