Strongswan IPSec Tunnel matching stadard rotes

Hello

I've been trying to set up stable ipsec tunnels using strongswan to connect to our network firewall (paloalto).

The firewall side uses a wide range of private IPs: 172.16.0.0/12, 10.192.0.0/11 and also 192.168.152.0/24. That makes me create three different tunnels so that clients behind openwrt can access everything.

I'm having real problems since I added the network 192.168.152.0/24 to strongswan which is sort of a "legacy" network. It works ok for a while (meaning I can access this network from the Openwrt but very often this tunnel will go down and cause the other two tunnels to act strange.

Looking at the route output I get:

root@openwrt:/etc# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.0.1     0.0.0.0         UG    0      0        0 eth2
10.248.1.0      *               255.255.255.0   U     0      0        0 br-lan
192.168.0.0     *               255.255.255.0   U     0      0        0 eth2
192.168.0.1     *               255.255.255.255 UH    0      0        0 eth2

I think the problem is happening mostly because the ISP side use the 192.168.0.0 network as well which matches one of my tunnels.

How do I address such an issue? I'm planning to implement that on hundreds of devices with many different ISP configurations that I have no control.


config setup
        # strictcrlpolicy=yes
        # uniqueids = no

conn %default
        ikelifetime=20m
        reauth=yes
        rekey=yes
        keylife=10m
        rekeymargin=3m
        rekeyfuzz=0%
        keyingtries=%forever
        type=tunnel

conn paloalto
        keyexchange=ikev1
        aggressive=yes
        ikelifetime=1440m
        keylife=60m
        dpdaction=hold
        dpddelay=10s
        leftcert=xyzclient.pem
        ike=aes128-sha1-modp1024
        esp=aes128-sha1-modp1024
        leftsubnet=10.248.1.0/24
        rightid="DC=br, DC=com, DC=xyz, CN=CA-xyz"
        right=FIREWALL_IP
        leftfirewall=yes
        auto=add
        closeaction=restart

conn xyz-lan
        also=paloalto
        rightsubnet=172.16.0.0/12
        auto=start

conn xyz-dmz
        also=paloalto
        rightsubnet=10.192.0.0/11
        auto=start

conn xyz-leg
        also=paloalto
        rightsubnet=192.168.152.0/24
        auto=start

Your ISP is using 192.168.0.0/24 network which is not interfering with 192.168.152.0/24.
Another thing is, that there is not needed to create three tunnels.
I have strongswan witch such configuration:

leftsubnet=192.168.51.0/24, 192.168.100.0/24, 192.168.52.0/24, 192.168.62.0/24

I had only one problem with strongswan on openwrt. Default openwrt configuration is doing NAT on any kind of network traffic. I disabled NATing for traffic beetween IPsec networks.

Here's another way to skip NAT for the VPN traffic. As an additional benefit, it allows you to define firewall rules specific to the VPN tunnel.
If you want to use a single set of rules for all VPN subnets, option subnet also accepts a list:

  option subnet  '172.16.0.0/12 10.192.0.0/11 192.168.152.0/24'

For your IPsec config, I recommend to:

  • avoid IKEv1 aggressive mode
  • use IKEv2 if possible
  • use at least DH group 14 (modp2048) or elliptic curve DH
  • instead of auto=start and closeaction=restart, use auto=route

I'm not sure if auto=add is needed at all for a section which is only referenced with also=.

You are right about the network I was sure that it was using /8 don't know why. Strongswan only supports that syntax with IKEv2 for left/righ subnet. I had to restrict masquerading as well but I'm using "firewall.user" because Chaos Calmer has a bug and does not allow multiple subnetworks configured via UCI for that.

That's the way I'm doing:

iptables -t nat -A postrouting_wan_rule -d 172.16.0.0/12 -j ACCEPT
iptables -t nat -A postrouting_wan_rule -d 10.0.0.0/8 -j ACCEPT
iptables -t nat -A postrouting_wan_rule -d 192.168.152.82/24 -j ACCEPT

That syntax is not supported for IKEv1 by strongswan. Why shouldn't I use agressive mode and IKEv2? And how is it related to the problem? I tried route without good results though.

Most importantly you really shouldn't be using CC for security reasons anymore.

Do you mean this one?

  option subnet  '172.16.0.0/12 10.192.0.0/11 192.168.152.0/24'

It is meant to be used in a vpn firewall zone, as in the posting I linked to. It should work in combination with any strongswan config as long as the subnets match:

  • multiple conn sections (IKEv1 or IKEv2), one conn per subnet
  • single conn section with multiple subnets (IKEv2 only).

However, it may not work yet on Chaos Calmer.

The other configuration posted by @jtaczanowski is simpler, but does not have a separate vpn zone. You can choose whatever suits you best.

I second the advice to upgrade OpenWrt for security reasons. A recent OpenWrt release also comes with a newer strongswan which may improve stability and interoperability.

Sorry, my warning about IKEv1 aggressive mode does not apply in your case.
IKEv1 aggressive mode transmits a hash that can be used for brute-force cracking of a pre-shared key.
Since you are using certificates, you should be safe from this attack. The identity is still transmitted in the clear, however.
IKEv1 main mode is better in this regard. But since it transmits the identity later in the protocol, it can cause problems with credential selection on the responder.
IKEv2 does not distinguish between main/aggressive mode and does not have these issues.

I recommend to use IKEv2 if supported by the peer, it has many improvements over IKEv1. Further random examples:

  • better handling of dynamic IP addresses (MOBIKE)
  • fewer round-trips

Not related to the problem, just general advice.

With auto=route, the tunnel is established on-demand when traffic matches the policy.
You have to live with a small delay/packet drops when the tunnel is first established, but in my experience it's the most reliable configuration. Of course you should validate this with your devices. I use strongswan on both peers.

What were your results? Did IKE negotiation not happen at all?
Maybe auto=route will start working after you solved the NAT problem.