No. It's coming from Route 53. Actually got the mapping from Sam Dowlings Reverse Proxy Tut. Thanks
@KevDog, I now have a working pfsense setup.
I think there might be some confusion here. All of the services I have run locally on my LAN, hosted in FreeNAS iocage jails. I don't run anything on AWS. The only reason I use Route 53 is to make my local services publicly routable, which is convenient because my _website_ is hosted using AWS.
The reverse proxy I've configured runs on my LAN. The rules I specify forward traffic to the reverse proxy jail, which forwards traffic to whichever service is being requested, in your case this is Nextcloud. This means that the rules I've specified won't necessarily apply to you if you've got a different configuration.
As far as your nextcloud instance showing up in pfSense goes, what's happening at the moment makes sense because the instructions I provide include a manual IP configuration. The manual IP I set is outside of my DHCP range, and I've added an alias for each service so that I can easily identify them when creating rules. Having said that, if you _want_ it to show up in your DHCP Leases/ARP table, adding a static mapping or any of the alternatives
@danb35 suggested earlier would be appropriate. If you want the jail to draw a DHCP address though, you'll need to configure it that way. I normally just map these statically by IP instead of MAC.
Also a bit of a semantic point, but note that traffic doesn't go "through" Route 53 - It provides domain name system (DNS) resolution. All it is is a mapping of your website URL with your public IP. i.e., if you have three services, Nextcloud, Bitwarden, Heimdall, all hosted on a server on your home network, and your public IP address is 15.15.15.15, then you might create the equivalent of the following mappings in Route 53:
Service | Route 53 <url:ip> mapping |
nextcloud | <cloud.example.com:15.15.15.15> |
bitwarden | <bitwarden.example.com:15:15:15.15> |
heimdall | <heimdall.example.com:15.15.15.15> |
This means that if you navigate to
http://cloud.example.com (i.e., you're making a GET request), your DNS service provider will ask Route 53 what the ip of this alias is, and it will resolve to 15.15.15.15. Then your client will make a connection with the socket 15.15.15.15:80. Exactly the same thing happens for the other services, bitwarden.example.com and heimdall.example.com. Each of them should resolve to your public IP. All of this to say that you have a "direct" (not considering intermediate hops) route to the server - nothing travels _through_ Route 53.
You can confirm this by running
nslookup
from a computer not connected to your LAN (if you have a local mapping for the service subdomains, as I detail in my guide, otherwise it should work from inside your LAN as well), which should show something similar to the following:
Code:
$ nslookup cloud.example.com
Server: 8.8.8.8
Address: 8.8.8.8#53
Non-authoritative answer:
Name: cloud.example.com
Address: 15.15.15.15
With this in mind,
@KevDog makes a valid point. If your reverse proxy is hosted on AWS (in an EC2/Elastic Beanstalk instance or similar) then the configuration I've provided won't be suitable since it makes unencrypted connections to the services. It's only encrypted from the reverse proxy onwards. This means that if you have locally hosted servers and your reverse proxy on AWS, then all of the traffic between your house and the AWS servers will be unencrypted. Not good.