More than one IPSec tunnel phase1 is fine, but adding another phase1 prevents an existing tunnel from re-establishing a connection
-
This post is deleted! -
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.
-
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.
-
@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.
-
The configuration data is all stored in
config.xmlwhich on the installation is held in/conf/config.xml. -
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 } } } -
Your problem is almost certainly because both of those have a remote ID of
%anyand 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
%anyID, so it's unpredictable which (if either) would ever match.Fix the remote IDs and both will probably work.
-
@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 -
@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.
-
@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 senseIndeed an interesting finding and definitely something to investigate to see if it resolves my issue...