hello. I got weird problem with Windows 10 PC and SSTP server on MikroTik router.
Good scenario: PC1 (win10) on Internet can access PC2 (win10) behind MikroTik, when Remote Desktop or Remote Admin ports are NAT-ed from MikroTik Public IP to IP of PC2.
Bad scenario: SSTP client on PC1 connected to SSTP MikroTik server, can ping PC2, unable to establish RD or RA session to PC2. Also it seems no TCP session can be established from PC1 to PC2.
Completely weird thing: If in place of PC2 I put PC3 with Win7 - no problem.
I did default reset of MikroTik, I did turn of firewall on PC2, reinstall netcard on PC2, reset IP stack on PC2, etc. No results.
This problem happened due this 2018 new year period. Up to November 2017 we was using sstp and Windows 10 just fine.
I am not asking how to run basic MikroTik stuff like SSTP VPN, firewall or NAT, but may me you can give me an idea what possibly happened here.
Here is Wireshark capture of failed attempt to start Remote Admin session via SSTP.
10.1.3.69 - SSTP Client, 10.1.1.51 - PC2 with Windows 10 (latest version and all updates) ,MikroTik SSTP server IP: 10.1.3.254, MikroTik LAN IP: 10.1.1.250
Please, help, I’m going crazy…
Client sends SYN and server sends back SYN,ACK. But client sends SYN again, so it looks like it didn’t receive the first SYN,ACK. If that screenshot is from server, then look where exactly the SYN,ACK gets lost (logging rules on MikroTik router can help you). If the screenshot is from client, then it’s really strange, because it clearly received SYN,ACK (it could still be dropped by client’s firewall, but since it’s reply for connection originated from client, it would be very unusual firewall config).
sorry, forget to mention: wireshark log was taken on PC2 - Remote Admin server.
attached capture made on MikroTik when SSTP Client PC1 tried to connect to PC2 with RAdmin.
PC1 10.1.3.69 Radmin Client → PC2 10.1.1.51 RAdmin Server
I don’t have any magic solution, but it’s clear what should happen. SYN packet to server comes correctly, we know that. Next step is SYN,ACK which is sent back to client. It must:
- leave the server
- arrive to router’s LAN interface
- leave router via VPN tunnel to client
- arrive to client’s interface
- pass through firewall and be accepted by application
So right now we’re at 2) or 3), depending on where exactly is your latest capture from. Step 4) can be done with packet sniffer on client. Step 5) will be ok if client continues further with communication.
What seems a little strange is that those three initial SYN packets are perhaps a little too fast.
Latest capture was done on router. TCP out of order - is it ok for first packet was was intended to start tcp session?
That’s not a precise enough indication. When any packet passes through the Mikrotik, it passes through at least two interfaces, the physical one through which it gets in and the physical one through which it gets out, and is captured (sniffed) at both unless you specify a particular (list of) interface(s) to sniff at. And as Mikrotik uses pcap format when sniffing, there is no way to tell at which interface a particular packet in the file has been captured.
So it is most likely that the triplets of packets just hundreds of microseconds apart are actually the same packet captured at different interfaces. So I’d recommend you to sniff once again and indicate the interface closest to the client, which should be the SSTP server virtual interface if I understand your scenario right. My assumption is that there is a bridge on the LAN side, so you capure the packet once at the physical etherner, second time on the bridge, and third time on the SSTP server virtual interface.
TCP out of order - is it ok for first packet was was intended to start tcp session?
I’m afraid that, as said above, there is actually no real packet out of order because the second and third packets in each burst are there only due to the sniffing configuration. But Wireshark has no information allowing it to identify that situation.
Given that you can ping the PC2 from PC1 via the SSTP tunnel but cannot establish a TCP connection, and according to the capture PC2 does answer, I would expect the SSTP tunnel to have some trouble delivering the ****
SYN,ACK
answer of PC2 to PC1, or PC1 has some problem to receive it.
The ****
SYN,ACK
packet is so small that it cannot be a MTU issue (unless you have done something really ugly). So I would try to sniff one more time, at the SSTP server virtual interface and at the internet-facing interface, to see whether the plaintext ****
SYN,ACK
packet from PC2 is followed by an encrypted packet from the Mikrotik’s WAN address to the public address behind which the PC1 is (most likely) NATed. Just don’t be surprised if the encrypted packet seems to be sent before the plaintext one, there used to be some issue with timestamping on Mikrotik and I don’t know whether it has already been fixed.
Based on the result (use display filters to show only the two sessions of interest before posting the picture), we can think further. Also, the same capture with PC3 instead of PC2 would be a good source of information for comparison.
I do not suspect a firewall for two reasons:
- there are three copies of each packet in both directions, which would not be the case if the firewall would prevent the ****
SYN,ACK
from being forwarded via SSTP virtual interface
- you say it works with PC3 instead of PC2, so I assume you use the same IP address for both
I did a rollback from 6.41.3 to 6.40.6 and problem gone!
Congratulations, RouterOS writers, you have +1 bug in new bridge implementation, as I think. As I wrote in my first post, problem rised about new year, so no doubts, I did upgrade for newest and latest firmware on RB450G unit.
Let me repeat again: This nightmare happened only with Windows 10 PC, what was on same subnet with RB450G. Windows 7 PC in the same local subnet has no problem with RAdmin connection from sstp client. In all tests, sstp client was Windows 10 PC. But at same time, Windows 8.1 sstp client was unable to connect to routed http sites, what can be reached through MikroTik sstp server. Nightmare…
Here is my last trace on RB450G fw 6.41.3 client sstp interface:
10.1.3.69 - Remote PC1 (Sstp Client)
10.1.1.51 - Local PC2 (RAdmin server)
Please don’t forget to send the information also to support@mikrotik.com, I’m not sure they manage to read every topic in the forum.