Hi Community,
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.
sstp-tunnels timing out
Last edited by latitude on Wed Mar 05, 2014 5:51 pm, edited 1 time in total.
Re: sstp-tunnels timing out
are you sure this is not related to the following?
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."Encryption negotiation rejected”
Re: sstp-tunnels timing out
Thanks for your feedback !
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.
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.
Re: sstp-tunnels timing out
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.
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.
-
-
mariosserhan
just joined
- Posts: 3
- Joined:
Re: sstp-tunnels timing out
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).
A work around would be more than welcome.
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).
A work around would be more than welcome.
-
-
mariosserhan
just joined
- Posts: 3
- Joined:
Re: sstp-tunnels timing out
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.
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.
Re: sstp-tunnels timing out
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.
-
-
mariosserhan
just joined
- Posts: 3
- Joined:
Re: sstp-tunnels timing out
Sorry for the double post (first post).
Downgraded to 6.7 and everything is ok, this a production environment so i want it as stable as possible.
Downgraded to 6.7 and everything is ok, this a production environment so i want it as stable as possible.
Re: sstp-tunnels timing out
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.
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.
Re: sstp-tunnels timing out
I have the same issue. When I downgrade to 6.7, all troubles gone away.
RB450G
RB750G
RB433AH
RB750
RB450G
RB750G
RB433AH
RB750
Re: sstp-tunnels timing out
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).
-
-
Disassembler
just joined
- Posts: 9
- Joined:
Re: sstp-tunnels timing out
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.
Client on ROS 6.13 with server on ROS 6.7
Client on ROS 6.13 with server on ROS 6.13 (or any other from 6.8 above)
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.
Client on ROS 6.13 with server on ROS 6.7
Code: Select all
Client (ROS 6.13):
08:48:29 sstp,packet SSTP: sstp-out2 sent control packet type: echo request
08:48:29 sstp,packet SSTP: 10 01 00 08 00 08 00 00
08:48:29 sstp,packet SSTP: sstp-out2 recv control packet type: echo response
08:48:29 sstp,packet SSTP: 10 01 00 08 00 09 00 00
08:48:29 sstp,packet SSTP: sstp-out2 recv control packet type: echo request
08:48:29 sstp,packet SSTP: 10 01 00 08 00 08 00 00
08:48:29 sstp,packet SSTP: sstp-out2 sent control packet type: echo response
08:48:29 sstp,packet SSTP: 10 01 00 08 00 09 00 00
Server (ROS 6.7):
08:48:29 sstp,packet SSTP: <sstp-Ouz9j6v1> sent control packet type: echo request
08:48:29 sstp,packet SSTP: 10 01 00 08 00 08 00 00
08:48:29 sstp,packet SSTP: <sstp-Ouz9j6v1> recv control packet type: echo request
08:48:29 sstp,packet SSTP: 10 01 00 08 00 08 00 00
08:48:29 sstp,packet SSTP: <sstp-Ouz9j6v1> sent control packet type: echo response
08:48:29 sstp,packet SSTP: 10 01 00 08 00 09 00 00
08:48:29 sstp,packet SSTP: <sstp-Ouz9j6v1> recv control packet type: echo response
08:48:29 sstp,packet SSTP: 10 01 00 08 00 09 00 00Code: Select all
Client (ROS 6.13):
09:19:15 sstp,packet SSTP: sstp-out2 sent control packet type: echo request
09:19:15 sstp,packet SSTP: 10 01 00 08 00 08 00 00
Server (ROS 6.13):
09:19:15 sstp,packet SSTP: <sstp-Ouz9j6v1> recv control packet type: echo request
09:19:15 sstp,packet SSTP: 10 01 00 08 00 08 00 00
09:19:15 sstp,packet SSTP: <sstp-Ouz9j6v1> sent control packet type: echo response
09:19:15 sstp,packet SSTP: 10 01 00 08 00 09 00 00
09:19:15 sstp,packet SSTP: <sstp-Ouz9j6v1> sent control packet type: echo request
09:19:15 sstp,packet SSTP: 10 01 00 08 00 08 00 00
Re: sstp-tunnels timing out
After upgrade to 6.13 is the issue the same.
Every 60s was sstp connection aborted. send control packet type: abort, no echo response.
After I downgrade, again, to the 6.7 version, sstp echo and response going well, no sstp link drop.
Every 60s was sstp connection aborted. send control packet type: abort, no echo response.
After I downgrade, again, to the 6.7 version, sstp echo and response going well, no sstp link drop.
Re: sstp-tunnels timing out
@Disassembler, liquidcz:
Are you using sstp-server interface bindings on server's side, or do you have dynamic sstp-server interfaces only?
I will do a deeper tests in my environment and if I will be able to capture the issue, I will let it know here and to support, too.
Are you using sstp-server interface bindings on server's side, or do you have dynamic sstp-server interfaces only?
I will do a deeper tests in my environment and if I will be able to capture the issue, I will let it know here and to support, too.
Re: sstp-tunnels timing out
2DjM: I'm using static sstp-server interface bindings. Thanks.
Re: sstp-tunnels timing out
@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?
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?
Re: sstp-tunnels timing out
@DjM: Not yet, but it is on my ToDo list. 
Re: sstp-tunnels timing out
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 
Re: sstp-tunnels timing out
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
- 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
Re: sstp-tunnels timing out
It seems that we have a good news from MK support team:
So let's wait for version 6.14 and then we should be able to close this forum threadThank you for the report. We were able to repeat the issue and fix it. Please wait
for v6.14 release.
Re: sstp-tunnels timing out
@liquidcz:
K+1?
I have tested the 6.14rc6 in my lab environment and based on first tests with SSTP I'm not able to replicate the SSTP timing out issue, so it seems that it was really fixed.
So the final result is probably: SSTP is broken in ROS 6.8 - 6.13 (including), if there is sstp-server interface binding used.
K+1?
I have tested the 6.14rc6 in my lab environment and based on first tests with SSTP I'm not able to replicate the SSTP timing out issue, so it seems that it was really fixed.
So the final result is probably: SSTP is broken in ROS 6.8 - 6.13 (including), if there is sstp-server interface binding used.
Who is online
Users browsing this forum: Bing [Bot], godel0914 and 79 guests