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? >> >
signature.asc
Description: OpenPGP digital signature
