More than one IPSec tunnel phase1 is fine, but adding another phase1 prevents an existing tunnel from re-establishing a connection

lifeboy

This post is deleted!

jimp

When something like this happens it tends to be one of two things:

There is something in the two configurations which conflicts so only one of the two is unique from strongSwan's point of view.
Something internal to strongSwan has gotten confused and you need to stop it and start it again (not restart, as that functions differently).

In either of those cases it's not a bug per se, so unless you can narrow it down further it likely doesn't warrant a Redmine issue since there wouldn't be anything actionable on our part.

lifeboy

UPDATE: After some more experimentation it turns out that the position of the connection in the config file it not relevant. If both con9 and con10 are enabled, then con9 cannot connect. When con10 is disabled (ie, removed from the config file), con9 can connect.
When con10 alone is in the config file, it connects succesfully, but if both con9 and con10 are present, then neither connects.

This is driving me a little crazy here... especially since I cannot see from the logs what the cause may be.

lifeboy

@jimp The start vs restart is something I will do after hours tonight to see if it makes a difference. I have up to this point only used restart. I did notice that restart does not drop established connections.

wrt the connnection configs and a possible conflict: I have only used the UI to create these connection parameters, not didn't hack around in the swanctl.conf file. Where are the "disabled" connections stored? I have not been able to find that even with a grep search.

jimp

The configuration data is all stored in config.xml which on the installation is held in /conf/config.xml.

lifeboy

@jimp

We stopped and started the IPsec service, but the bahaviour is the same.
If one config is in the file, the service starts.
con9 present alone: con9 connects automatically (far side is RouterOS)
com10 present alone: con10 connects if far side is restarted manually, but not automatically (far side is Sophos).
If both con9 and 10 are present, neither connection starts.

Below are two configurations from the swanctl.conf file. There's not overlap or conflict that I can see, but maybe I'm missing something?

     con9 {
            # P1 (ikeid 9): RC
            fragmentation = yes
            unique = replace
            version = 2
            proposals = aes128gcm128-sha256-modp2048,aes128-sha256-modp2048
            dpd_delay = 10s
            rekey_time = 544320s
            reauth_time = 0s
            over_time = 60480s
            rand_time = 60480s
            encap = no
            mobike = no
            local_addrs = 197.214.xxx.yyy
            remote_addrs = 196.250.abc.def
            local {
                    id = 197.214.xxx.yyy
                    auth = psk
            }
            remote {
                    id = %any
                    auth = psk
            }
            children {
                    con9 {
                            # P2 (reqid 13): RC Subnet
                            mode = tunnel
                            policies = yes
                            life_time = 3600s
                            rekey_time = 3240s
                            rand_time = 360s
                            start_action = trap
                            remote_ts = 192.168.0.0/24
                            local_ts = 192.168.152.0/29
                            esp_proposals = aes128gcm128-modp2048,aes128gcm96-modp2048,aes128gcm64-modp2048
                            dpd_action = trap
                    }
            }
    }

    con10 {
            # P1 (ikeid 10): G
            fragmentation = yes
            unique = replace
            version = 2
            proposals = aes128gcm128-sha256-modp2048
            rekey_time = 544320s
            reauth_time = 0s
            over_time = 60480s
            rand_time = 60480s
            encap = no
            mobike = no
            local_addrs = 197.214.xxx.yyy
            remote_addrs = 165.165.cde.fgh
            local {
                    id = 197.214.xxx.yyy
                    auth = psk
            }
            remote {
                    id = %any
                    auth = psk
            }
            children {
                    con10 {
                            # P2 (reqid 17): G server
                            # P2 (reqid 16): G server
                            # P2 (reqid 15): G server
                            # P2 (reqid 14): G server
                            # P2 (reqid 11): G server
                            mode = tunnel
                            policies = yes
                            life_time = 604800s
                            rekey_time = 544320s
                            rand_time = 60480s
                            start_action = trap
                            remote_ts = 10.10.3.0/24,10.10.4.0/24,192.168.3.0/24,10.10.2.0/24,192.168.1.0/24
                            local_ts = 192.168.153.0/24,192.168.153.0/24,192.168.153.0/24,192.168.153.0/24,192.168.153.0/24
                            esp_proposals = aes128gcm128-modp2048,aes128gcm96-modp2048,aes128gcm64-modp2048
                            dpd_action = clear
                    }
            }
    }

jimp

Your problem is almost certainly because both of those have a remote ID of %any and are using pre-shared keys.

strongSwan references pre-shared keys by associating them with a remote identifier. With both of those tunnels enabled, it would have both keys listed for the %any ID, so it's unpredictable which (if either) would ever match.

Fix the remote IDs and both will probably work.

michmoor

@jimp nice.
i have been following this out of curiosity. I have been a bit worried about the stability of IPsec on the platform based on my current experience so this has been an interesting post to follow. I would've never thought about the remote id being a problem. Makes sense

lifeboy

@jimp, you're quite correct about the peer identifier. (No surprise there! )

Thanks for pointing that out. Although we need to finally test the one link after hours tonight, the "g" link is already working with both configs enabled.

Gblenn

@michmoor said in More than one IPSec tunnel phase1 is fine, but adding another phase1 prevents an existing tunnel from re-establishing a connection:

@jimp nice.
i have been following this out of curiosity. I have been a bit worried about the stability of IPsec on the platform based on my current experience so this has been an interesting post to follow. I would've never thought about the remote id being a problem. Makes sense

Indeed an interesting finding and definitely something to investigate to see if it resolves my issue...