[strongSwan] Strongswan internal DNS-resolution

[Noel Kuntze]

Seems like it. 

On 22.07.2017 11:17, Dusan Ilic wrote:
> Hi Noel,
> 
> So, are you saying that there is no way to make Strongswan aware of a domain name have changed IP-address without restarting it manually?
> 
> 
> Den 2017-07-22 kl. 01:49, skrev Noel Kuntze:
>> Hi Dusan,
>>
>> I took a "quick" look at the code[1] and it seems the DNS names are only resolved once the result replaces the original destination.
>> So it has nothing to do with caching. Just with a disadvantageous design decision.
>>
>> Kind regards
>>
>> Noel
>>
>> [1] https://github.com/strongswan/strongswan/blob/master/src/libcharon/sa/ike_sa.c#L1470
>>
>> On 21.07.2017 00:19, Dusan Ilic wrote:
>>> Okey, so I just did a forced release/renew on the same endpoint, dynamic DNS updated shortly the new IP (ttl 5 min) and after like 10 min or so another endpoint reconnected again (a fortigate, I have two endpoints), however the troubling endpoint (also strongswan) havent connected yet.
>>>
>>> When logging in to the remote endpoint and pinging the domain name, it resolves to the new IP, but below are the output from both sides of the tunnel when trying to manually run ipsec up-command.
>>>
>>> On the remote endpoint:
>>>
>>> First of, running ipsec statusall connection shows as if the tunnel is still up, maybe thats the problem that Strongswan thinks its up even if it isn't?
>>>
>>> ESTABLISHED 46 minutes ago, 94.254.123.x[local.host.name]...85.24.241.x[85.24.241.x]
>>> IKE SPIs: 1dffaab2cafa2f48_i 15e867fa149370f0_r*, pre-shared key reauthentication in 22 hours
>>> IKE proposal: AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
>>> INSTALLED, TUNNEL, ESP SPIs: cf0473a2_i c45028cb_o
>>> AES_CBC_128/HMAC_SHA1_96, 8275 bytes_i (2616s ago), 81235 bytes_o (8s ago), rekeying in 7 hours
>>> 192.168.1.0/24 === 10.1.1.0/26
>>>
>>> Command ipsec up connection
>>>
>>> initiating IKE_SA to 85.24.241.x
>>> generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ]
>>> sending packet: from 94.254.123.x[500] to 85.24.241.x[500]
>>> retransmit 1 of request with message ID 0
>>> sending packet: from 94.254.123.x[500] to 85.24.241.x[500]
>>>
>>> On the local endpoint (with new IP):
>>>
>>> initiating IKE_SA to 94.254.123.x
>>> generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
>>> sending packet: from 85.24.244.x[500] to 94.254.123.x[500] (464 bytes)
>>> received packet: from 94.254.123.x[500] to 85.24.244.x[500] (36 bytes)
>>> parsed IKE_SA_INIT response 0 [ N(NO_PROP) ]
>>> received NO_PROPOSAL_CHOSEN notify error
>>> establishing connection 'wesafe' failed
>>>
>>> And when restarting Strongswan on the remote endpoint, it connects again...
>>>
>>> Den 2017-07-20 kl. 12:00, skrev Dusan Ilic:
>>>> Hi,
>>>>
>>>> I have some issues with a site to site tunnel with two dynamic endpoints. One side almost never changes IP-adress (it is DHCP however), the other side changes more frequently. Both endpoints IP-adresses are using dynamic DNS and have a corresponding domain name associated at all times.
>>>>
>>>> Today one side changed IP, and the new IP have been updated in public DNS. I understand DNS propagation and caching, but I seem to not understand how Strongswan handles and acts upon it.
>>>>
>>>> For example, I have set keyingtries to %forever on both sides, so that they continuesly tries to reconnect when connections is lost. I have also changed the global initiation parameter from default 0 to 60 s, so that it retries unsuccesful connections attempts.
>>>> Now the other side is trying to reconnect to the old IP still, however if I ping the hostname from that endpoint it resolves to the new, correct IP. It seems like Strongswan is caching the old DNS some how?
>>>> At last I tried to restart Strongswan and then it picked up the new IP.
>>>>
>>>> I would like to have a system that solves this by itself, so I don't need to manually have to intervene each and everythime any of the endpoints get a new IP. How can this best be achieved?
>>>>
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.strongswan.org/pipermail/users/attachments/20170722/77de43e7/attachment.sig>