Self-hosted services see external IP address when connected via VPN reddit / selfhosted ---------------------------------------------------------------------- mekaneck84 · 2023-12-02 06:52 My Setup: * Unfi UGS3 gateway running L2TP VPN server. * NGINX Proxy Manager * AdGuard Home * A bunch of Docker containers * A service hosted at `internal.mydomain.com` that has an access control list in NGINX set to allow only 192.168.0.0/16 * A service hosted at `public.mydomain.com` that is accessible by any IP When I am outside my home network and connect via the L2TP VPN, I can see my DNS requests show up in my AdGuard log reflecting my internal VPN IP address (let's say 192.168.10.1). Even though I'm trying to access a self-hosted service, since I'm accessing via `internal.mydomain.com` my DNS resolves my server's public IP. This works, but then blocks the access, and in the log it shows that my IP is my device's public IP (which is a Verizon IP address when I'm testing it via my phone) as opposed to 192.168.10.1. How can I get NGINX (and also the downstream services) to see the internal IP address of 192.168.10.1 instead of the external address (Verizon, in this example)? How is my external address even getting passed along? I should note that when I'm actually inside my network and I visit `internal.mydomain.com` everything works as expected (and my AdGuard DNS is still resolving that address to my server's public IP). And when I'm not on VPN and outside my network and I visit `public- service.mydomain.com` everything works normally also. I considered doing DNS re-writes for all my services, but besides being a pain, I don't have that option because I'm not exposing those ports on my docker containers and I'd rather not do that. (Following this best practice: https://nginxproxymanager.com/advanced- config/#best-practice-use-a-docker-network) ---------------------------------------------------------------------- timothyclaypole · 2023-12-02 07:59 I’m confused about what you are expecting and trying to do here. Start from first principles. You have a vpn, that means your client device has at least two ip addresses and two routes it knows about - one route to the internet via its external Verizon address and one to your home network via its vpn address. (There’s a concept of forcing all traffic through a vpn but it doesn’t sound like that’s what you have setup) If your phone needs to connect to a public ip address it will use the Verizon route to get there. So when your phone resolves the dns name for your host and it gets given a public ip address that’s always going to mean a connection over Verizon. What I think you want is that the internal domain name should resolve to the internal ip address and that way your phone would connect via the vpn. Your actual at home connections should also resolve the internal ip address not the public one, using the public ip address is likely resulting in that traffic hitting your router, the traffic being NATted and then routed to the routers external ip before coming back in again and sent to your server (using the internal ip address of the router, and not the original ip address of the client). Which is all probably not what you want either? ---------------------------------------------------------------------- mekaneck84 · 2023-12-02 15:48 Thanks for your reply! My goal is to be able to use \`internal.mydomain.com\` instead of the port & internal IP address of the service (e.g. \`192.168.1.50:9000\`) whether I’m inside my home network or VPN’d into my home network from outside. And when I’m outside not on VPN I want access to be blocked via the access list on my reverse DNS server (NPM). For \`public.mydomain.com\` I want access in all 3 scenarios. How I have things set up now, it works for clients inside my network and correctly blocks or passes clients outside my home network, as desired. However it is blocking VPN clients from accessing \`internal.mydomain.com\` which is not desired and is what I want to fix. My expectation is that, when my phone is connected to VPN, all phone traffic \*is\* routed through the VPN. I understand the concept of split tunneling and I certainly don’t have anything like that configured on my phone. I’m on an iPhone and have manually configured an L2DP VPN connection and “send all traffic” is checked. No proxy is configured. When my phone is connected to the VPN and I visit a ‘what is my ip address’ website I will see my home’s external IP from my ISP provider (as desired & expected). (This is also the external IP address of my NPM which is my DNS A-record IP since I host from that IP.) I \*don’t\* see my phone’s Verizon IP. So I do believe all traffic is being routed through VPN. Your point about home connections resolving the internal address instead of the external address: I see from my AdGuard DNS logs that it is serving the external IP of my NPM, and so I would agree that from that information alone I would expect traffic is routed outside and then back to my routers external IP. But looking at my NPM logs I’m seeing the client IP is showing as the [192.168.1.1](https://192.168.1.1) even though my device IP is [192.168.1.40](https://192.168.1.40) and my AdGuard DNS server sits at 192.168.2.2 so I’m not clear on what is actually happening. I would love to go through this on first principles but my understanding of routing is clearly poor and is why I'm struggling. If I can figure out the principle of why things are & aren't working I am more than competent to figure out the step-by-step process of implementing a fix. But I'm not clear on what is happening and why. I came across this post which I believe is describing my scenario but neither proposed solution is desirable: [https://www.reddit.com/r/Ubiquiti/comments/xy0k82/comment/irgu9s3/?ut m\_source=share&utm\_medium=web2x&context=3](https://www.reddit.com/r/ Ubiquiti/comments/xy0k82/comment/irgu9s3/?utm_source=share&utm_medium= web2x&context=3) If this thread nosedives, what I probably need to do is start another that simply asks what the proper network & routing configuration is such that a reverse proxy will properly route traffic whether it is internal, external, or internal VPN. If I could understand that setup independent of the specifics of which DNS server and which reverse proxy and which VPN is being used, then I could easily figure out the implementation for my specific scenario. ---------------------------------------------------------------------- timothyclaypole · 2023-12-02 16:33 What I think you need to lookup is split horizon DNS - that would allow you to use the same DNS name but it would resolve to different ip addresses depending on if you are inside your network or outside it (inclusing being inside via VPN). The 192.168.1.1 ip address will be the internal ip address of your router. If it helps you should try to think about routing and ip addresses separately from how you think about DNS. DNS is simply a translation from something that’s human compatible to something that’s mostly only what a machine wants to know. If we didn’t have DNS we would have to remember hundreds of different IP addresses, humans aren’t good at that so we invented dns to allow us to remember something we are pretty good at - “names”. Routing on the other hand is entirely something that machines do and routing has (mostly) nothing to do with the names we have decided to put into DNS. Your client (phone) asks DNS “hey what’s the ip address of the host called name?” And DNS returns an answer. Your phone then makes a separate connection to the ip address that your dns server provided - the dns server itself is not involved in that connection. Once it gives you the ip address its job is done. In your case with the way you have this setup your phone is trying to connect to an external ip address even when it’s inside your network so the phone is looking at its route table and it sees that it can communicate to anything on network 182.168.1.0 directly but to get anywhere else it needs to talk to your router on 192.168.1.1 Your router is then doing what it’s supposed to - often routers are configured to stop this kind of loop back traffic, after all typically we don’t want traffic to unnecessarily go through the router and back inside again - that’s just wasteful. I still think the correct solution here is to get your internal stuff setup so that the internal ip address is used for all your internal networking and then get the von connections to use the same internal dns translation and then “local” routing. That way you won’t even need the real public connection option (at least not unless you do decide to explicitly white list certain ip addresses). With split horizon dns your internal dns servers (adguard?) would return the internal ip address and you would have the exact same name registered with a real public dns service that would return the public ip address for any truly external clients. ---------------------------------------------------------------------- mekaneck84 · 2023-12-02 18:04 OK I did some research of split horizon DNS, thank you for that. In my case I think every client served by my DNS (AdGuard) is an internal client, so I don't necessarily need split horizon, I just need to resolve *every* client's `*.mydomain.com` request to an internal IP address. I also found this helpful blog entry: https://whhone.com/posts/local-dns-rewrite/ It looks like an alternate solution is setting up a rule in my router to do hairpin nat, which would take all requests that are outbound with my public IP address as a destination and instead reroute them to my NGINX proxy manager's internal IP address. I think either solution will solve my needs. But since neither solution can redirect to different ports, and my reverse proxy (NPM) sits on different ports (neither 80 nor 443). So I will need to reconfigure my NPM docker container with macvlan and give it it's own IP so it can sit on 80 and 443. I'm going to start going down this rabbit hole, thank you for your advice so far! If you see anything wrong with my understanding of how this works or the path I'm taking please let me know! ---------------------------------------------------------------------- 0r_not · 2023-12-02 18:42 Frigate + Coral TPU, Homeassistant with public facing address (Proxy - nginx or HAproxy). Integrate frigate with Homeassistant -- add the frigate card to Lovelace. ---------------------------------------------------------------------- timothyclaypole · 2023-12-02 20:43 Good luck! ---------------------------------------------------------------------- mekaneck84 · 2023-12-03 15:23 What to say thank you for helping out with this and getting me to think about it in simple terms. Everything is now working using a single DNS rewrite. If I hadn’t been stupid about it, it would have taken just a few minutes of work. However I spent about 6 hours trying to get the NGINX docker container onto a macvlan while retaining the ability for it to talk to all the other containers by connecting them all on a bridge network. Turns out I was doing it correctly but was testing it out without the rewrite or updating my port forwarding to the new proxy IP. I had given up for the night and was brushing my teeth when it hit me. Working perfectly now!