Project

General

Profile

Issue #3271

Can't reach local subnets when tunneling VPN is active. Passtrough rules don't get active

Added by Alexander Pelz 26 days ago. Updated 15 days ago.

Status:
Feedback
Priority:
Normal
Assignee:
-
Category:
configuration
Affected version:
5.8.1
Resolution:

Description

Hi StrongSwan,

I have an issue with my IPSec tunnel that I cannot ping local subnets even though I have created passtrough rules for them.

The host is a debian on testing (buster) with version 5.8.1:

# alexp at aurora-gw in ~ [7:21:09]
→ sudo ipsec --version
Linux strongSwan U5.8.1/K5.2.0-3-amd64
University of Applied Sciences Rapperswil, Switzerland
See 'ipsec --copyright' for copyright information.

The host has the following network configuration:

# alexp at aurora-gw in ~ [7:21:20]
→ cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug eth0
allow-hotplug eth1

iface eth0 inet static
        address 10.145.40.10
        netmask 255.255.255.0
        gateway 10.145.40.1

        dns-name-server 10.145.50.3

iface eth1 inet static
        address 10.145.40.4
        netmask 255.255.255.0

        dns-name-server 10.145.50.3

eth0 is the outbound interface where also the ipsec vpn will get attached too.
eth1 is local and I use this to connect via SSH to the host and where later on all machines will connect to and will be then routed over an iptables rule to eth0 for outbound connections.
At the moment I cannot reach 10.145.50.3 whenever the VPN is active. Once the vpn is down I can however.

My ipsec.conf looks like this:

# ipsec.conf - strongSwan IPsec configuration file

# basic configuration

config setup
        # strictcrlpolicy=yes
        # uniqueids = no
include /var/lib/strongswan/ipsec.conf.inc

conn KIVPN
  keyexchange=ikev2
  dpdaction=clear

  dpddelay=300s
  eap_identity="Aebian" 

  leftauth=eap-mschapv2
  left=%defaultroute
  leftsourceip=%config

  right=ca.redacted.net
  rightauth=pubkey
  rightsubnet=0.0.0.0/0
  rightid=ca.redacted.net

  rightca=/etc/ipsec.d/cacerts/redacted.pem
  type=tunnel
  auto=start

conn bypass-tunnel
    left=127.0.0.1
    right=127.0.0.1
    leftsubnet=10.145.40.0/24
    authby=never
    type=passthrough
    auto=route

conn bypass-lab
    also=bypass-tunnel
    rightsubnet=10.145.50.0/24

conn bypass-main
    also=bypass-tunnel
    rightsubnet=10.0.0.0/24

conn bypass-transport
    also=bypass-tunnel
    rightsubnet=10.145.40.0/24

Once the VPN is active I can only ping IPs in the subnet of 10.145.40.0/24
Outbound IP works too, e.g. when I ping 1.1.1.1

Do you have any idea what I've been missing? I don't have setup any iptable rules at the moment and also re-installed the linux host once.

Regards,

Alex

redacted.pem (1.77 KB) redacted.pem root ca Alexander Pelz, 25.11.2019 23:19
charon_debug.log (29.1 KB) charon_debug.log Alexander Pelz, 28.11.2019 19:38
charon_debug.log (24.9 KB) charon_debug.log Alexander Pelz, 28.11.2019 20:05
charon_debug.log (38.3 KB) charon_debug.log Alexander Pelz, 28.11.2019 20:49
charon_debug.log (41.8 KB) charon_debug.log Alexander Pelz, 28.11.2019 22:24

History

#1 Updated by Alexander Pelz 26 days ago

Subject has a type. I CANNOT access local subnets :/

#2 Updated by Tobias Brunner 25 days ago

  • Subject changed from Can reach local subnets when tunneling VPN is active. Passtrough rules don't get active to Can't reach local subnets when tunneling VPN is active. Passtrough rules don't get active
  • Status changed from New to Feedback

Status output? Installed policies? Installed routes? see HelpRequests

#3 Updated by Alexander Pelz 25 days ago

Hi Tobias,

Thanks for getting back.

Output of ipsec statusall:

# alexp at aurora-gw in ~ [10:57:24]
→ sudo ipsec statusall
[sudo] password for alexp:
Status of IKE charon daemon (strongSwan 5.8.1, Linux 5.2.0-3-amd64, x86_64):
  uptime: 27 hours, since Nov 18 07:12:21 2019
  malloc: sbrk 2969600, mmap 0, used 1204784, free 1764816
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 4
  loaded plugins: charon aesni aes rc2 sha2 sha1 md5 mgf1 random nonce x509 revocation pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl fips-prf gmp agent xcbc hmac gcm attr kernel-netlink resolve socket-default connmark 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:
  10.145.40.10
Connections:
     KIVPN:  %any...ca.redacted.net  IKEv2, dpddelay=300s
     KIVPN:   local:  uses EAP_MSCHAPV2 authentication with EAP identity 'Aebian'
     KIVPN:   remote: [ca.redacted.net] uses public key authentication
     KIVPN:   child:  dynamic === 0.0.0.0/0 TUNNEL, dpdaction=clear
bypass-tunnel:  127.0.0.1...127.0.0.1  IKEv1/2
bypass-tunnel:   local:  [127.0.0.1] uses public key authentication
bypass-tunnel:   remote: [127.0.0.1] uses public key authentication
bypass-tunnel:   child:  dynamic === 10.145.40.0/24 PASS
  bypass-lab:   child:  10.145.50.0/24 === 10.145.40.0/24 PASS
  bypass-main:   child:  10.0.0.0/24 === 10.145.40.0/24 PASS
  bypass-transport:   child:  10.145.40.0/24 === 10.145.40.0/24 PASS
Shunted Connections:
bypass-tunnel:  dynamic === 10.145.40.0/24 PASS
  bypass-lab:  10.145.50.0/24 === 10.145.40.0/24 PASS
 bypass-main:  10.0.0.0/24 === 10.145.40.0/24 PASS
bypass-transport:  10.145.40.0/24 === 10.145.40.0/24 PASS
Security Associations (1 up, 0 connecting):
     KIVPN[10]: ESTABLISHED 2 hours ago, 10.145.40.10[10.145.40.10]...172.16.16.32[ca.redacted.net]
     KIVPN[10]: IKEv2 SPIs: b858b903549ea416_i* 303f8bc309426f04_r, EAP reauthentication in 8 minutes
     KIVPN[10]: IKE proposal: AES_CBC_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_3072
     KIVPN{40}:  INSTALLED, TUNNEL, reqid 10, ESP in UDP SPIs: c968a7d6_i c66a3e44_o
     KIVPN{40}:  AES_CBC_128/HMAC_SHA2_256_128, 0 bytes_i, 0 bytes_o, rekeying in 29 minutes
     KIVPN{40}:   10.6.3.220/32 === 0.0.0.0/0

iptables-save reports back no rules installed (which is correct):

# alexp at aurora-gw in ~ [12:07:56]
→ sudo iptables-save

# alexp at aurora-gw in ~ [12:07:59]
→

The current routing table:

# alexp at aurora-gw in ~ [12:28:19]
→ ip route show table all
default via 10.145.40.1 dev eth0 table 220 proto static src 10.6.0.147
10.145.40.0/24 dev eth0 table 220 proto static src 10.145.40.10
default via 10.145.40.1 dev eth0 onlink
10.145.40.0/24 dev eth0 proto kernel scope link src 10.145.40.10
10.145.40.0/24 dev eth1 proto kernel scope link src 10.145.40.4
local 10.6.0.147 dev eth0 table local proto kernel scope host src 10.6.0.147
broadcast 10.145.40.0 dev eth0 table local proto kernel scope link src 10.145.40.10
broadcast 10.145.40.0 dev eth1 table local proto kernel scope link src 10.145.40.4
local 10.145.40.4 dev eth1 table local proto kernel scope host src 10.145.40.4
local 10.145.40.10 dev eth0 table local proto kernel scope host src 10.145.40.10
broadcast 10.145.40.255 dev eth0 table local proto kernel scope link src 10.145.40.10
broadcast 10.145.40.255 dev eth1 table local proto kernel scope link src 10.145.40.4
broadcast 127.0.0.0 dev lo table local proto kernel scope link src 127.0.0.1
local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1
local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1
broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1
::1 dev lo proto kernel metric 256 pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium
fe80::/64 dev eth1 proto kernel metric 256 pref medium
local ::1 dev lo table local proto kernel metric 0 pref medium
local fe80::20c:29ff:fe92:e354 dev eth0 table local proto kernel metric 0 pref medium
local fe80::20c:29ff:fe92:e35e dev eth1 table local proto kernel metric 0 pref medium
ff00::/8 dev eth0 table local metric 256 pref medium
ff00::/8 dev eth1 table local metric 256 pref medium

The whole ips:

# alexp at aurora-gw in ~ [12:27:25]
→ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:0c:29:92:e3:54 brd ff:ff:ff:ff:ff:ff
    inet 10.145.40.10/24 brd 10.145.40.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet 10.6.0.147/32 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::20c:29ff:fe92:e354/64 scope link
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:0c:29:92:e3:5e brd ff:ff:ff:ff:ff:ff
    inet 10.145.40.4/24 brd 10.145.40.255 scope global eth1
       valid_lft forever preferred_lft forever
    inet6 fe80::20c:29ff:fe92:e35e/64 scope link
       valid_lft forever preferred_lft forever

I connect to the server via eth1 10.145.40.4

#4 Updated by Tobias Brunner 24 days ago

You probably want to disable charon.plugins.stroke.allow_swap in strongswan.conf (or not set right). Because right is a local address, left* and right* keywords are swapped, which results in the wrong policies. Also, using auto=route for conn bypass-tunnel, which lacks a rightsubnet, might not be ideal. Either set auto in the actual conns or merge one of the bypass policies into it by setting rightsubnet (it can be overridden by conns that "also" it).

#5 Updated by Alexander Pelz 23 days ago

Hello Tobias,

Thanks for the reply. I would like to try this out, but for some reason after a complete system restart the /etc/ipsec.conf don't get read anymore, which is weird, I didn't change anything out of my mind.
Ideas? The parameters I used for the install a week ago where:

./configure --prefix=/usr --sysconfdir=/etc --with-systemdsystemunitdir=/etc/systemd/system --enable-systemd --enable-eap-mschapv2 --enable-eap-peap --enable-bypass-lan --enable-ipseckey --enable-libipsec --enable-blowfish --enable-openssl --enable-curl --enable-ldap --enable-coupling --enable-eap-identity 

#6 Updated by Tobias Brunner 23 days ago

I would like to try this out, but for some reason after a complete system restart the /etc/ipsec.conf don't get read anymore, which is weird, I didn't change anything out of my mind.

ipsec.conf is parsed by the starter daemon and pushed via stroke socket to the daemon. If you use charon-systemd (via strongswan systemd service unit) the former is not started and the file won't be loaded. You could switch to the strongswn-legacy unit, which doesn't start charon-systemd but starter, which in turn starts charon. But I'd encourage you to switch to swanctl.conf, which is loaded by the strongswan unit (via swanctl/vici), and which doesn't have that keyword-switching "feature".

#7 Updated by Alexander Pelz 23 days ago

Hi Tobias,

Thanks, yes swanctl works fine for me.
Can you please show me or share a guide for the config changes I have to make?

Yesterday I tried the swanctl.conf but the layout seemed to be different and even after trying to rewrite nothing was loaded it seems.

#9 Updated by Alexander Pelz 23 days ago

Is the children parameter really needed? My start so far (children replaced with 0):

KIVPN {

KIVPN.version 2
KIVPN.children.0.start_action=start    
KIVPN.children.0.close_action=start

KIVPN.dpd_delay != 0s plus one of
KIVPN.children.0.dpd_action=clear

KIVPN.local.eap_id=Aebian
    }

Do you have maybe a live example?

#10 Updated by Tobias Brunner 22 days ago

Is the children parameter really needed?

It is. The sub-sections define what traffic is protected in what way (CHILD_SAs/policies).

My start so far (children replaced with 0):

Completely wrong. Did you just skip over the parts that describe the basic structure?

Do you have maybe a live example?

Sure (also here but these are not intended to be used directly).

#11 Updated by Alexander Pelz 22 days ago

I'm confused by the swanctl.conf syntax, but I guess I figured it out, need to read a bit deeper into the whole config parameters.
Does this makes any sense?:

connections {
        KIVPN {
                version = 2
                mobike = no
                dpd_delay = 15
                fragmentation = yes
                unique = replace
                reauth_time = 13h
                proposals = aes256-sha512-ecp384
                local {
                        certs = /etc/ipsec.d/cacerts/redacted.pem
                        auth  = pubkey
                        id    = ca.redacted.net
                }
                remote {
                        auth = pubkey
                        id   = ca.redacted.net
                }
                children {
                        KIVPN {
                                esp_proposals = aes256-sha512-ecp384
                                local_ts = 10.145.40.4
                                remote_ts = %any
                                inactivity = 90m
                                rekey_time = 100m
                                mode = tunnel
                        }
                }
        }
}

secrets {

   eap-aebian {
      id = Aebian
      secret = "s3cr3t" 
   }
}

#12 Updated by Tobias Brunner 22 days ago

I'm confused by the swanctl.conf syntax, but I guess I figured it out, need to read a bit deeper into the whole config parameters.

You should definitely read the documentation of these options, possibly related documents (e.g. on rekeying), and perhaps about strongSwan and its configuration files in general.

Does this makes any sense?:

Not sure about the certificate you configured there. The option expects the end-entity certificate, not a CA certificate (which the path indicates).

The remote traffic selector is bogus (it will result in 0.0.0.0/32, if you want to tunnel everything, configure 0.0.0.0/0).

You may also want to request a virtual IP address (via vips = 0.0.0.0).

#13 Updated by Alexander Pelz 21 days ago

Hi Tobias,

I seem to have made good progress:

connections {
        KIVPN {
                version = 2
                mobike = no
                dpd_delay = 15

                fragmentation = yes
                unique = replace
                reauth_time = 13h

                vips = 0.0.0.0
                local_addrs = 10.145.40.10

                local {
                        auth  = eap-mschapv2
                        eap_id = %any
                        id    = ca.redacted.net
                }
                remote {
                        auth = pubkey
                        certs = /etc/ipsec.d/cacerts/redacted.pem
                        id   = ca.redacted.net
                }
                children {
                        net {
                                local_ts = 10.145.40.10/32
                                remote_ts = 0.0.0.0/0
                                inactivity = 90m
                                rekey_time = 100m
                                mode = tunnel
                        }
                }
        }
}

secrets {
   eap-aebian {
      id = Aebian
      secret = S3cr3t
   }
}

My systemctl output:

# alexp at aurora-gw in ~ [14:17:13]
→ sudo systemctl status strongswan
● strongswan.service - strongSwan IPsec IKEv1/IKEv2 daemon using swanctl
   Loaded: loaded (/etc/systemd/system/strongswan.service; disabled; vendor preset: enabled)
   Active: active (running) since Sat 2019-11-23 14:17:13 EST; 2s ago
  Process: 13208 ExecStartPost=/usr/sbin/swanctl --load-all --noprompt (code=exited, status=0/SUCCESS)
 Main PID: 13191 (charon-systemd)
   Status: "charon-systemd running, strongSwan 5.8.1, Linux 4.19.0-6-amd64, x86_64" 
    Tasks: 17 (limit: 4915)
   Memory: 3.5M
   CGroup: /system.slice/strongswan.service
           └─13191 /usr/sbin/charon-systemd

Nov 23 14:17:13 aurora-gw charon-systemd[13191]: interface change for bypass policy for 10.145.40.0/24 (from eth0 to eth1)
Nov 23 14:17:13 aurora-gw charon-systemd[13191]: interface change for bypass policy for fe80::/64 (from eth0 to eth1)
Nov 23 14:17:13 aurora-gw charon-systemd[13191]: loaded EAP shared key with id 'eap-aebian' for: 'Aebian'
Nov 23 14:17:13 aurora-gw swanctl[13208]: no authorities found, 0 unloaded
Nov 23 14:17:13 aurora-gw swanctl[13208]: no pools found, 0 unloaded
Nov 23 14:17:13 aurora-gw charon-systemd[13191]: added vici connection: KIVPN
Nov 23 14:17:13 aurora-gw swanctl[13208]: loaded eap secret 'eap-aebian'
Nov 23 14:17:13 aurora-gw swanctl[13208]: loaded connection 'KIVPN'
Nov 23 14:17:13 aurora-gw swanctl[13208]: successfully loaded 1 connections, 0 unloaded
Nov 23 14:17:13 aurora-gw systemd[1]: Started strongSwan IPsec IKEv1/IKEv2 daemon using swanctl.

One thing I'm now missing is an virtual ip on the interface eth0 and an actual connection to the vpn. When using dig to fetch my public IP then still my local one is used instead of the remote one.
Is there anything I forgot?

Thanks very much for your help!

#14 Updated by Tobias Brunner 19 days ago

Is there anything I forgot?

Possibly initiating the connection (swanctl --initiate or start_action).

#15 Updated by Alexander Pelz 19 days ago

Hi Tobias,

I thought about that, response I got back from the status is this:

# alexp at aurora-gw in ~ [7:21:38]
→ sudo systemctl restart strongswan

# alexp at aurora-gw in ~ [7:21:40]
→ sudo systemctl status strongswan
● strongswan.service - strongSwan IPsec IKEv1/IKEv2 daemon using swanctl
   Loaded: loaded (/etc/systemd/system/strongswan.service; disabled; vendor preset: enabled)
   Active: active (running) since Mon 2019-11-25 07:21:40 EST; 2s ago
  Process: 14174 ExecStartPost=/usr/sbin/swanctl --load-all --noprompt (code=exited, status=0/SUCCESS)
 Main PID: 14157 (charon-systemd)
   Status: "charon-systemd running, strongSwan 5.8.1, Linux 4.19.0-6-amd64, x86_64" 
    Tasks: 17 (limit: 4915)
   Memory: 3.5M
   CGroup: /system.slice/strongswan.service
           └─14157 /usr/sbin/charon-systemd

Nov 25 07:21:40 aurora-gw swanctl[14174]: no authorities found, 0 unloaded
Nov 25 07:21:40 aurora-gw swanctl[14174]: no pools found, 0 unloaded
Nov 25 07:21:40 aurora-gw charon-systemd[14157]: added vici connection: KIVPN
Nov 25 07:21:40 aurora-gw charon-systemd[14157]: initiating 'net'
Nov 25 07:21:40 aurora-gw charon-systemd[14157]: unable to resolve %any, initiate aborted
Nov 25 07:21:40 aurora-gw charon-systemd[14157]: tried to checkin and delete nonexisting IKE_SA
Nov 25 07:21:40 aurora-gw swanctl[14174]: loaded eap secret 'eap-aebian'
Nov 25 07:21:40 aurora-gw swanctl[14174]: loaded connection 'KIVPN'
Nov 25 07:21:40 aurora-gw swanctl[14174]: successfully loaded 1 connections, 0 unloaded
Nov 25 07:21:40 aurora-gw systemd[1]: Started strongSwan IPsec IKEv1/IKEv2 daemon using swanctl.

The latest config:
connections {
        KIVPN {
                version = 2
                mobike = no
                dpd_delay = 15

                fragmentation = yes
                unique = replace
                reauth_time = 13h

                vips = 0.0.0.0
                local_addrs = 10.145.40.10

                local {
                        auth  = eap-mschapv2
                        eap_id = eap-aebian
                        id    = ca.redacted.net
                }
                remote {
                        auth = pubkey
                        certs = /etc/ipsec.d/cacerts/redacted.pem
                        id   = ca.redacted.net
                }
                children {
                        net {
                                local_ts = 10.145.40.10/32
                                remote_ts = 0.0.0.0/0
                                inactivity = 90m
                                rekey_time = 100m
                                mode = tunnel
                                start_action=start
                        }
                }
        }
}

secrets {
   eap-aebian {
      id = Aebian
      secret = S3cr3t
   }
}

Is the vips 0.0.0.0 or maybe the remote_ts 0.0.0/0 the issue here?

#16 Updated by Tobias Brunner 19 days ago

First, read the logs (see HelpRequests).

Is the vips 0.0.0.0 or maybe the remote_ts 0.0.0/0 the issue here?

No, but local_ts definitely makes no sense if you want to use a virtual IP (don't configure it or set it to dynamic).

#17 Updated by Alexander Pelz 18 days ago

Hi Tobias,

I almost got it:

connections {
        KIVPN {
                version = 2
                mobike = yes
                dpd_delay = 15

                reauth_time = 12h
                vips = 10.0.6.1

                local_addrs = 0.0.0.0/0
                remote_addrs = ca.redacted.net

                local {
                        auth = pubkey
                        certs = /etc/ipsec.d/cacerts/redacted.pem
                        id   = ca.redacted.net
                }

                remote {
                        auth  = eap-mschapv2
                        eap_id = %any
                }
                children {
                        net {
                                local_ts = 0.0.0.0/0
                                mode = tunnel
                                dpd_action = trap
                                start_action=start
                        }
                }
        }
}

secrets {
   eap-aebian {
      id = Aebian
      secret = S3cr3t
   }
}

My error:

# alexp at aurora-gw in ~ [17:09:47]
→ sudo systemctl restart strongswan

# alexp at aurora-gw in ~ [17:09:50]
→ sudo systemctl status strongswan
● strongswan.service - strongSwan IPsec IKEv1/IKEv2 daemon using swanctl
   Loaded: loaded (/etc/systemd/system/strongswan.service; disabled; vendor preset: enabled)
   Active: active (running) since Mon 2019-11-25 17:09:50 EST; 2s ago
  Process: 17337 ExecStartPost=/usr/sbin/swanctl --load-all --noprompt (code=exited, status=0/SUCCESS)
 Main PID: 17319 (charon-systemd)
   Status: "charon-systemd running, strongSwan 5.8.1, Linux 4.19.0-6-amd64, x86_64" 
    Tasks: 18 (limit: 4915)
   Memory: 5.7M
   CGroup: /system.slice/strongswan.service
           └─17319 /usr/sbin/charon-systemd

Nov 25 17:09:50 aurora-gw charon-systemd[17319]: initiating IKE_SA KIVPN[1] to 888.888.888.888
Nov 25 17:09:50 aurora-gw charon-systemd[17319]: 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) ]
Nov 25 17:09:50 aurora-gw charon-systemd[17319]: sending packet: from 10.145.40.10[500] to 888.888.888.888[500] (1112 bytes)
Nov 25 17:09:50 aurora-gw charon-systemd[17319]: received packet: from 888.888.888.888[500] to 10.145.40.10[500] (592 bytes)
Nov 25 17:09:50 aurora-gw charon-systemd[17319]: parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(MULT_AUTH) ]
Nov 25 17:09:50 aurora-gw charon-systemd[17319]: selected proposal: IKE:AES_CBC_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_3072
Nov 25 17:09:50 aurora-gw charon-systemd[17319]: local host is behind NAT, sending keep alives
Nov 25 17:09:50 aurora-gw charon-systemd[17319]: sending cert request for "C=PA, O=redacted, CN=redacted Root CA" 
Nov 25 17:09:50 aurora-gw charon-systemd[17319]: sending cert request for "C=PA, O=redacted, CN=redacted Root CA" 
Nov 25 17:09:50 aurora-gw charon-systemd[17319]: no private key found for 'ca.redacted.net'

The swanctl -L output:

# alexp at aurora-gw in ~ [17:14:38]
→ sudo swanctl -L
KIVPN: IKEv2, reauthentication every 43200s, no rekeying, dpd delay 15s
  local:  0.0.0.0/0
  remote: ca.redacted.net
  local public key authentication:
    id: ca.redacted.net
    certs: C=PA, O=redacted, CN=redacted Root CA
  remote EAP_MSCHAPV2 authentication:
    eap_id: %any
  net: TUNNEL, rekeying every 3600s, dpd action is hold
    local:  0.0.0.0/0
    remote: dynamic

The certificate does not have a private key yes, but this should work nonetheless, it worked under ipsec.conf ?!

The ipsec.conf entry had this: rightca=/etc/ipsec.d/cacerts/redacted.pem which according to the wiki is

 connections.<conn>.remote<suffix>.cacerts=<ca certificates> (place in cacerts directory)

Old complete config:

conn KIVPN
  keyexchange=ikev2
  dpdaction=clear
  dpddelay=300s
  eap_identity="Aebian" 
  leftauth=eap-mschapv2
  left=%defaultroute
  leftsourceip=%config
  right=ca.redacted.net
  rightauth=pubkey
  rightsubnet=0.0.0.0/0
  rightid=%SERVER
  rightca=/etc/ipsec.d/cacerts/redacted.pem
  type=tunnel
  auto=add 

#18 Updated by Tobias Brunner 18 days ago

The certificate does not have a private key yes, but this should work nonetheless, it worked under ipsec.conf ?!

You apparently got left|right and local|remote confused.

The ipsec.conf entry had this: rightca=/etc/ipsec.d/cacerts/redacted.pem which according to the wiki is
[...]

That doesn't translate to local.certs rather to remote.cacerts.

#19 Updated by Alexander Pelz 18 days ago

Tobias Brunner wrote:

The certificate does not have a private key yes, but this should work nonetheless, it worked under ipsec.conf ?!

You apparently got left|right and local|remote confused.

The ipsec.conf entry had this: rightca=/etc/ipsec.d/cacerts/redacted.pem which according to the wiki is
[...]

That doesn't translate to local.certs rather to remote.cacerts.


However this will not work. When Switching sides I'll get an error saying that the auth failed.
With cert as remote:

# alexp at aurora-gw in ~ [13:09:07]
→ sudo systemctl status strongswan
● strongswan.service - strongSwan IPsec IKEv1/IKEv2 daemon using swanctl
   Loaded: loaded (/etc/systemd/system/strongswan.service; disabled; vendor preset: enabled)
   Active: active (running) since Tue 2019-11-26 13:09:07 EST; 5s ago
  Process: 18082 ExecStartPost=/usr/sbin/swanctl --load-all --noprompt (code=exited, status=0/SUCCESS)
 Main PID: 18065 (charon-systemd)
   Status: "charon-systemd running, strongSwan 5.8.1, Linux 4.19.0-6-amd64, x86_64" 
    Tasks: 18 (limit: 4915)
   Memory: 3.9M
   CGroup: /system.slice/strongswan.service
           └─18065 /usr/sbin/charon-systemd

Nov 26 13:09:08 aurora-gw charon-systemd[18065]:   using trusted ca certificate "C=PA, O=redacted, CN=redacted Root CA" 
Nov 26 13:09:08 aurora-gw charon-systemd[18065]: checking certificate status of "C=PA, O=redacted, CN=redacted CA3" 
Nov 26 13:09:08 aurora-gw charon-systemd[18065]: certificate status is not available
Nov 26 13:09:08 aurora-gw charon-systemd[18065]:   reached self-signed root ca with a path length of 1
Nov 26 13:09:08 aurora-gw charon-systemd[18065]: authentication of 'ca.redacted.net' with RSA_EMSA_PKCS1_SHA2_256 successful
Nov 26 13:09:08 aurora-gw charon-systemd[18065]: constraint check failed: peer not authenticated with peer cert 'C=PA, O=redacted, CN=redacted Root CA'
Nov 26 13:09:08 aurora-gw charon-systemd[18065]: selected peer config 'KIVPN' unacceptable: constraint checking failed
Nov 26 13:09:08 aurora-gw charon-systemd[18065]: no alternative config found
Nov 26 13:09:08 aurora-gw charon-systemd[18065]: generating INFORMATIONAL request 2 [ N(AUTH_FAILED) ]
Nov 26 13:09:08 aurora-gw charon-systemd[18065]: sending packet: from 10.145.40.10[4500] to 888.888.888.888[4500] (80 bytes)

With cert as local:

# alexp at aurora-gw in ~ [13:13:57]
→ sudo systemctl status strongswan
● strongswan.service - strongSwan IPsec IKEv1/IKEv2 daemon using swanctl
   Loaded: loaded (/etc/systemd/system/strongswan.service; disabled; vendor preset: enabled)
   Active: active (running) since Tue 2019-11-26 13:13:57 EST; 4s ago
  Process: 18147 ExecStartPost=/usr/sbin/swanctl --load-all --noprompt (code=exited, status=0/SUCCESS)
 Main PID: 18130 (charon-systemd)
   Status: "charon-systemd running, strongSwan 5.8.1, Linux 4.19.0-6-amd64, x86_64" 
    Tasks: 18 (limit: 4915)
   Memory: 3.7M
   CGroup: /system.slice/strongswan.service
           └─18130 /usr/sbin/charon-systemd

Nov 26 13:13:57 aurora-gw charon-systemd[18130]: initiating IKE_SA KIVPN[1] to 888.888.888.888
Nov 26 13:13:57 aurora-gw charon-systemd[18130]: 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) ]
Nov 26 13:13:57 aurora-gw charon-systemd[18130]: sending packet: from 10.145.40.10[500] to 888.888.888.888[500] (1112 bytes)
Nov 26 13:13:57 aurora-gw charon-systemd[18130]: received packet: from 888.888.888.888[500] to 10.145.40.10[500] (592 bytes)
Nov 26 13:13:57 aurora-gw charon-systemd[18130]: parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(MULT_AUTH) ]
Nov 26 13:13:57 aurora-gw charon-systemd[18130]: selected proposal: IKE:AES_CBC_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_3072
Nov 26 13:13:57 aurora-gw charon-systemd[18130]: local host is behind NAT, sending keep alives
Nov 26 13:13:57 aurora-gw charon-systemd[18130]: sending cert request for "C=PA, O=redacted, CN=redacted Root CA" 
Nov 26 13:13:57 aurora-gw charon-systemd[18130]: sending cert request for "C=PA, O=redacted, CN=redacted Root CA" 
Nov 26 13:13:57 aurora-gw charon-systemd[18130]: no private key found for 'ca.redacted.net'

#20 Updated by Noel Kuntze 18 days ago

*ca*certs, not just certs.

#21 Updated by Alexander Pelz 18 days ago

Noel Kuntze wrote:

*ca*certs, not just certs.

Hi Noel,

Yes I tried that as well yesterday (and did it again just now), then I get the expected output that I need to use eap-mschapv2 as auth on the remote side instead of the certificate:

# alexp at aurora-gw in ~ [13:25:35]
→ sudo systemctl status strongswan
● strongswan.service - strongSwan IPsec IKEv1/IKEv2 daemon using swanctl
   Loaded: loaded (/etc/systemd/system/strongswan.service; disabled; vendor preset: enabled)
   Active: active (running) since Tue 2019-11-26 13:25:35 EST; 1s ago
  Process: 18204 ExecStartPost=/usr/sbin/swanctl --load-all --noprompt (code=exited, status=0/SUCCESS)
 Main PID: 18187 (charon-systemd)
   Status: "charon-systemd running, strongSwan 5.8.1, Linux 4.19.0-6-amd64, x86_64" 
    Tasks: 18 (limit: 4915)
   Memory: 4.0M
   CGroup: /system.slice/strongswan.service
           └─18187 /usr/sbin/charon-systemd

Nov 26 13:25:36 aurora-gw charon-systemd[18187]: requesting EAP_MSCHAPV2 authentication, sending EAP_NAK
Nov 26 13:25:36 aurora-gw charon-systemd[18187]: generating IKE_AUTH request 3 [ EAP/RES/NAK ]
Nov 26 13:25:36 aurora-gw charon-systemd[18187]: sending packet: from 10.145.40.10[4500] to 888.888.888.888[4500] (80 bytes)
Nov 26 13:25:36 aurora-gw charon-systemd[18187]: received packet: from 888.888.888.888[4500] to 10.145.40.10[4500] (112 bytes)
Nov 26 13:25:36 aurora-gw charon-systemd[18187]: parsed IKE_AUTH response 3 [ EAP/REQ/MSCHAPV2 ]
Nov 26 13:25:36 aurora-gw charon-systemd[18187]: server requested EAP_MSCHAPV2 authentication (id 0x02)
Nov 26 13:25:36 aurora-gw charon-systemd[18187]: no EAP key found for hosts 'ca.redacted.com' - '10.145.40.10'
Nov 26 13:25:36 aurora-gw charon-systemd[18187]: EAP_MSCHAPV2 method failed
Nov 26 13:25:36 aurora-gw charon-systemd[18187]: generating INFORMATIONAL request 4 [ N(AUTH_FAILED) ]
Nov 26 13:25:36 aurora-gw charon-systemd[18187]: sending packet: from 10.145.40.10[4500] to 888.888.888.888[4500] (80 bytes)

#22 Updated by Noel Kuntze 18 days ago

Please paste the config you use when you get these log messages.

#23 Updated by Alexander Pelz 18 days ago

Hi Noel,

The config for the error above your config request is:

connections {
        KIVPN {
                version = 2
                mobike = yes
                dpd_delay = 15

                reauth_time = 12h
                vips = 10.0.6.1

                local_addrs = 0.0.0.0/0
                remote_addrs = ca.redacted.net

                remote {
                        auth = pubkey
                        cacerts = /etc/ipsec.d/cacerts/redacted.pem
                        id   = ca.redacted.net
                }

                local {
                        auth  = eap-mschapv2
                        eap_id = %any
                }
                children {
                        net {
                                local_ts = 0.0.0.0/0
                                mode = tunnel
                                dpd_action = trap
                                start_action=start
                        }
                }
        }
}

secrets {
   eap-aebian {
      id = Aebian
      secret = S3cr3t
   }
}

I also tried to swap remote with local (just swapped the identifier before the bracket but left the entries the same)

#24 Updated by Noel Kuntze 17 days ago

That configuration contains several mistakes.
1. Remove local_addrs = 0.0.0.0/0
2. Set eap_id to your id (Aebian).

Furthermore, please paste the output of `swanctl --stats`.

#25 Updated by Alexander Pelz 17 days ago

Hi Noel,

Update config now looks like this:

connections {
        KIVPN {
                version = 2
                mobike = yes
                dpd_delay = 15

                reauth_time = 12h
                vips = 10.0.6.1

                remote_addrs = ca.redacted.net

                remote {
                        auth = pubkey
                        cacerts = /etc/ipsec.d/cacerts/redacted.pem
                        id   = ca.redacted.net
                }

                local {
                        auth  = eap-mschapv2
                        eap_id = Aebian
                }
                children {
                        net {
                                local_ts = 0.0.0.0/0
                                mode = tunnel
                                dpd_action = trap
                                start_action=start
                        }
                }
        }
}

secrets {
   eap-aebian {
      id = Aebian
      secret = S3cr3t
   }
}

Output of swanctl --stats:

# alexp at aurora-gw in ~ [5:13:27]
→ sudo swanctl --stats
uptime: 25 seconds, since Nov 27 05:13:19 2019
worker threads: 16 total, 11 idle, working: 4/0/1/0
job queues: 0/0/0/0
jobs scheduled: 0
IKE_SAs: 0 total, 0 half-open
mallinfo: sbrk 2973696, mmap 0, used 820928, free 2152768
loaded plugins: charon-systemd bypass-lan ldap aes des blowfish rc2 sha2 sha1 md5 mgf1 random nonce x509 revocation pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl fips-prf gmp curve25519 xcbc cmac hmac curl attr kernel-netlink resolve socket-default stroke vici updown eap-identity eap-mschapv2 eap-peap xauth-generic counters

And the status to the config file above:

# alexp at aurora-gw in ~ [5:13:44]
→ sudo systemctl status strongswan
● strongswan.service - strongSwan IPsec IKEv1/IKEv2 daemon using swanctl
   Loaded: loaded (/etc/systemd/system/strongswan.service; disabled; vendor preset: enabled)
   Active: active (running) since Wed 2019-11-27 05:13:19 EST; 2min 6s ago
  Process: 18632 ExecStartPost=/usr/sbin/swanctl --load-all --noprompt (code=exited, status=0/SUCCESS)
 Main PID: 18615 (charon-systemd)
   Status: "charon-systemd running, strongSwan 5.8.1, Linux 4.19.0-6-amd64, x86_64" 
    Tasks: 17 (limit: 4915)
   Memory: 3.8M
   CGroup: /system.slice/strongswan.service
           └─18615 /usr/sbin/charon-systemd

Nov 27 05:13:19 aurora-gw charon-systemd[18615]:   using trusted ca certificate "C=PA, O=redacted, CN=redacted Root CA" 
Nov 27 05:13:19 aurora-gw charon-systemd[18615]: checking certificate status of "C=PA, O=redacted, CN=redacted CA3" 
Nov 27 05:13:19 aurora-gw charon-systemd[18615]: certificate status is not available
Nov 27 05:13:19 aurora-gw charon-systemd[18615]:   reached self-signed root ca with a path length of 1
Nov 27 05:13:19 aurora-gw charon-systemd[18615]: authentication of 'ca.redacted.net' with RSA_EMSA_PKCS1_SHA2_256 successful
Nov 27 05:13:19 aurora-gw charon-systemd[18615]: constraint check failed: peer not authenticated with peer cert 'C=PA, O=redacted, CN=redacted Root CA'
Nov 27 05:13:19 aurora-gw charon-systemd[18615]: selected peer config 'KIVPN' unacceptable: constraint checking failed
Nov 27 05:13:19 aurora-gw charon-systemd[18615]: no alternative config found
Nov 27 05:13:19 aurora-gw charon-systemd[18615]: generating INFORMATIONAL request 2 [ N(AUTH_FAILED) ]
Nov 27 05:13:19 aurora-gw charon-systemd[18615]: sending packet: from 10.145.40.10[4500] to 888.888.888.888[4500] (80 bytes)

#26 Updated by Noel Kuntze 17 days ago

Okay, thank you.

Please provide complete logs, not just what systemctl gives you.
Make sure verbosity is as described in the snippet on the HelpRequests page and it shows the daemon start, too.

#27 Updated by Alexander Pelz 16 days ago

Hi Noel,

As this log is pretty long, please find it here: https://gist.github.com/Aebian/b847859aec4aeb7634a41fb7d797f276
Loglevel is set to 3, I'm not sure if there is a bigger value to set to. My log config:

charon {
    # two defined file loggers
    filelog {
        charon {
            # path to the log file, specify this as section name in versions prior to 5.7.0
            path = /var/log/charon.log
            # add a timestamp prefix
            time_format = %b %e %T
            # prepend connection name, simplifies grepping
            ike_name = yes
            # overwrite existing files
            append = no
            # increase default loglevel for all daemon subsystems
            default = 3
            # flush each line to disk
            flush_line = yes
        }
        stderr {
            # more detailed loglevel for a specific subsystem, overriding the
            # default loglevel.
            ike = 3
            knl = 3
        }
    }

     load_modular = yes
        plugins {
                include strongswan.d/charon/*.conf
        }

}

Regards,

Alex

#28 Updated by Noel Kuntze 16 days ago

Why didn't you use the settings from the HelpRequests page?

#29 Updated by Alexander Pelz 16 days ago

Hello Noel,

I checked the https://wiki.strongswan.org/projects/strongswan/wiki/HelpRequests and totally oversaw the post at the bottom...

Sorry about that. Attached the log you mentioned...

#30 Updated by Noel Kuntze 16 days ago

Thu, 2019-11-28 13:36 05[IKE] <KIVPN|1> received end entity cert "CN=ca.redacted.net"
Thu, 2019-11-28 13:36 05[CFG] <KIVPN|1> using trusted ca certificate "C=PA, O=Redacted, CN=Redacted Root CA"
Thu, 2019-11-28 13:36 05[CFG] <KIVPN|1> constraint check failed: peer not authenticated with peer cert 'C=PA, O=Redacted, CN=Redacted Root CA'

Do you mind pasting the output of swanctl --list-certs, please?

#31 Updated by Alexander Pelz 16 days ago

Hi Noel,

Sure, it is:

List of X.509 End Entity Certificates

  subject:  "CN=ca.redacted.net" 
  issuer:   "C=PA, O=Redacted, CN=Redacted CA3" 
  validity:  not before Apr 03 06:53:14 2019, ok
             not after  Apr 02 06:53:14 2020, ok (expires in 125 days)
  serial:    5d:f8:cc:74:b2:87:77:67
  altNames:  ca.redacted.net
  flags:     serverAuth ikeIntermediate 
  authkeyId: c2:e2:a7:85:09:52:09:12:88:00:b0:60:7d:eb:51:9f:2f:24:80:87
  subjkeyId: 74:e9:5e:da:78:db:cd:0a:93:39:dc:d6:09:a6:5a:1d:c6:b9:78:17
  pubkey:    RSA 2048 bits
  keyid:     88:ed:c3:42:bb:10:71:f3:78:82:6e:3e:92:9b:4c:90:f0:bf:a5:d0
  subjkey:   74:e9:5e:da:78:db:cd:0a:93:39:dc:d6:09:a6:5a:1d:c6:b9:78:17

List of X.509 CA Certificates

  subject:  "C=PA, O=Redacted, CN=Redacted CA3" 
  issuer:   "C=PA, O=Redacted, CN=Redacted Root CA" 
  validity:  not before Dec 31 19:00:00 2017, ok
             not after  Dec 31 18:59:59 2019, ok (expires in 33 days)
  serial:    04
  flags:     CA CRLSign 
  pathlen:   0
  subjkeyId: c2:e2:a7:85:09:52:09:12:88:00:b0:60:7d:eb:51:9f:2f:24:80:87
  pubkey:    RSA 4096 bits
  keyid:     7d:a6:c2:d0:0b:ea:b3:ce:af:89:82:55:6a:ab:e9:94:09:83:38:94
  subjkey:   c2:e2:a7:85:09:52:09:12:88:00:b0:60:7d:eb:51:9f:2f:24:80:87

  subject:  "C=PA, O=Redacted, CN=Redacted Root CA" 
  issuer:   "C=PA, O=Redacted, CN=Redacted Root CA" 
  validity:  not before Dec 31 19:00:00 2015, ok
             not after  Dec 31 18:59:59 2035, ok (expires in 5877 days)
  serial:    01
  flags:     CA CRLSign self-signed 
  subjkeyId: 53:e8:9e:a8:86:b5:a4:10:30:e1:5c:e4:26:99:71:2f:4c:3f:a4:88
  pubkey:    RSA 4096 bits
  keyid:     e5:61:f5:79:47:ae:5f:40:c2:96:f0:4b:b7:43:41:18:d4:7a:b9:a0
  subjkey:   53:e8:9e:a8:86:b5:a4:10:30:e1:5c:e4:26:99:71:2f:4c:3f:a4:88

#32 Updated by Noel Kuntze 16 days ago

Looks okay. What's the X509 data (openssl x509 -in filegoeshere -noout -text) of /etc/ipsec.d/cacerts/redacted.pem?

#33 Updated by Alexander Pelz 16 days ago

Ho Noel,

Here you go:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1 (0x1)
        Signature Algorithm: sha512WithRSAEncryption
        Issuer: C = PA, O = Redacted, CN = Redacted Root CA
        Validity
            Not Before: Jan  1 00:00:00 2016 GMT
            Not After : Dec 31 23:59:59 2035 GMT
        Subject: C = PA, O = Redacted, CN = Redacted Root CA
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (4096 bit)
                Modulus:
                    00:c9:2b:fc:16:21:ca:8d:05:da:ea:6c:20:c5:f0:
                    0b:a4:2f:91:9a:6c:dc:d3:76:fd:e4:05:91:f4:08:
                    4b:58:2a:97:46:9e:8e:c2:ac:12:79:98:d0:a6:a8:
                    9f:cb:99:09:35:cf:b1:11:f5:81:03:60:83:90:f6:
                    82:2c:5d:77:59:89:52:f5:77:74:4d:f2:f4:52:6b:
                    5c:ca:03:91:77:42:18:1a:1d:bc:a2:72:53:a9:5c:
                    7c:45:45:eb:f5:31:1d:c6:c1:82:e6:4a:f5:4b:51:
                    1d:2f:5e:25:89:b7:ae:92:ff:e6:1b:90:30:2a:69:
                    5f:b9:14:79:0f:1d:a4:2c:1d:de:22:88:4e:ac:1d:
                    d5:9b:9d:0e:ab:16:69:4d:2f:ab:30:b6:1f:9e:48:
                    c9:a6:7f:e7:f4:e7:0a:4d:f5:43:55:0f:e8:19:2c:
                    6d:bb:91:73:03:95:b2:41:03:b2:6e:98:a1:60:e7:
                    9f:f2:08:cc:63:98:9c:52:51:cd:01:f9:8d:3c:f7:
                    8f:54:01:bd:12:2e:42:e0:6e:bd:49:1f:87:1d:45:
                    13:08:70:66:28:2b:73:15:ee:30:ff:90:80:ce:78:
                    91:ec:e0:ce:22:54:69:97:0e:33:6c:c5:de:5b:eb:
                    c0:cb:d7:0c:c7:cd:78:8a:09:00:1b:fd:96:3c:3d:
                    eb:dc:50:f1:cc:d0:09:4e:65:31:59:80:df:b9:6d:
                    bf:91:1c:f5:4e:61:66:ec:24:ff:d4:0e:d5:9f:9d:
                    fe:be:89:c7:49:a5:ba:b4:bc:82:70:80:28:98:30:
                    6b:79:32:67:0e:9e:e0:56:7c:99:82:f8:be:94:51:
                    84:f7:6f:45:35:82:30:99:1e:07:8c:81:1f:28:71:
                    52:64:d1:80:91:e6:e9:84:77:0f:a8:5c:14:07:3d:
                    71:07:13:12:5f:c8:eb:4b:4c:77:3d:f7:1b:a9:b4:
                    3b:8d:ac:42:df:fe:01:1d:d8:09:8f:d1:ba:c5:95:
                    04:90:7f:a8:d4:bd:e0:4b:4d:b6:3f:22:69:e6:c2:
                    41:6d:63:1c:08:6f:1a:61:48:2d:54:7d:97:30:f4:
                    13:35:8a:1e:4b:f2:58:48:e6:51:54:60:08:37:7a:
                    35:ed:de:15:13:52:ef:78:1d:bf:f0:b7:97:96:e8:
                    63:24:9e:bb:87:b1:90:46:15:c5:54:67:f0:38:42:
                    c6:cd:0c:9e:43:07:58:52:ba:33:2c:d7:08:29:fe:
                    26:75:85:0d:83:df:0c:a1:ef:a5:f7:ff:90:b0:e8:
                    6e:d3:c1:7f:e2:db:72:1e:70:43:2f:6a:b9:8d:bb:
                    c5:a8:f4:5f:02:f2:8c:e9:6d:a6:24:93:2d:66:9e:
                    fd:0e:2f
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: 
                CA:TRUE
            X509v3 Key Usage: 
                Certificate Sign, CRL Sign
    Signature Algorithm: sha512WithRSAEncryption
         bd:7d:42:f6:b1:93:f1:20:dd:a6:0f:7d:95:78:dc:92:4e:06:
         65:08:47:55:9a:5a:b8:ef:5a:3f:6c:33:0f:e0:1f:20:9d:07:
         ac:15:1b:57:63:66:42:8e:ce:74:26:6e:f7:07:62:d5:88:bf:
         6a:95:11:26:23:ab:c4:e4:80:bc:22:c4:41:25:25:78:71:ed:
         56:63:1c:97:ae:8e:6b:99:58:3f:93:a6:b5:d2:b9:6c:6c:af:
         de:83:ff:c6:1e:82:71:0d:d5:c3:3a:89:0b:51:29:f1:b7:b8:
         24:dd:02:a9:5f:a7:82:76:1e:bb:a7:43:ee:5a:6f:fb:59:42:
         50:c4:7d:92:0f:1b:13:f6:f0:7f:89:9a:e2:4c:81:1e:fc:82:
         e8:39:01:74:02:aa:7b:02:03:42:70:b7:0b:02:66:f1:5d:09:
         17:60:20:92:07:7e:55:a7:4e:ae:f9:e4:d6:8c:6d:3f:a7:24:
         b9:57:5e:2c:b4:6b:70:f9:f0:34:0c:9a:79:64:95:78:7a:a2:
         79:2e:ac:4c:95:8b:c4:67:fa:8a:4c:47:68:09:e6:97:bf:64:
         04:98:de:9d:56:a8:c3:a1:30:28:93:4b:79:bb:86:11:5f:31:
         15:09:f5:c0:0b:7a:1c:a6:53:5d:b4:20:3b:db:08:c5:25:c4:
         9b:7e:27:f8:05:20:bc:6c:30:02:4d:7b:67:3c:2e:e7:0f:45:
         67:75:92:e9:f9:18:8d:2d:e8:84:36:19:34:a1:30:be:51:57:
         52:73:e9:f6:9c:93:b3:90:22:b4:bd:8b:b4:01:db:38:24:62:
         01:ee:0f:08:07:7c:f6:b7:d2:02:9a:c5:ab:82:78:5d:35:d7:
         0e:7b:5e:41:8a:77:2b:18:0f:1a:bd:0d:5c:59:7b:1f:20:a1:
         23:6e:b9:c4:b8:49:3d:6f:98:de:97:a3:5f:1e:d3:ca:a0:77:
         3d:98:3a:51:74:d3:c8:49:e5:5a:c0:30:4c:d6:62:42:86:77:
         87:b7:9f:4d:87:c1:9a:87:be:3e:4c:cd:63:06:cc:38:7e:12:
         4f:be:87:3b:02:d7:20:ef:8d:09:12:b6:fd:d3:89:99:7e:42:
         04:9a:88:c2:54:f8:41:1d:54:3d:2c:70:40:74:cf:2a:14:8d:
         a4:44:ad:08:ca:73:a6:01:98:5e:c6:53:ff:69:3f:e4:a4:4b:
         04:3f:26:99:42:59:c1:9f:70:27:d4:24:73:f2:1d:12:3c:0a:
         4b:f0:fc:ad:82:06:0a:79:09:91:86:5e:3d:f7:ee:a3:2f:17:
         19:d8:87:a0:2d:fa:aa:e3:57:73:22:3c:07:c1:33:29:96:0f:
         b5:a4:a2:0e:56:88:e9:58

#34 Updated by Noel Kuntze 16 days ago

Okay, can you get the cert that the other peer sends and run the command on that file and paste that output here?

#35 Updated by Alexander Pelz 16 days ago

Hi Noel,

Uh that will be difficult as I don't manage that server and have no access to it. When using the method over ipsec.conf I can get a connection up and running, does this help in any way?

When swapping local with remote the log looks like this, does this help maybe?:

#36 Updated by Noel Kuntze 16 days ago

Okay. Please create logs when using ipsec.conf then, so I can compare.

#37 Updated by Alexander Pelz 16 days ago

Hi Noel,

Despiste the log telling the CA is missing it is there:


# alexp at aurora-gw in ~ [14:48:16]
→ ll /etc/ipsec.d/cacerts/Redacted.pem
-rw-r--r-- 1 root root 1.8K Nov 28 14:48 /etc/ipsec.d/cacerts/Redacted.pem

Attached the log with ipsec.conf

The config file for this log is:

# ipsec.conf - strongSwan IPsec configuration file

# basic configuration

config setup
        # strictcrlpolicy=yes
        # uniqueids = no

conn KIVPN

  keyexchange=ikev2
  dpdaction=clear
  dpddelay=300s
  eap_identity="Aebian" 

  leftauth=eap-mschapv2
  left=%defaultroute
  leftsourceip=%config

  right=ca.Redacted.net
  rightauth=pubkey
  rightsubnet=0.0.0.0/0
  rightid=ca.Redacted.net

  rightca=/etc/ipsec.d/cacerts/Redacted.pem
  type=tunnel
  auto=start

conn bypass-tunnel

    left=127.0.0.1
    right=127.0.0.1
    rightsubnet=10.145.40.0/24

    authby=never
    type=passthrough
    auto=route

conn bypass-lab
    also=bypass-tunnel
    rightsubnet=10.145.50.0/24
    auto=route

conn bypass-main
    also=bypass-tunnel
    rightsubnet=10.0.0.0/24
    auto=route

conn bypass-transport
    also=bypass-tunnel
    rightsubnet=10.145.40.0/24
    auto=route

#38 Updated by Noel Kuntze 15 days ago

rightca takes the DN of the CA certificate, not a path. Because the value was invalid, strongSwan discarded that constraint and that's why it worked. Could you try with a valid rightca setting?

Thu, 2019-11-28 14:46 06[IKE] <KIVPN|1> received end entity cert "CN=ca.redacted.net"
Thu, 2019-11-28 14:46 06[IKE] <KIVPN|1> received issuer cert "C=PA, O=Redacted, CN=Redacted CA3"
Thu, 2019-11-28 14:46 06[CFG] <KIVPN|1> using certificate "CN=ca.redacted.net"
Thu, 2019-11-28 14:46 06[CFG] <KIVPN|1> certificate "CN=ca.redacted.net" key: 2048 bit RSA
Thu, 2019-11-28 14:46 06[CFG] <KIVPN|1> using untrusted intermediate certificate "C=PA, O=Redacted, CN=Redacted CA3"

I have the suspicion that there is also a problem with the usage of the "cacerts" key in swanctl.conf, because the log message emitted indicates strongSwan takes that certificate as the other peer's certificate, not a CA certificate as indicated by the name and the description on the man page.

#39 Updated by Alexander Pelz 15 days ago

Hi Noel,

Can you please guide me what needs to be added? I'm not sure at this point.

CN = Redacted Root CA
O = Redacted
C = PA

What do I now enter in rightca?

left|rightca = <issuer dn> | %same

the distinguished name of a certificate authority which is required to lie in the trust path going from the
left|right participant's certificate up to the root certification authority.
%same means that the value configured for the other participant should be reused.

Tried both Redacted & Redacted Root CA

Regards,

Alex

#40 Updated by Noel Kuntze 15 days ago

You need to use "C=PA, O=Redacted, CN=Redacted Root CA".

#41 Updated by Alexander Pelz 15 days ago

Hi Noel,

Thanks, the certificate has been loaded, ip a shows the virtual ip and the log does not state the error anymore.
Log attached again. Update config is now:

# ipsec.conf - strongSwan IPsec configuration file

# basic configuration

config setup
        # strictcrlpolicy=yes
        # uniqueids = no

conn KIVPN

  keyexchange=ikev2
  dpdaction=clear
  dpddelay=300s
  eap_identity="Aebian" 

  leftauth=eap-mschapv2
  left=%defaultroute
  leftsourceip=%config

  right=ca.redacted.net
  rightauth=pubkey
  rightsubnet=0.0.0.0/0
  rightid=ca.redacted.net

  rightca="C=PA, O=Redacted, CN=Redacted Root CA" 
  type=tunnel
  auto=start

conn bypass-tunnel

    left=127.0.0.1
    right=127.0.0.1
    rightsubnet=10.145.40.0/24

    authby=never
    type=passthrough
    auto=route

conn bypass-lab
    also=bypass-tunnel
    rightsubnet=10.145.50.0/24
    auto=route

conn bypass-main
    also=bypass-tunnel
    rightsubnet=10.0.0.0/24
    auto=route

conn bypass-transport
    also=bypass-tunnel
    rightsubnet=10.145.40.0/24
    auto=route

#42 Updated by Noel Kuntze 15 days ago

That looks okay. I think this problem with the cacerts key is a bug.
Tobias, what do you think?

#43 Updated by Alexander Pelz 15 days ago

Hi Noel,
Hi Tobias,

It works when you put the cert in /etc/swanctl/x509ca

Then use the config:

remote {
                        auth = pubkey
                        cacerts=Redacted.pem
                        id   = ca.redacted.net
                }

The absolute path however does not work.

#44 Updated by Noel Kuntze 15 days ago

I'm surprised that when the cacerts constraint is discarded, strongSwan seems to select a CA cert as the peer cert, maybe based on the id (although none of the CA certs has a usable ID of "ca.redacted.net" (whole DN or one of the SAN fields).

#45 Updated by Tobias Brunner 15 days ago

The absolute path however does not work.

Obviously, /etc/ipsec.d/cacerts/redacted.pem doesn't work in cacerts if the file's name is actually Redacted.pem (file paths are usually case-sensitive on Linux).

I'm surprised that when the cacerts constraint is discarded, strongSwan seems to select a CA cert as the peer cert

Hm, where do you see that?

#46 Updated by Noel Kuntze 15 days ago

These are log lines from when he was using a wrong cacerts constraint (#29, config in #25)
Thu, 2019-11-28 13:36 05[IKE] <KIVPN|1> received end entity cert "CN=ca.redacted.net"
Thu, 2019-11-28 13:36 05[CFG] <KIVPN|1> using trusted ca certificate "C=PA, O=Redacted, CN=Redacted Root CA"
Thu, 2019-11-28 13:36 05[CFG] <KIVPN|1> constraint check failed: peer not authenticated with peer cert 'C=PA, O=Redacted, CN=Redacted Root CA'

#47 Updated by Alexander Pelz 15 days ago

Tobias Brunner wrote:

The absolute path however does not work.

Obviously, /etc/ipsec.d/cacerts/redacted.pem doesn't work in cacerts if the file's name is actually Redacted.pem (file paths are usually case-sensitive on Linux).

Hi, that's just a error on my redaction here on the ticket. Filepath and filename matched all the time with the correct name.

#48 Updated by Tobias Brunner 15 days ago

These are log lines from when he was using a wrong cacerts constraint

I can only imagine that certs was used and not cacerts when that log was produced (unfortunately, neither constraint is logged when the config is loaded).

Hi, that's just a error on my redaction here on the ticket. Filepath and filename matched all the time with the correct name.

I very much doubt that's true (there is no reason whatsoever that the absolute file path wouldn't work). And it's proving once again that redacting configs/logs is just a waste of everyone's time.

Also available in: Atom PDF