SSTP Tunnel from MikroTik to SoftEther – Routing to Remote LAN Fails (Packets Not Reaching Client)
Posted: Tue Jul 15, 2025 10:29 am
Hello,
I'm currently working on a setup where a MikroTik router connects to a SoftEther VPN server using an SSTP tunnel. The connection is successfully established, and both ends of the tunnel can ping each other.
✅ Topology Overview:
VPN Server (SoftEther)
Virtual Hub mode: Bridge (Local Bridge is configured)
IP in tunnel: 10.100.100.1
Interface: tap_xxx
Route to remote LAN: 192.168.1.0/24 via 10.100.100.2 dev tap_xxx
MikroTik (VPN Client)
IP in tunnel: 10.100.100.2
Local LAN: 192.168.1.0/24
SSTP interface: to_Server
NAT and firewall rules are disabled for debugging
🧪 What works:
From the VPN server (10.100.100.1) I can ping the MikroTik endpoint (10.100.100.2) – works fine.
Reverse ping also works.
❌ What Doesn’t Work:
When pinging a device behind MikroTik (e.g. 192.168.1.102) from the VPN server:
The ICMP echo request leaves the server via the tap_xxx interface.
But on the MikroTik side, no RX packets appear on the SSTP interface (checked via sniffer and interface stats).
So, no reply is ever sent — because the request never arrives.
🔍 Troubleshooting Done:
No firewall rules exist on the MikroTik that could block or filter traffic.
MikroTik is in bridge mode, so local LAN and VPN tunnel are bridged.
Server-side routing is correct — the route to 192.168.1.0/24 points to 10.100.100.2.
❗ Problem Summary:
It seems the SoftEther Virtual Hub does not forward traffic that is destined to 192.168.1.0/24 (the client’s local network).
Packets leave the TAP interface on the server but are not received on the SSTP interface of the MikroTik client.
💡 My Assumption:
I suspect the Virtual Hub is only forwarding traffic within the 10.100.100.0/24 tunnel network, and silently drops anything else (e.g. 192.168.x.x).
❓ Questions:
Why does SoftEther not forward this routed traffic properly?
Is there any additional configuration required to allow routed packets through the virtual hub bridge?
Should I be using a Virtual Layer 3 switch instead?
Any insights, suggestions, or corrections would be highly appreciated!
Thank you.
I'm currently working on a setup where a MikroTik router connects to a SoftEther VPN server using an SSTP tunnel. The connection is successfully established, and both ends of the tunnel can ping each other.
✅ Topology Overview:
VPN Server (SoftEther)
Virtual Hub mode: Bridge (Local Bridge is configured)
IP in tunnel: 10.100.100.1
Interface: tap_xxx
Route to remote LAN: 192.168.1.0/24 via 10.100.100.2 dev tap_xxx
MikroTik (VPN Client)
IP in tunnel: 10.100.100.2
Local LAN: 192.168.1.0/24
SSTP interface: to_Server
NAT and firewall rules are disabled for debugging
🧪 What works:
From the VPN server (10.100.100.1) I can ping the MikroTik endpoint (10.100.100.2) – works fine.
Reverse ping also works.
❌ What Doesn’t Work:
When pinging a device behind MikroTik (e.g. 192.168.1.102) from the VPN server:
The ICMP echo request leaves the server via the tap_xxx interface.
But on the MikroTik side, no RX packets appear on the SSTP interface (checked via sniffer and interface stats).
So, no reply is ever sent — because the request never arrives.
🔍 Troubleshooting Done:
No firewall rules exist on the MikroTik that could block or filter traffic.
MikroTik is in bridge mode, so local LAN and VPN tunnel are bridged.
Server-side routing is correct — the route to 192.168.1.0/24 points to 10.100.100.2.
❗ Problem Summary:
It seems the SoftEther Virtual Hub does not forward traffic that is destined to 192.168.1.0/24 (the client’s local network).
Packets leave the TAP interface on the server but are not received on the SSTP interface of the MikroTik client.
💡 My Assumption:
I suspect the Virtual Hub is only forwarding traffic within the 10.100.100.0/24 tunnel network, and silently drops anything else (e.g. 192.168.x.x).
❓ Questions:
Why does SoftEther not forward this routed traffic properly?
Is there any additional configuration required to allow routed packets through the virtual hub bridge?
Should I be using a Virtual Layer 3 switch instead?
Any insights, suggestions, or corrections would be highly appreciated!
Thank you.