Problem accessing Tomato WEB Admin

HEllo, I'm using Tomato 1.28 Shibby's release, i managed to set up a openvpn server, and everything works fine except accesing Admin web gui throuth ip given by the vpn.

This is bassically how it looks like. Whem i'm trying to access Tomato which is vpn server through WAN ip, everyting is fine , but when i try to access web admin gui ising vpn ip which is 192.100.50.1 i get connection refused, same thing when i try to access tomato on vpn client 192.100.50.6. Remote access on both routers is enabled and set to port 8080.

Yes, but i need to access Tomato Web interface from completly different network, that's way a set up a openvpn server and connected router which is behind nat as a vpn client. All other services like telnet or ssh works fine, except web gui

Yes, but i need to access Tomato Web interface from completly different network, that's way a set up a openvpn server and connected router which is behind nat as a vpn client. All other services like telnet or ssh works fine, except web gui

Click to expand...

Did you find a way around this issue? I am looking for the same thing.

The reason this doesn’t work is because you’re creating a contradictory routing situation.

Let’s assume the VPN client of the router is NOT the default gateway, but instead the WAN remains the default gateway. So a remote client from the internet enters the router via the VPN. You might believe that because you entered via the VPN that you must necessarily return via that same network interface, and you’d be WRONG!

Connection tracking and the routing system are completely independent. The ONLY thing the routing system cares about is what the routing table(s) tell it to do. And if that routing system is configured such that all unknown IP addresses are to be routed out the WAN, that’s exactly what it’s gonna do! It couldn’t care less that you entered via the VPN.

The exact same thing happens if you make the VPN the default gateway and you enter via the WAN.
Now in a perfect world, this wouldn’t really matter since packets are routinely rerouted across the internet. The problem is that many routers/ISPs treat reply packets for which they can’t associate a corresponding request packet as spoofed, and drop them (aka rp_filter'ing).

There are ways to work around it. One is to entirely exclude an IP (or IPs) from the default gateway using an alternate routing table. Another is to add static routes for the source IP(s) you intend to access from remotely (obviously that’s only going to work if you know that ahead of time, which is not always possible). But if you can, static routes basically act as overrides since a more specific route is always preferred over a more general route (w/ the default gateway being “the” most general). With more effort, you could even exclude IP(s) based on specific ports as well (iow, for specific services).