Multiple subnets in IPsec: Only first one is reachable

The local IPFire initiates a connection to a partner’s remote system. The remote endpoint is not ipfire (don’t know what exactly) but capable of handling multiple subnets with one connection.

Problem: The tunnel is established, and I can ping a host on the first subnet, but not on the second subnet. This used to work right after the connection had been configured in IPFire, but not anymore after we updated to Core 141 and restarted yesterday.

I doubt it has something to do with the update as other users have reported the same problem before:
https://forum.ipfire.org/viewtopic.php?t=15419
https://forum.ipfire.org/viewtopic.php?t=8167

Status is missing 192.168.24.0/24:

# ipsec status
Routed Connections:
     other1{4}:  ROUTED, TUNNEL, reqid 1
     other1{4}:   10.160.74.0/24 === 10.192.0.0/16
Security Associations (2 up, 0 connecting):
      partner[19]: ESTABLISHED 87 seconds ago, our_external_ip[our_external_ip]...partner_ip[partner_ip]
      partner{60}:  INSTALLED, TUNNEL, reqid 6, ESP SPIs: c9991a46_i c4f14773_o
      partner{60}:   10.160.85.0/24 === 192.168.23.0/24

“/var/ipfire/vpn/ipsec.conf” has both subnets configured:

conn partner
    left=%defaultroute
    leftsubnet=10.160.85.0/24
    leftfirewall=yes
    lefthostaccess=yes
    right=partner_ip
    rightsubnet=192.168.23.0/24,192.168.24.0/24
    leftid="our_external_ip"
    rightid="partner_ip"
    type=tunnel
    ike=aes128-sha2_256-modp2048!
    esp=aes128-sha2_256-modp2048!
    keyexchange=ikev1
    ikelifetime=3h
    keylife=1h
    dpdaction=restart
    dpddelay=30
    dpdtimeout=120
    authby=secret
    auto=start
    fragmentation=yes

I have already added iptables rules for the second subnet as those apparently were missing:

atl-ipfire:~# iptables --list -n | grep 192.168.23
RETURN     all  --  192.168.23.0/24      10.160.85.0/24       policy match dir in pol ipsec reqid 7 proto 50
MARK       all  --  10.160.85.0/24       192.168.23.0/24      policy match dir out pol ipsec reqid 7 proto 50 MARK set 0x32
RETURN     all  --  192.168.23.0/24      10.160.85.0/24       policy match dir in pol ipsec reqid 7 proto 50
MARK       all  --  10.160.85.0/24       192.168.23.0/24      policy match dir out pol ipsec reqid 7 proto 50 MARK set 0x32
atl-ipfire:~# iptables --list -n | grep 192.168.24
atl-ipfire:~#

Adding manually:

iptables -A IPSECFORWARD -s 192.168.24.0/24 -d 10.160.85.0/24 -m policy --dir in --pol ipsec --reqid 4 --proto esp -j RETURN
iptables -A IPSECFORWARD -s 10.160.85.0/24 -d 192.168.24.0/24 -o red0 -m policy --dir out --pol ipsec --reqid 5 --proto esp -j MARK --set-xmark 0x32/0xffffffff
iptables -A IPSECINPUT -s 192.168.24.0/24 -d 10.160.85.0/24 -i red0 -m policy --dir in --pol ipsec --reqid 5 --proto esp -j RETURN
iptables -A IPSECOUTPUT -s 10.160.85.0/24 -d 192.168.24.0/24 -o red0 -m policy --dir out --pol ipsec --reqid 5 --proto esp -j MARK --set-xmark 0x32/0xffffffff

Also have restarted the IPsec tunnel as someone suggested to no avail.

I have found only one IPSec change in core141 this change a default at new certificate creation so it should not affect the rule generation.

https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=993724b4dd9837af033880d7816511818f030d59

I have also an IPSec with multiple subnets but to a second IPFire that set the rules correct.

Could you show me how the iptables rules should look like for those subnets?
Then I can compare that to my situation and check if maybe something is missing.

The rules looks like your rules but the other subnets are displayed also in ipsec status. (seperated with space) so i think strongswan has not established a multi subnet tunnel.

Any ideas how to debug this?

I now tested switching the order of how I specify the remote subnets (from “192.168.23.0/24,192.168.24.0/24” to “192.168.24.0/24,192.168.23.0/24”).

Whatever subnet comes first, will be pingable. The other not.

Comparing the iptables rules:

atl-ipfire:~# diff 1 2
475,476c475,476
< RETURN     all  --  192.168.23.0/24      10.160.85.0/24       policy match dir in pol ipsec reqid 24 proto 50
< MARK       all  --  10.160.85.0/24       192.168.23.0/24      policy match dir out pol ipsec reqid 24 proto 50 MARK set 0x32
---
> RETURN     all  --  192.168.24.0/24      10.160.85.0/24       policy match dir in pol ipsec reqid 25 proto 50
> MARK       all  --  10.160.85.0/24       192.168.24.0/24      policy match dir out pol ipsec reqid 25 proto 50 MARK set 0x32
489c489
< RETURN     all  --  192.168.23.0/24      10.160.85.0/24       policy match dir in pol ipsec reqid 24 proto 50
---
> RETURN     all  --  192.168.24.0/24      10.160.85.0/24       policy match dir in pol ipsec reqid 25 proto 50
502c502
< MARK       all  --  10.160.85.0/24       192.168.23.0/24      policy match dir out pol ipsec reqid 24 proto 50 MARK set 0x32
---
> MARK       all  --  10.160.85.0/24       192.168.24.0/24      policy match dir out pol ipsec reqid 25 proto 50 MARK set 0x32

Looks buggy to me, so I have created a bug report.