VPN Not able to conect

Networking Solutions
1

Hi,
A new error has occured. And I am struggeling figuring out what is going on.

I think we might have a DYNU issue.
But seems it connects.

So logs are the same over and over. peer is not responding.

802 Fri Jun 13 07:34:35 2025 daemon.info ipsec: 07[IKE] <Azure|1> giving up after 3 retransmits
803 Fri Jun 13 07:34:35 2025 daemon.info ipsec: 07[IKE] <Azure|1> peer not responding, trying again (8/0)

Is there somewhere I can see the logs from DYNU on Teltonika? I have been looking, but in the stress, i might have overlooked something.

Now I have lost VPN on all 100 connections. And a sligt panic is hitting.

SW versions:

  • RUT9M_R_00.07.13.1
  • RUT9M_R_00.07.13.2
  • RUT9M_R_00.07.15

HW Versions:

  • RUT951
  • RUT956
  • RUTX50

Does anyone know if there has been a change on DYNU or somewhere that might cause this?

3

Hello,

Thank you for reaching out.

To clarify first:
All IPsec-related logs can be reviewed from Services → VPN → IPsec
(image) on router’s WebUI.

Since it’s difficult to pinpoint the exact cause without full logs, here are a few troubleshooting steps worth checking right away:

  1. Confirm Azure VPN Gateway’s current public IP — if it changed and your DDNS client hasn’t updated or isn’t resolving properly, tunnels won’t re-establish.
  2. Test DNS resolution manually from router CLI:
ping yourvpnname.dynu.net
nslookup yourvpnname.dynu.net

Confirm the resolved IP matches your Azure VPN gateway’s actual public IP.

  1. Restart services from CLI:
/etc/init.d/ddns restart
/etc/init.d/swanctl restart
  1. Check IPsec status after restart via CLI and WebUI:
/etc/init.d/swanctl get_status
  1. If your tunnels attempt to reconnect but still fail, please collect and share the latest full tunnel establishment logs (found in Services → VPN → IPsec Logs:).

Would you mind reviewing these and letting me know what you find? We can then narrow it down further.

Best regards,

4

BusyBox v1.34.1 (2025-06-04 10:34:44 UTC) built-in shell (ash)

| _ \ _ | | / _ / |
| |) | | | | | | | _
| _ <| || | || || |) |
|| _\,|_|__/|____/

Teltonika RUTX series 2025

Device: RUTX50
Kernel: 6.6.87
Firmware: RUTX_R_00.07.15
Build: 18a177b964b
Build date: 2025-06-04 11:59:01

root@RUTX50:~# ping bernhard01.dyn.timepark.customer.parkly.cloud
PING bernhard01.dyn.timepark.customer.parkly.cloud (162.216.242.208): 56 data bytes
64 bytes from 162.216.242.208: seq=0 ttl=41 time=167.472 ms
64 bytes from 162.216.242.208: seq=1 ttl=41 time=167.515 ms
64 bytes from 162.216.242.208: seq=2 ttl=41 time=167.333 ms
64 bytes from 162.216.242.208: seq=3 ttl=41 time=167.313 ms
64 bytes from 162.216.242.208: seq=4 ttl=41 time=167.341 ms
64 bytes from 162.216.242.208: seq=5 ttl=41 time=167.371 ms
64 bytes from 162.216.242.208: seq=6 ttl=41 time=167.289 ms
64 bytes from 162.216.242.208: seq=7 ttl=41 time=167.263 ms
64 bytes from 162.216.242.208: seq=8 ttl=41 time=167.425 ms
^C
— bernhard01.dyn.timepark.customer.parkly.cloud ping statistics —
9 packets transmitted, 9 packets received, 0% packet loss
round-trip min/avg/max = 167.263/167.369/167.515 ms
root@RUTX50:~# nslookup bernhard01.dyn.timepark.customer.parkly.cloud
Server: 127.0.0.1
Address: 127.0.0.1#53

Name: bernhard01.dyn.timepark.customer.parkly.cloud
Address 1: 162.216.242.208
Address 2: 2602:ff23:0:8888::208
root@RUTX50:~#

First glance, seems my suspisions was right, the ip is wrong from DYNU.

5

root@RUTX50:~# /etc/init.d/ddns restart
root@RUTX50:~# /etc/init.d/swanctl restart
root@RUTX50:~# /etc/init.d/swanctl get_status
strongSwan swanctl 5.9.14
uptime: 10 seconds, since Jun 13 08:19:34 2025
worker threads: 16 total, 11 idle, working: 4/0/1/0
job queues: 0/0/0/0
jobs scheduled: 1
IKE_SAs: 1 total, 1 half-open
loaded plugins: charon des sha1 md4 mgf1 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pgp pem openssl pkcs8 xcbc kdf curl kernel-netlink socket-default connmark vici updown eap-identity eap-mschapv2 xauth-generic
Connection list:
Azure: IKEv2, no reauthentication, rekeying every 14400s, dpd delay 30s
local: %any
remote: vpn.timepark.customer.parkly.cloud
local pre-shared key authentication:
id: bernhard01.dyn.timepark.customer.parkly.cloud
remote pre-shared key authentication:
id: vpn.timepark.customer.parkly.cloud
Azure_c: TUNNEL, rekeying every 26181s, dpd action is start
local: 10.30.55.0/24
remote: 10.20.0.0/22
Security Association list:
Azure: #1, CONNECTING, IKEv2, 2a98df91997dbcc7_i* 0000000000000000_r
local ‘%any’ @ 192.168.137.2[500]
remote ‘%any’ @ 51.120.1.165[500]
active: IKE_VENDOR IKE_INIT IKE_NATD IKE_CERT_PRE IKE_AUTH IKE_CERT_POST IKE_CONFIG IKE_AUTH_LIFETIME IKE_MOBIKE IKE_ESTABLISH CHILD_CREATE
root@RUTX50:~#

And then logs from WebUI on IPSEC

IKE:AES_CBC_128/AES_CBC_192/AES_CBC_256/AES_CTR_128/AES_CTR_192/AES_CTR_256/3DES_CBC/HMAC_SHA2_256_128/HMAC_SHA2_384_192/HMAC_SHA2_512_256/HMAC_SHA1_96/AES_XCBC_96/PRF_HMAC_SHA2_256/PRF_HMAC_SHA2_384/PRF_HMAC_SHA2_512/PRF_AES128_XCBC/PRF_HMAC_SHA1/ECP_256/ECP_384/ECP_521/ECP_256_BP/ECP_384_BP/ECP_512_BP/CURVE_25519/CURVE_448/MODP_3072/MODP_4096/MODP_6144/MODP_8192/MODP_2048, IKE:AES_GCM_16_128/AES_GCM_16_192/AES_GCM_16_256/AES_CCM_16_128/AES_CCM_16_192/AES_CCM_16_256/CHACHA20_POLY1305/AES_GCM_12_128/AES_GCM_12_192/AES_GCM_12_256/AES_GCM_8_128/AES_GCM_8_192/AES_GCM_8_256/AES_CCM_12_128/AES_CCM_12_192/AES_CCM_12_256/AES_CCM_8_128/AES_CCM_8_192/AES_CCM_8_256/PRF_HMAC_SHA2_256/PRF_HMAC_SHA2_384/PRF_HMAC_SHA2_512/PRF_AES128_XCBC/PRF_HMAC_SHA1/ECP_256/ECP_384/ECP_521/ECP_256_BP/ECP_384_BP/ECP_512_BP/CURVE_25519/CURVE_448/MODP_3072/MODP_4096/MODP_6144/MODP_8192/MODP_2048
451854 Fri Jun 13 08:21:34 2025 daemon.info ipsec: 14[CFG] <azure|33> sending supported signature hash algorithms: sha256 sha384 sha512 identity
451855 Fri Jun 13 08:21:34 2025 daemon.info ipsec: 14[ENC] <azure|33> 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) ]
451856 Fri Jun 13 08:21:34 2025 daemon.info ipsec: 14[NET] <azure|33> sending packet: from 192.168.138.120[500] to 51.120.1.165[500] (1368 bytes)
451857 Fri Jun 13 08:21:38 2025 daemon.info ipsec: 16[IKE] <azure|33> retransmit 1 of request with message ID 0
451858 Fri Jun 13 08:21:38 2025 daemon.info ipsec: 16[NET] <azure|33> sending packet: from 192.168.138.120[500] to 51.120.1.165[500] (1368 bytes)
451859 Fri Jun 13 08:21:45 2025 daemon.info ipsec: 11[IKE] <azure|33> retransmit 2 of request with message ID 0
451860 Fri Jun 13 08:21:45 2025 daemon.info ipsec: 11[NET] <azure|33> sending packet: from 192.168.138.120[500] to 51.120.1.165[500] (1368 bytes)

6

Hello,

Thank you for the additional information.

It is likely that your primary suspicion is correct. Based on the logs, your DYNU hostname bernhard01.dyn.timepark.customer.parkly.cloud is currently resolving to 162.216.242.208, while your IPsec configuration is attempting to negotiate with 51.120.1.165. Since these don’t match, it indicates one of two likely scenarios:

  • Azure’s public IP has changed, and your DYNU DDNS client didn’t update the record.
    or
  • 51.120.1.165 was manually configured in your IPsec configuration, overriding the DDNS-resolved address.

This essentially points to a DDNS sync issue or a stale A record on DYNU.

To confirm this:

  1. From an external management PC (on a different ISP or network), run:
nslookup vpn.timepark.customer.parkly.cloud

Check whether it resolves to 51.120.1.165 or 162.216.242.208.
2. Then, log in to your Azure portal, and check the current public IP of your VPN gateway.

If Azure shows a different public IP than 162.216.242.208, it confirms that DYNU didn’t receive the updated IP from Azure.

Quick potential workaround/fix:

Manually update the DYNU hostname record via the DYNU portal to reflect the current public IP of your Azure VPN gateway.

Once that’s done, restart the DDNS and IPsec services on your Teltonika device:

/etc/init.d/ddns restart
/etc/init.d/swanctl restart

Then monitor the tunnel logs to confirm it re-establishes successfully.

Let me know how it goes.

Best regards,

7

Ok, I quit my job. Seems that our bill to DYNU was not paid. And by adding my private credit card, the services are now working again. Sorry for wasting everyones time.

8

Thank you for the update and for letting us know; no problem at all.

Similar things happen all the time, nevertheless, the important part is that the issue is resolved and IPsec tunnels are back online.

Feel free to reach out to us if you need any assistance in the future.

Best regards,

9

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.