I have an IPsec VPN where the remote site uses two subnets. Those two subnets are entered into the "Remote subnet" field separated by comma: "192.168.23.0/24,192.168.24.0/24" I can then ping a host in the .23 subnet, but not in the .24 subnet. This reverses when I reverse the order of the subnets. Configuring it as "192.168.24.0/24,192.168.23.0/24", I can then ping a host in .24, but not in .23 anymore. Comparing the iptables rules (1 = .23 first; 2 = .24 first): 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 Apparently, IPfire only creates iptables rules for the subnet that is entered at the first position.
My forum thread for reference: https://community.ipfire.org/t/multiple-subnets-in-ipsec-only-first-one-is-reachable/1488/
This is working absolutely fine for me. Which release are you on?
IPFire 2.25 (x86_64) - Core Update 141
Could you please post the output of "ipsec statusall"?
atl-ipfire:~# ipsec statusall Status of IKE charon daemon (strongSwan 5.8.1, Linux 4.14.154-ipfire, x86_64): uptime: 17 hours, since Mar 12 19:22:06 2020 malloc: sbrk 2908160, mmap 0, used 1404080, free 1504080 worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 13 loaded plugins: charon aes rc2 des sha2 sha1 md5 mgf1 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl gcrypt fips-prf gmp curve25519 chapoly xcbc cmac hmac ctr ccm gcm curl attr kernel-netlink resolve socket-default farp stroke vici updown eap-identity eap-mschapv2 eap-radius eap-tls eap-ttls eap-peap xauth-generic xauth-eap xauth-noauth dhcp counters Virtual IP pools (size/online/offline): 192.168.110.0/24: 254/0/0 Listening IP addresses: 192.168.120.1 #our_external_ip# 10.119.127.1 Connections: Customer: %any...#customer_ip# IKEv1, dpddelay=30s Customer: local: [#our_external_ip#] uses pre-shared key authentication Customer: remote: [#customer_ip#] uses pre-shared key authentication Customer: child: 10.160.85.0/24 === 192.168.23.0/24 192.168.24.0/24 TUNNEL, dpdaction=restart Routed Connections: OtherCustomer{5}: ROUTED, TUNNEL, reqid 1 OtherCustomer{5}: 10.160.74.0/24 === 10.192.0.0/16 Security Associations (2 up, 0 connecting): Customer[17]: ESTABLISHED 68 seconds ago, #our_external_ip#[#our_external_ip#]...#customer_ip#[#customer_ip#] Customer[17]: IKEv1 SPIs: 2ece5da10a162596_i bb585b0882e4dfce_r*, pre-shared key reauthentication in 2 hours Customer[17]: IKE proposal: AES_CBC_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048 Customer{51}: INSTALLED, TUNNEL, reqid 6, ESP SPIs: c1e3691d_i cbccffcb_o Customer{51}: AES_CBC_128/HMAC_SHA2_256_128/MODP_2048, 315934 bytes_i (948 pkts, 1s ago), 148205 bytes_o (848 pkts, 1s ago), rekeying in 44 minutes Customer{51}: 10.160.85.0/24 === 192.168.23.0/24
(In reply to Larsen from comment #5) > Customer{51}: 10.160.85.0/24 === 192.168.23.0/24 You only negotiated one subnet. I assume that this is some Cisco equipment that simply does not support more than one subnet. So you can either combine them with a larger subnet mask or you will have to create two separate tunnels. We unfortunately have no good and easy way to show what has actually been negotiated in the web UI.
Customer told me this is not some Cisco equipment: > Securepoint UTM v11.8 - 11.8.7.2 > Running as a virtual appliance on a HyperV-cluster. > Some other connections are using multiple subnets Therefore, the problem appears to be with IPFire. Anything I could test to verify it's not?
Customer just informed us that their Securepoint support told them this might be a problem of negotiating both subnets at once. Hence, this should be done one after another. Is this possible?
(In reply to Larsen from comment #7) > > Securepoint UTM v11.8 - 11.8.7.2 > > Running as a virtual appliance on a HyperV-cluster. Oh my god! (In reply to Larsen from comment #8) > Customer just informed us that their Securepoint support told them this > might be a problem of negotiating both subnets at once. Hence, this should > be done one after another. > > Is this possible? You simply need to configure two tunnels on IPFire. They MUST have the same PSK (I suppose you are not using certificates) and they will only create one IKE instance and two ESPs.
Apparently I have to use the same local subnet for both remote subnets. Is that correct? As I first tried it with ".85 -> .23" (first tunnel) and ".86 -> .24" (second tunnel), the second tunnel couldn't be established.
(In reply to Larsen from comment #10) > Apparently I have to use the same local subnet for both remote subnets. Is > that correct? Yes, you only have one subnet anyways, don't you? > As I first tried it with ".85 -> .23" (first tunnel) and ".86 -> .24" > (second tunnel), the second tunnel couldn't be established. I am not sure what those numbers are supposed to represent.
I specify those myself, so in principle I can have a lot of them. Main reason being as I don't have much knowledge there, it was simply more intuitive for me to use a separate local subnet for each different remote subnet. > > As I first tried it with ".85 -> .23" (first tunnel) and ".86 -> .24" > > (second tunnel), the second tunnel couldn't be established. > > I am not sure what those numbers are supposed to represent. Shortened form of the local/remote subnet.
Oh, and thanks of course! =)
(In reply to Larsen from comment #13) > Oh, and thanks of course! =) You are welcome. Also, I can only warmly recommend support: https://www.lightningwirelabs.com/products/ipfire/support
Have already made use of that =)