Hello,
since upgrading to RUTX_R_00.07.14_WEBUI I can’t connect to the device anymore after a couple successful connections have been made via the L2TP:
9165 Sun Apr 27 17:23:59 2025 daemon.notice xl2tpd[12667]: Connection established to 46.xxx.yyy.z7, 65078. Local: 35212, Remote: 168 (ref=0/0). LNS session is ‘default’
9166 Sun Apr 27 17:23:59 2025 daemon.info xl2tpd[12667]: call_close: Call 17421 to 46.xxx.yyy.z7, disconnected
9167 Sun Apr 27 17:23:59 2025 daemon.debug xl2tpd[12667]: control_finish: Out of IP addresses on tunnel 168!
w9185 Sun Apr 27 17:24:22 2025 daemon.debug xl2tpd[12667]: Unable to deliver closing message for tunnel 53494. Destroying anyway.
There seems to be some issue since trying to do something ssh’ed @ CLI gives this:
root@RUTX11:~# /etc/init.d/xl2tpd start
/etc/rc.common: eval: line 39: ipsec: not found
There certainly isn’t a issue with IPs, there are 5 clients with 10-addresses long pool!
I’ve obtained a second device and this happened once a few connections were made as well L2TP becomes unusable – downgrading to previous version seems to resolve the problem.
Primary device is in remote location and downgrading the firmware there is not an option. Is there any solution, please?
RUTX50
everything worked before (RUTX_R_00.07.13.4) and today after the update (RUTX_R_00.07.14.2) I can’t connect to the L2TP/IPSEC server.
In the logs there is information:
1912 Sun May 11 23:13:19 2025 daemon.notice xl2tpd[12308]: Connection established to 213.19.16.123, 1701. Local: 6302, Remote: 23 (ref=0/0). LNS session is ‘default’
1913 Sun May 11 23:13:19 2025 daemon.debug xl2tpd[12308]: check_control: Received out of order control packet on tunnel 23 (got 3, expected 2)
1914 Sun May 11 23:13:19 2025 daemon.debug xl2tpd[12308]: handle_control: bad control packet!
1915 Sun May 11 23:13:19 2025 daemon.info xl2tpd[12308]: call_close: Call 4635 to 213.19.16.123 disconnected
1916 Sun May 11 23:13:19 2025 daemon.debug xl2tpd[12308]: control_finish: Out of IP addresses on tunnel 23!
2003 Sun May 11 23:13:31 2025 daemon.debug xl2tpd[12308]: control_finish: Peer requested call 1 twice, ignoring second one.
I can’t connect anymore to the firewall after upgrading to RUTX_R_00.07.14.2 from remote side in IPSEC VPN Tunnel. Anyone found the problem ? I can ping it but cannot access webpage. On local side everything is ok
I just found this: If i disable “Port Scan” in Network - Firewall - Attack Prevention im able to connect from remote side to the firewall web page on IPSEC Tunnel. Can someone test this
Our R&D is aware of it and already addressed this L2TP over IPsec issue (with FW 7.14). The resolution for it will be in the next 7.14.3 RutOS release.
Gentlemen, but such basic services should be verified before a patch is issued.
I have a dozen or so devices that are now lying around and people can’t work.
Yes this is not the first time that important bug like this happen. Im also having problem with pinging device over the IPSEC Tunnel. We have a lot of email alert saying that the firewall or any other device behind the Teltonika firewall are down since upgrading to this version. ANy info on that ?
Ive update to firmware 7.14.3 and over IPSEC VPN im still having issue with the https WEBUI page. It take long time to load the page and sometime i have error like this
Could you please confirm whether the initial issue with the L2TP over IPsec tunnel is now working properly? Also, do you still encounter the “Failed to load page: status/Services…” error after trying to refresh the WebUI page, clearing the browser cache, or rebooting the device?
Well the initial issue was alway having trouble accessing webUI over IPSEC tunnel and the issue still persist with firmware 7.14.3. If i access webUI page over WAN and LAN everything is ok. I have 5 differents RUTX08 firewall with site to site and they do all same problem. Ive tried different browser clearing cache and still the same thing
What encryption is used for IPsec? Could you try enabling the “IPsec software flow offload” option found on the Network → Firewall → Settings page, and check if that gives any improvement?
From the first glance, there’s a mismatch between the IPSec Phase 1 and Phase 2 proposals. Also, for testing purposes, leave the “Hardware flow offloading” in Firewall → Settings enabled.
Furthermore, could you check the Network → Firewall → Attack Prevention page on the device? It’s possible that HTTP or HTTPS flood prevention settings are enabled there; if so, disable them and leave only the single SYN flood enabled.
