we are facing a strange behaviour with sstp-tunnels here with V6.7 and V6.10
Local device is OgmaConnect, remote devices are RB750G.
Initial staus: No sstp session is established.
We now set up sstp-sessions from the remote devices A and B. Both tunnels are stable. So far - so good.
After we interrupt one of the tunnels it recovers but starts toggling due to keepalive/inactivity timeouts. The other sstp-session meanwhile remains stable. Fault analysis showed that the echo-request from the local site (Ogma) does not arrive at the remote site and causes timeout then. The log at the local site says that the echo-reuest was sent but it seems to be “swallowed” by the local Ogma. Same applies vice versa to the echo-request being sent from the remote site. The logfile at the local site says that it was answered but the answer does not arrive at the remote site. A packet capture is indicating that no TLS packet was sent out from the local site.
We also checked the firewall settings but could not find any indication - at the initial setup both tunnels are working stable exchanging their echo-request/response.
Problem can be reproduced with two or more sstp-sessions and starts after the first tunnel is interrupted and re-established.
Has anybody experienced this also ? Any help is welcome - also how to further analyse the issue locally.
are you sure this is not related to the following?
"Encryption negotiation rejected”
This is a > SSTP > configuration error, not a bug. Please check your config. I see several people with this config mistake. For the PPP profile that you use in SSTP, turn off encryption, this setting is only used for PPTP. If you have enabled encryption in the PPP profile and use it for SSTP, you will get this error.
Dont’t think that this is the reason. We do not see that encryption error message. Tunnel comes up and remains active for 60s till the keepalive timeout is triggered at the remote site. Local site reports “sstp terminated by remote peer” then.
But will re-test this anyway with the suggested config.
I was able to built up a test-environment with three RB750G (all in the same subnet, all with V6.10). One acting as local device, two as remote devices setting up sstp-connections to the local one.
Result: I tried several PPP-profile settings locally and remote with almost every option (incl. encryption) deativated. The behaviour persisted as described above. After interrupting a sstp-session the connections recovers but starts toggling after 60s or 120s as an inactivity timeout is triggered at the remote side. Then i downgraded the local device to 5.26 (remote devices remained on 6.10) and i was not able to re-produce the sstp-timeout with this setup anymore. After Upgrading the local device back to 6.10 without changing any profile settings the timeout behaviour became re-producable again.
same problem here, i am in need of creating an SSTP VPN server with more than 20 clients.
The first connection is OK and lasts for days any extra connection lasts exactly 120s with the client reporting “reminating…- conn timeout”.
The fact that my config is very simple proves that is not a firewall issue (no rules at all).
Same problem here,
I am trying to built up a topology of an SSTP VPN Server with more than 20 clients,
the first one will be stable for days the next one will throw “terminating…- conn. timeout” every exactly 120s.
I am struggling all day with no luck, my config is simple with no firewall rules so the problem probably is not there.
What could ease your pain is to increase the Keepalive-Timeout on both (!) sstp client and server since this value is triggering the timeout that tears down the tunnel. Default value is 60s which causes the 120s for the timeout.
I’m having the same issues with “negotiation timeout” in SSTP VPNs.
Used RBs:
RB951Ui-2HnD
RB433UAH
RB750
ROS version:
6.12 - issue is ongoing
6.7 - no issues with SSTP VPNs
There was no configuration change before and after upgrading from 6.7 to 6.12 . I have already created [Ticket#2014051266000793] and provided support data.
@latitude:
Have you already created a ticket to support@mikrotik.com and provided requested details from them? As you created a lab environment with this issue, as you have mentioned, it should be a good place for troubleshooting for MK support team, I think.
It seems that 6.13 has fixed the issue with SSTP timing out. Based on my tests the issue was connected with sstp-server interface bindings, after upgrade from 6.12 to 6.13 check you firewall rules, where sstp-server interface bindings were used, as they was marked as invalid after upgrade (disable + enable will fix the issue).
No improvement with 6.13 on my side.
Seems like there is some problem with sending ICMP keepalives from server side.
Weirdest thing is, that it exhibits this behavior only on like 5 to 10 clients from 100. I have even tried to factory reset few of them and set the tunnels from scratch, which works for a while, but after restart or two, it starts to time-out again.
@liquidcz:
Thank you for answer. In this case we are having a similar scenario where the issue is visible.
I was also able to get this issue ongoing also with version 6.13, so I will try to repeat it and send support information to MK support. Have you already provided information to MK support?
I was able to capture the issue between ROS 6.13 – ROS 6.13, I have generated a support files and send to MK support via [Ticket#2014051266000793], let’s see if it will move forward
Same problem. Since RouterOS 6.7 SSTP doesn´t work right for several reasons:
If using NPS (Windows Server 2008 R2) and you force encryption, SSTP tunnels are affected so you must permit no encryption to PPTP or another kind of tunnels.
I updated to version 6.12 and L2TP/IPSec tunnel started to shutdown the system with apparently no reason after 10 days working Ok.
Now in 6.13 version the connection drops with no reason and the Windows 7 client looks like connected.
Lately it seems that secure tunnels are not RouterOS friendly
