DNS for VPN

Hi, we have a few web servers behind a WG M300 in a data centre, no users, we have sNATs for the servers web https set on the M300 and DNS in the cloud. Externally thats fine, anyone can access the apps via https. We dont have internal dns servers, all servers use Google DNS.

The developers use WG SSL VPN to login to the local LAN and connect to the servers for maintenance via RDP (split tunnel), if on the server they run the site URL the servers host file resolves to its LAN IP.

Some want to VPN and run URLs internally whilst not on the servers RDP, so that means their PC needs a host file set to LANIP then disconnect SSLVPN run URL again and they have to reset to not using host file as the IP is wrong.

so can I add trusted / any optional or SSL Users goup on the "HTTPs sNAT incoing rule for the public IP", so they can SSL VPN in and use the URL without needing to set host files?

can you add trusted in that way, is it secure?
seems counter intuitive for some reason.

eg https packet filter > 210.56.23.1 sNAT to 192.168.99.100
from any external to snat - then add any trusted / optional as well ?

thanks

Comments

  • Yes, that should work.
    This is called NAT loopback

    NAT Loopback and Static NAT (SNAT)
    https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/nat/nat_loopback_static_c.html

  • edited July 2021

    Thanks Bruce, the assumption on that WG link is that this is a separate internal users packet filter only "nat loopback", which makes sense.

    so in my scenario where i have say 5 web servers all with HTTPS (only) packet filters in place already using e.g.;

    210.56.23.5 > 192.168.99.100 from "any external" to snat
    210.56.23.6 > 192.168.99.101 from any external to snat
    210.56.23.7 > 192.168.99.102 from any external to snat
    etc....

    I should "add" any trusted or optional (as required) to those existing packet filter rules?, or make a new rule for each server just for my internal users, which actually may make sense?

    New Loopback HTTPs
    210.56.23.5 > 192.168.99.100 Loopback from any trusted to same snat
    210.56.23.6 > 192.168.99.101 Loopback from any trusted to same snat
    210.56.23.7 > 192.168.99.102 Loopback from any trusted to same snat

    thanks
    sys345

  • Adding to the existing policies will work just fine.

  • Thanks for the information Bruce

Sign In to comment.