OK. Step by step.
1. You make your SSTP tunnel.
Local MT has SSTP server. It will create a dynamic "SSTP-<username>" 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.)
5. 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.
You do not have the required permissions to view the files attached to this post.