Multiple subnets in IPsec: Only first one is reachable

Virtual Private Networks IPsec
1

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.

2

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.

3

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.

4

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.

5

Any ideas how to debug this?

6

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.

7

Hi,

sorry to warm up this old discussion but i stumpled over the same problem.
Do you found a solution for this problem?
For me it looks not like a iptables rules problem becaus i can see this in ipsec statusall:

NorgeFortigate: child: 192.168.2.0/24 10.234.16.0/24 10.251.150.0/24 === 10.234.72.0/24 10.234.73.0/24 10.234.74.0/24 10.234.76.0/24 TUNNEL, dpdaction=restart

So the subnet parameters are correct but:

NorgeFortigate[7]: IKEv1 SPIs: 906edaa9e6a56282_i* 2e0542523071cdf7_r, pre-shared key reauthentication in 23 hours
NorgeFortigate[7]: IKE proposal: AES_CBC_256/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/CURVE_25519
NorgeFortigate{16}: REKEYED, TUNNEL, reqid 2, expires in 23 hours
NorgeFortigate{16}: 192.168.2.0/24 === 10.234.72.0/24
NorgeFortigate{17}: INSTALLED, TUNNEL, reqid 2, ESP in UDP SPIs: c4398951_i 356c0c1f_o
NorgeFortigate{17}: AES_GCM_16_256/CURVE_25519, 566 bytes_i (7 pkts, 18s ago), 512 bytes_o (7 pkts, 18s ago), rekeying in 23 hours
NorgeFortigate{17}: 192.168.2.0/24 === 10.234.72.0/24

The ipsec tunnel connects only to one subnet (the first one of the list).
So i’m not sure if this is really a firewall problem, for me it looks more like a ipsec connection problem.

Why i will connect to different subnets?
I will only allow some OVPN users to connect to special subnets and if i create a rule for one big net this is not possible.

Silvio

8

Hi Silvio,

only a workaround not a solution, see the aforementioned bug report:
I created two IPsec connections in IPFire with the same values except for the remote subnet.

hth,
Lars

1 Like
9

Hi Lars,

that was something i have tested and it was not working with my Fortigate. The system allows me only one tunnel per connection.
I have to create a single tunnel for every connection on both ends - only possible if you have control over both ends.

Silvio