ikev2 ipsec roadwarrior with virtual subnet configuration issue

[simonvetter]

Hi there,

I am using opnsense as an IPSec VPN access point i.e. opnsense is configured as a responder only, with a roadwarrior/mobile client ikev2 configuration, as shown in https://docs.opnsense.org/manual/how-tos/ipsec-road.html . After authentication, each client gets an ip address from the virtual pool.

This set-up works fine with a single client. As soon as a second session is brought up (by a different user), traffic on the first client stops. Both clients authenticate just fine, security associations are set up (and stay up), but packets are only passed to the last client to have connected.

Logging in through SSH and poking at configuration files, I tracked down the issue to be an ipsec.conf problem:

root@opnsense:~ # cat /usr/local/etc/ipsec.conf
# This file is automatically generated. Do not edit
config setup
  uniqueids = yes
  charondebug=""

conn con2-000
  aggressive = no
  fragmentation = yes
  keyexchange = ikev2
  mobike = yes
  reauth = yes
  rekey = yes
  forceencaps = no
  installpolicy = yes
  type = tunnel
  dpdaction = clear
  dpddelay = 30s
  dpdtimeout = 330s
  left = <globally routable ipv4 address>
  right = %any
  leftid = <FQDN of the firewall>
  ikelifetime = 86400s
  lifetime = 3600s
  rightsourceip = 192.168.0.0/24
  ike = aes256-sha256-ecp384!
  leftauth = pubkey
  rightauth = eap-mschapv2
  eap_identity = %any
  leftcert = /usr/local/etc/ipsec.d/certs/cert-2.crt
  leftsendcert = always

conn con2
  rightsubnet = 192.168.0.0/24
  leftsubnet = 0.0.0.0/0
  esp = aes256gcm16-sha256-modp4096!
  also = con2-000
  auto = add

From https://wiki.strongswan.org/projects/strongswan/wiki/VirtualIP :

[...] the remote traffic selector in swanctl.conf and ipsec.conf (remote_ts and rightsubnet, respectively) defaults to the value %dynamic. This value gets dynamically replaced by the virtual IP assigned to a client. Therefore, no remote traffic selector must be configured on the server when using virtual IPs. This ensures the client's traffic selector is correctly narrowed to the assigned virtual IP (otherwise, every client would get the same traffic selector assigned, resulting in conflicting policies).

Removing "rightsubnet = 192.168.0.0/24" and restarting strongswan solved the issue: multiple roadwarriors can now simultaneously connect and their traffic is correctly routed.

Could that be an ipsec.conf generator problem, or did I miss a setting somewhere?

This is on the latest release (18.1.5, i386/openssl), on an alix2d3 board (not the fastest but it gets the job done).

When creating bug reports, please make sure you provide the following:
    The current OPNsense version where the bug first appeared

I am not sure unfortunately. I started using opnsense around last december and I believe the bug has always been present (VPN flakiness has always been reported but I haven't had time to dig in until now)

    The last OPNsense version where the bug did not exist

Like i said above, I believe the bug was already present when I started using opnsense.

    The exact URL of the GUI page involved (if any)

That would be the IPSec configuration pages. VPN > IPSec > Mobile client/Tunnel configuration.

    A list of steps to replicate the bug

1. Configure opnsense 18.5.1 as in https://docs.opnsense.org/manual/how-tos/ipsec-road.html
2. add two VPN users with a corresponding PSK (I don't think the auth type matters much, but I used EAP for mschapv2).
3. apply changes (which restarts strongswan)
4. connect the first client, notice that it gets an ip from the virtual pool and that its traffic is correctly routed through the tunnel,
5. connect the second client, notice that the first client, while still connected, stops receiving tunneled traffic.
6. log in through SSH, edit /usr/local/etc/ipsec.conf, remove or comment the rightsubnet line, type

ipsec reload

to restart strongswan.
7) disconnect and reconnect both clients, notice that they both get inbound traffic.

Optionally before step 6, type

ipsec statusall
setkey -DP

to inspect ipsec policies and see that with the rightsubnet statement, the entire virtual pool is routed to every client, thus explaining the routing issue i've been seeing.

[AdSchellevis]

Hi,

3c3628c should fix the issue, with ikev1 it worked with ikev2 apparently not.

Can you try and confirm?
Install locally using the command below, then disable/enable ipsec to check.
opnsense-patch 3c3628c

[simonvetter]

It does, thank you.
I didn't do the disable/enable ipsec dance as I am connecting to the firewall through a roadwarrior tunnel. I merely hit Save on the tunnel settings page, checked that the config was properly generated then disconnected and reconnected.
Is that good enough? If not, I'll try a disable/enable on monday.

The generated config file now looks like so:

conn con2
  rightsubnet = 
  leftsubnet = 0.0.0.0/0
  esp = aes256gcm16-sha256-modp4096!
  also = con2-000
  auto = add

did you mean to leave that rightsubnet statement empty? I am not sure if that would be a problem or not.

[AdSchellevis]

oops, missed a spot apparently. eaf1927 solves the empty rightsubnet when tunnel isolation is enabled.

[simonvetter]

works as expected, thanks!

Without tunnel isolation (which I enabled during debugging), this is what the generated file looks like:

# cat /usr/local/etc/ipsec.conf
# This file is automatically generated. Do not edit
config setup
  uniqueids = yes
  charondebug=""

conn con2
  aggressive = no
  fragmentation = yes
  keyexchange = ikev2
  mobike = yes
  reauth = yes
  rekey = yes
  forceencaps = no
  installpolicy = yes
  type = tunnel
  dpdaction = clear
  dpddelay = 60s
  dpdtimeout = 360s
  left = <globally routable ipv4 address>
  right = %any
  leftid = <FQDN of the firewall>
  ikelifetime = 86400s
  lifetime = 3600s
  rightsourceip = 192.168.0.0/24
  ike = aes256-sha256-ecp384!
  leftauth = pubkey
  rightauth = eap-mschapv2
  eap_identity = %any
  leftcert = /usr/local/etc/ipsec.d/certs/cert-2.crt
  leftsendcert = always
  leftsubnet = 0.0.0.0/0
  esp = aes256gcm16-sha256-modp4096!
  auto = add

[AdSchellevis]

thanks for reporting back!