SSTP problem

RouterOS Beginner Basics
1

Hi everybody, newbie here.
I’m trying to get to work a site-to-site SSTP VPN, between a local site I can control (office) and a remote site which I cannot control (customer). So in my local site I can fully access the ISP modem/router and edit the network topology if needed, but I cannot access anything in the remote site, and I have to assume no port is open (except the obvious ones), and I have to assume the remote Mikrotik device is working behind a NAT.

At the moment, I’m using RemoteWinBox to connect from the office PC to the remote Mikrotik, from which I initiate the VPN connection back to my office using my public IP and a port forwarding rule on my ISP modem/router. Then, I connect the VPN from the office back to the customer using the VPN interface address.
In this situation the two routers can see each other, ping works etc, but I still can’t route any traffic from the office LAN to the customer LAN i.e. I cannot ping any device on the remote LAN, neither from the office LAN, nor from the local Mikrotik. I added the routes to the respective bridges so I expect everything should work fine, but for some reason ping doesn’t reach the destination / I don’t receive a response.

Can you please help me solve/troubleshoot my problem? I can post here logs, settings, whatever needed.

Thanks in advance.

2

Up.

3

I solve this by using NAT/masquerade at the local and on the remote SSTP/Mikrotik for the interface going into the remote network.

The problem is that the remote client devices otherwise have to know the path back to your local device. Normally they are not configured for that, and will route to their default gateway only, and as such send the answer for the PING to the internet.

By using NAT/masquerade all requests seem to come from a local device.

The local LAN (192.168.87.0/24) but also incoming SSTP links from my mAP’s (remote access to this TURN service coming in with address 185 and 186) all go out as 192.168.187.1 to the remote site with SSTP address 192.168.187.2
Klembord-2.jpg
The remote Mikrotik is connected to the remote network with NAT and firewall set , just as a WAN port is towards internet. This means that all trafiic sent will come from the local WAN port (=remote LAN) address.
Klembord-4.jpg

In addition of all this I use the webproxy and force all HTTP to use the proxy. This again creates a more local access (not really needed) but has improved the interaction considerably. (There is no caching on disk, but the TCP session reuse of the webproxy apparently helps a lot)

Two hAP Lite as “TURN” server or management sites. The mAP can use either of the hAP Lite to get into the remote site while using a local 192.168.1.2 address.
The masquerades make sure the return path is found by the client devices. This also protects the management environment, together with the default WAN firewall rules in the hEX (DUDE server :slight_smile: )
The SSTP tunnel to the mAP directly is not guaranteed, as on foreign networks the port-forwarding is missing. Therefor the use of the “TURN” function in the hAP Lite’s. Works great!
Klembord-3.jpg

4

Thank you for the answer!
I will try this asap and I’ll let you know if I somehow manage to get this to work :slight_smile:

5

Ok I think I’m making some steps towards the solution. I set the firewall rules as you said both ways, this is the local router (the local network is 192.168.0.0):
local.png
And this is the remote firewall (the remote network is 192.168.1.0), the rule #0 is for the RemoteWinbox service:
remote.png
Now I can ping from each router the devices on the other network (i.e. from the local Mikrotik I can ping all the remote network, and viceversa), BUT I cannot reach the remote network from my local network: I cannot ping 192.168.1.x devices from my PC (which is 192.168.0.202), for example. At the moment I cannot say if I could ping the local network from the remote site, but I guess not.
What could the problem be?
Thank you for the support.

6

I don’t think you can set this both ways. Normally you access from your local network to the remote network with masquerade.

You masquerade the local LAN addresses (192.168.0.202/24) to the SSTP_ address. (Whatever that is)

The remote site receives initiation requests from this SSTP_ address and put them on the remote LAN, masqueraded with the remote LAN port (defined as WAN port in RouterOS) IP address (192.168.1.x/24, whatever address that interface got, might have used DHCP client to get it from the remote LAN)

The SSTP setup is from the remote MT (SSTP_out1) to the local MT. (SSTP server binding).
Communication setup is from the local MT or local LAN (eg your PC) to the remote site. Once the UDP/TCP/ICMP session is established the data flows in both directions. The firewall with the default firewall rules allows answers on an established session, not new sessions, and even due to the NAT used it would not know where to connect to.

This setup is used if you have full control over the local LAN. (eg. use the local MT as default gateway, setting the appropriate routes through the SSTP_)
The remote MT is configured as if it connects to Internet (WAN port) for accessing the remote LAN. (You need a masquerade to that ethernet port, not connected to the bridge!)
The remote MT is not known nor used by any remote device, remote devices need no modification whatsoever. (They see the remote MT as just another client device, in their network)

If you have full control on all devices on the remote site, this could be replaced with a plain routed solution, but then at least the remote devices must route correctly (eg use the remote MT as default gateway. Communication initiation would then be possible in 2 directions.

Think of this. If I drop this remote MT on your network, and get an IP address and are allowed outgoing access to Internet on some ports. I would be “in” your network with access just as any of your local devices. (e.g. My remote network has 3 NAT levels, 3 different firewalls, dynamic CGNAT address, not allowed incoming connection by the provider (4G and satellite) … it doesn’t matter … I’m permanently IN that network from anywhere.)

On your config …

So this is the masquerade needed (but not on SSTP_out1, but the other end of the SSTP tunnel). Setting up two SSTP tunnels in opposite directions is not what I use, and would need careful consideration for having the session following the same in/out path. Firewalls don’t like non-stateful sessions by default). Setting both directions would require a public IP address and port forwarding on both sides. Here the second NAT rules is the one that is used, and the only one that makes sense here.
Klembord-2.jpg
So this is my local setup again … I do manage multiple sites …
.
Klembord-3.jpg
.
Ad this is my internet default route and the the specific route for one of the sites.
.
Klembord-4.jpg

7

Thank you for your patience, it is much appreciated. From what I gather, I cannot do what I want to do by using my ISP router as a gateway, right?

At the moment the network configuration is like so (the local PwrLine is temporary, it was the only device I had at home, and of course there is a switch connecting PCs, ISP, PwrLine)
network.png
I set the firewall rules of the local MT like this. bridge-lan is the only out interface I can set, if I set ether1 it tells me I cannot use a slave interface (same on remote).
local.png
Remote MT firewall has only one rule: masquerade srcnat with bridge-lan as out interface.
Local SSTP server is enabled, remote SSTP server is disabled. Remote client is enabled, and it can connect (it shows in the route table).
It doesn’t work, did I do everything correctly?

Even if I manually set the default GW of my PC to 192.168.0.20 (which should be the scenario you described), it doesn’t work.

Thank you.

8

OK. Step by step.

  1. You make your SSTP tunnel.
    Local MT has SSTP server. It will create a dynamic “SSTP-” interface.
    The remote MT has the SSTP client and initiates the SSTP tunnel. It has a static interface “SSTP-out1”
    The direction of the tunnel has no influence on the traffic. The interfaces names do differ however.

  2. The traffic we send from local to remote through the tunnel will be NAT/masquerade’d.
    So the NAT rule translating the traffic from the local LAN source address 192.168.0.0/24 is needed. The reverse NAT rule for the remote LAN addresses 192.168.1.0/24 should not be there !
    The name of the tunnel interface is not SSTP-out1 at the SSTP server side.
    The second NAT rule (with index <1>) is what you need. The first does nothing (no such interface) , and the third one should not be there.

  3. At the other end, the remote MT, the SSTP interface to the local LAN should be NAT/masquerade’d. Therefor the SSTP-out1 and the remote LAN ports cannot be on the same bridge.
    There are multiple scenarios here. I have taken mine where only one ethernet port is connected to that remote LAN, the others form yet other “remote MT managed LAN”, with other subnets, where the remote MT is the DHCP/DefaultGW/DNS etc server. These other WAN interfaces also have their own connection to the ISP modems. (in failover for the SSTP tunnel) It does not need to be that way.

In my scenario, the corresponding ether port is removed from the bridge and handled as independent L3 network connection, with a DHCP client but without the default route, and a NAT/masquerade rule for that interface (simply done in the default MT config by adding that interface to the WAN interface list. Protection and NAT for this WAN type port will be applied.)

You could keep the ethernet port connected to the bridge. But then that whole bridge is only a client device to the remote LAN, with DHCP client on the bridge, and no DHCP server.

If a port is slave to a bridge, all settings can only be applied to the bridge, and all those ports have no individual settings that differ like IP address or DHCP client or server or whatever.

My remote firewall/NAT setting:
Klembord-2.jpg
With default firewall rules (and some extra rules for the public list). The remote LAN is on ether3.
.
Klembord-3.jpg
Klembord-4.jpg
4 Now we have to get the packet delivered to the remote LAN. Some conditions must be met.
4a: in the local MT a dedicated route via the SSTP tunnel is needed (setting the SSTP client IP address as gateway) for all addresses on the remote site.
4b clients on the local LAN must send their traffic to the local MT. They can define the local MT as default gateway, or get that information from the DHCP server. Or the ISP modem should be configured to send the remote LAN subnets to the local MT. This configuration is not always possible!

(My ISP modem is almost a black box. I run a local LAN on the local MT, and “WAN style” connect this local MT to the ISP modem. As long as I connect from the local MT network, the path is OK, because the local MT is the default gateway for that connection. Otherwise, for the browser , setting explicitly the webproxy of the local MT in the PC browser, is also a way to get on the remote LAN with HTTP/HTTPS.)

  1. The reverse path is no problem. The NAT/masquerades will make all steps on the way back as just simple same subnet connects. There is no need for extra routes and certainly not extra NAT/masquerades.
9

It works! Thank you so much for your support and patience with a newbie :slight_smile:

I still have to try some more things to another remote site, but I guess it’s all ok now. In this situation I can connect since the two networks are different (the remote is 192.168.1.0 and the local is 192.168.0.0), but let’s say also the remote is 192.168.0.0, will problems arise? Can I solve them simply by using an EoIP tunnel?

Thank you again.

10

OK great!

I would not use EoIP tunnel for the same network subnet in LOcal and Remote. This is quite strong integration and a totally different approach.

For the same subnets: I would just change my local subnet to something unique. That’s the most pratical way of working, and easy to manage.

If that is not possible …

Accessing identical IP addresses is possible, but it’s not that simple. (e.g. Could happen with a set of identical fixed IP devices). http://forum.mikrotik.com/t/access-multiple-devices-with-same-ip-address/106788/1 .
This is complex, not?
Your case is somewhat simpler as multiple MT routers are involved. (no routing marks and routing tables needed)
Basic principe is that from the local MT point of view the IP subnets are logical and correctly unique for the IP routing.
Then you do a “dstnat” netmap (https://wiki.mikrotik.com/wiki/Manual:IP/Firewall/NAT#1:1_mapping) at the remote MT towards the real subnet there.
DSTNAT could be relative simple if there is only one subnet. Could be a major task if a remote site is complex , with multiple subnets and it’s own routing. (My remote site has 10 subnets)
EG in the local MT use 192.168.17.0/24 for your first remote site, use 192.168.18.0/24 for your second remote site. You use those addresses to address the remote devices.
This will make the connection use the proper SSTP tunnel. The remote netmap DSTNAT will convert those intermediate addresses to the real local ones..

(Heh, I have not used netmap yet myself ! Untested !)

11

Actually I don’t see any complex subnet in the remote sites, the sites I have to manage will be fairly simple I believe (SOHO scenario basically), so I think dstnat might just work :slight_smile: I’ll try it as soon as I can, I’ll let you know if it works.

Thank you!