Hi, i do apologies for this second post, somewhat its kinder related.
I was able to configure Static routing as per Martynas’s response - thank you kindly.
Now the router can route its LAN traffic through to my Windows SSTP VPN on 192.168.2.X and all other traffic on its cellular network, further to that I can access the Windows network in the same subnet - all ok.
The follow-up question is and Im having some hard time figuring it out is how can my Windows SSTP Server access the connected devices on the Teltonika Router on its LAN as 192.168.100.x subnet?
From the Windows Server - I can ping the router 192.168.2.191 - screenshot attached.
I knows its something to do with the Windows Static routing - but im not sure.
And I know its related to the Teltonika’s Masquerading settings..
Just to clarify, is 192.168.2.X the LAN IP subnet of your Windows Server hosting the SSTP VPN? I’ll also assume that from the 192.168.100.0/24 network you’re currently able to reach the 192.168.2.0/24 subnet via the SSTP VPN.
If your main goal is for the Windows Server to be able to access devices in the 192.168.100.0/24 subnet behind the router, then yes, you’ll need to add a static route on the Windows Server side to direct traffic to 192.168.100.0/24 via the Teltonika’s SSTP IP (192.168.2.191). You can do this with the following command:
After testing and confirming that it works, you can make the route persistent across reboots by adding -p before add:
If this still doesn’t resolve the issue, try disabling NAT masquerading on the SSTP zone (in Network → Firewall → Zones settings). At the moment, all packets from 192.168.100.X are likely masqueraded as 192.168.2.191 when leaving via SSTP, which breaks the return path routing if the Windows Server tries to reply directly to a 192.168.100.X address.
Alternatively, if the previous suggestion doesn’t work, you can try adding a static route (Network → Routing → Static Routes) on the router to the 192.168.2.0/24 network (target) via 192.168.2.191 (gateway) for the SSTP interface and disabling masquerading on the firewall’s SSTP zone.
Thank you for the update and sharing additional information.
Can you see the added route in the routing table?
route print | find "192.168.100"
Metrics aren’t very necessary here; for testing, you can use 1 or 100 in RRAS static route config.
However, I’d still suggest adding a route through CMD (as admin) with route add 192.168.100.0 mask 255.255.255.0 192.168.2.191.
For optimal testing, firstly, I’d suggest adding a static route on the server side with masquerading on the SSTP zone disabled (assuming the route is being added properly) and on LAN enabled.
Secondly, metric and MTU in static route on RUT can be left empty. Zone settings, from first glance, look good.
Apologies for the delay. I just wanted to follow up and check if the routing issue still persists. If so, could you please review your router’s firewall zone settings (under Network → Firewall → Zones) and ensure that all traffic policies are set to Accept for both input, output, and forward?
When I use CMD >
route add 192.168.100.0 mask 255.255.255.0 192.168.2.192
then this works however with the persistent value
route -p add 192.168.100.0 mask 255.255.255.0 192.168.2.192 > this does not work after SSTP Server reboot, after some googling, it maybe some issues with RRAS, only best option is add bat file at server reboot in startup folder. https://superuser.com/questions/1250282/routing-table-persistent-route-not-working-windows
