[strongSwan] Tunnels with dynamic IP and another route issue
Dusan Ilic
dusan at comhem.se
Sat Apr 29 18:34:08 CEST 2017
It works! I found a hidden setting under Phase 1 in Fortigate where i
could add the local ID. Added it's dynamic dns hostname and now it connects.
However, I still have issues with another endpoint I'm testing. My local
endpoint have Strongswan 5.5.1 and the remote endpoint have 4.5.2. Would
that present any issues or incompatibilites? Unfortunately it's not
possible to upgrade the remote endpoint (Strongswan).
I tried below, per your suggestion
left=%local.example
leftid=local.example
right=%remote.example
rightid=remote.example
remote.example : PSK "PSKGOESHERE"
Log when local sides initiates connection:
parsed IKE_AUTH response 1 [ N(AUTH_FAILED) ]
received AUTHENTICATION_FAILED notify error
Log when remote side initiates connection:
Apr 29 16:32:20 R6250 daemon.info charon: 10[CFG] looking for peer configs matching 85.24.x.x[85.24.x.x]...94.254.x.x[94.254.x.x]
Apr 29 16:32:20 R6250 daemon.info charon: 10[CFG] no matching peer config found
It looks like the same issue, the remote endpoint doesnt send the configured ID?
And another question, when using dynamic hostnames instead of IP's as "right", how often does Strongswan make a new DNS-lookup? How does Strongswan handle the situation where let's say the remote endpoint suddenly receives a new IP? Or if the local side receives a new IP during established connection?
Den 2017-04-29 kl. 17:28, skrev Noel Kuntze:
> I just tested it with two hosts running strongSwan 5.5.2 and it works just fine.
> This is a problem with the fortigate, which resolves its configured ID to an IP address.
> Try to find a way to turn that off.
>
> Here are the two configurations I used (one with ipsec.conf, one with swanctl.conf). They are functionally identical.
>
> Instead of starting the FQDN in "left" or "right", you can also set "leftallowany" and "rightallowany2".
> There are no such options for swanctl, so adding 0.0.0.0/0 and ::/0 to left and right allows any. It behaves identical.
>
> --- configurations ---
>
> --- legacy ipsec.conf format ---
>
> --- on vms.thermicorp.lan ---
>
> --- ipsec.conf ---
> conn vms-test
> left = %vms.thermicorp.lan
> leftid = vms.thermicorp.lan
> leftauth = psk
> leftsubnet = 172.16.0.2
> right = %thermi-pc.thermicorp.lan
> rightid = thermi-pc.thermicorp.lan
> rightauth = psk
> rightsubnet = 172.16.0.1
> ike = chacha20poly1305-prfsha256-newhope128
> esp = chacha20poly1305-newhope128, chacha20poly1305
> keyexchange = ikev2
> auto = add
>
> --- ipsec.secrets ---
>
> thermi-pc.thermicorp.lan : PSK test123
>
> --- on thermi-pc.thermicorp.lan ---
>
> None, used equivalent swanctl.conf configuration.
> You could just use the configuration from vms.thermicorp.lan, because the peer could figure out
> that his side is "right" now, when the FQDN defined in "right" resolves to a local IP.
>
> --- modern swanctl.conf format ---
>
> --- on vms.thermicorp.lan ---
>
> --- swanctl.conf ---
>
> connections {
> vms-test {
> version = 2
> remote_addrs = thermi-pc.thermicorp.lan
> local_addrs = vms.thermicorp.lan
> local {
> auth = psk
> id = vms.thermicorp.lan
> }
> remote {
> auth = psk
> id = thermi-pc.thermicorp.lan
> }
> children {
> vms-test-esp {
> local_ts = 172.16.0.2
> remote_ts = 172.16.0.1
> esp_proposals = chacha20poly1305-newhope128, chacha20poly1305
> }
> }
> }
> }
>
> secrets {
> ike-vms-test {
> id = thermi-pc.thermicorp.lan
> secret = test123
> }
> }
>
> --- on thermi-pc.thermicorp.lan ---
>
> --- swanctl.conf ---
>
> connections {
> vms-test {
> version = 2
> local_addrs = thermi-pc.thermicorp.lan, %any
> remote_addrs = vms.thermicorp.lan, %any
> proposals = chacha20poly1305-prfsha256-newhope128
> local {
> auth = psk
> id = thermi-pc.thermicorp.lan
> }
> remote {
> auth = psk
> id = vms.thermicorp.lan
> }
> children {
> vms-test-esp {
> local_ts = 172.16.0.1
> remote_ts = 172.16.0.2
> esp_proposals = chacha20poly1305-newhope128, chacha20poly1305
> }
> }
> }
> }
>
> secrets {
> ike-vms-test {
> id = vms.thermicorp.lan
> secret = test123
> }
> }
>
>
> --- Logs ---
>
> Attached.
>
>
> On 29.04.2017 14:29, Dusan Ilic wrote:
>> For the Fortigate connection if I add in both locla and remote ID, instead of only remote ID, i get the following:
>>
>> authentication of '85.230.x.x' with pre-shared key successful
>> constraint check failed: identity 'remote.example' required
>> selected peer config 'site2site' inacceptable: constraint checking failed
>> no alternative config found
>>
>> Only remote ID as you suggested
>>
>> parsed IKE_AUTH response 1 [ IDr AUTH SA TSi TSr ]
>> no shared key found for 'local.example' - '85.230.x.x'
>> generating INFORMATIONAL request 2 [ N(AUTH_FAILED) ]
>>
>>
>> Den 2017-04-29 kl. 13:26, skrev Dusan Ilic:
>>> no shared key found for 'local.example' - '137.135.x.x'
>>> generating INFORMATIONAL request 2 [ N(AUTH_FAILED) ]
>>>
>>> The remote side is a Fortigate firewall, so I can't configure it the same. I can just choose local interface (ie wan) and remote gateway IP or Dynamic DNS, I have chosen Dynamic DNS.
>>> It logs "peer SA proposal not match local policy".
>>>
>>> If I change to IP adresses it works, but that won't work for very long unfortunately.
>>>
>>>
>>> Den 2017-04-29 kl. 02:49, skrev Noel Kuntze:
>>>> Hello Dusan,
>>>>
>>>> On 29.04.2017 02:25, Dusan Ilic wrote:
>>>>> Hi Noel,
>>>>>
>>>>> Okey, if I don't set "left" and initiate the connection it takes the wrong route (multiple WAN-interfaces) and the remote peer don't expect that source IP. Probably works better if the remote peer is initiating connection instead.
>>>>>
>>>>> If I set "left=%local.example" and "right" / "rightid" as you suggest I get the following output n logfile:
>>>>>
>>>>> Apr 29 00:10:51 R6250 daemon.info charon: 10[IKE] tried 1 shared key for 'local.example' - '137.135.x.x', but MAC mismatched
>>>>> Apr 29 00:10:51 R6250 daemon.info charon: 10[ENC] generating INFORMATIONAL request 2 [ N(AUTH_FAILED) ]
>>>>>
>>>>> If i fiddle in ipsec.secrets a bit, i get this instead:
>>>>>
>>>>> authentication of '137.135.x.x' with pre-shared key successful
>>>>> constraint check failed: identity 'remote.example' required
>>>>> selected peer config 'site2site' inacceptable: constraint checking failed
>>>>> no alternative config found
>>>>>
>>>> Alright. Try the following
>>>> left=%local.example
>>>> leftid=local.example
>>>> right=%remote.example
>>>> rightid=remote.example
>>>>
>>>> remote.example : PSK "PSKGOESHERE"
>>>>
>>>> Do it vice versa on the remote peer.
>>>>
>>>> Kind regards,
>>>> Noel
>>>>
More information about the Users
mailing list