NAT Reflection blocked by firewall
-
I've recently setup ACME+HAproxy to get valid-letsencrypt-certificates of LAN-only services.
Everything works fine so far - the only problem is that pfsense blocks the connection attempts on :443.
This is what my setup looks like:
sub.domain.tld --CNAME--> my.ddns.tld --IP-A--> ISP-router --IP-B--> pfSense --IP-C--> local-server
Some clarification:
IP-A: my public WAN ip (provided by my ISP)
IP-B: the network-IP that my ISP's router assigns to my pfsense (in pfSense, that's the IP of its WAN-interface)
IP-C: the IP assigned by pfsense to my local serverWhen I'm trying to open up sub.domain.tld, the site can't be reached because pfsense blocks this request:
Action Time Interface Source Destination Protocol BLOCKED <DATE> WAN <IP-A>:60699 <IP-B>:443 TCP:S
(The source-port varies)
Obviously, I can just allow the following rule:TCP: my.ddns.tld:* --> <IP-B>:443
After creating this rule, I can reach my services just fine. But this seems like a problematic rule.
I was under the impression that Nat Reflection is exactly what I'm looking for, meaning: when I try to access sub.domain.tld and pfsense can't reach it, it'll try to look for it in my local network instead.
My settings:
NAT Reflection mode: Pure NAT
Enable NAT Reflection for 1:1 NAT: Enabled
Enable automatic outbound NAT for Reflection: EnabledIncidentally, I've read that NAT Reflection is generally frowned upon. Is that true? If so, what's the preferred alternative?
-
@W5Ofwur1xtOmtk9ZBO said in NAT Reflection blocked by firewall:
when I try to access sub.domain.tld and pfsense can't reach it, it'll try to look for it in my local network instead.
re: this point, reflection allows requests to the WAN IP from inside the network. Otherwise the firewall would see the request coming from the wrong interface and deny it. There's no looking for things. https://docs.netgate.com/pfsense/en/latest/book/nat/nat-reflection.html NAT reflection isn't used at all if the request is coming from the WAN to begin with.
-
@teamits Thank you for this comment. I think I understand the problem now.
pfSense thinks my WAN-IP is (e.g.) 192.168.0.101 (which is the IP that was assigned to it by the other router). It's not the actual WAN-IP.
When I try to open 192.168.0.101, I correctly get the HAproxy default error-page (because my HAproxy frontend doesn't have a rule for it)
Meaning: Nat Reflection works correctly.
But how can I make pfSense understand the correct WAN-IP?
I already tried the following approach:
I created a host-override in pfSense's dns-resolver and told it to return it's own fake-WAN-IP (192.168.0.101) for my.ddns.tld-requests. So now, my.ddns.tld also redirects to pfSenseBut the actual domain still doesn't! Trying to open 'sub.domain.tld' will not redirect to 192.168.0.101, because the subdomain redirects to my ddns-provider, which redirects to my actual WAN-IP - instead of the fake-WAN-IP.
Not sure where to go from here. Obviously I could just create host-overrides for all of my sub-domains. But isn't there just a way to make pfsense understand the 'correct' WAN-IP?
-
In your situation it would be ideal if the ISP router had NAT reflection. Some routers do, many do not. So in your case subdomains and split DNS might be necessary, and then your connections won't go through pfSense at all, they would go straight to the LAN IP.
-
I just discovered that my ISPs router has an option called 'disable DNS Rebind Protection', which I'm assuming is the same as Nat Reflection?
It allows me to type in a number of hostnames that should be excluded from this.
I can just type in my ddns-hostname or my subdomains, but I don't really understand how that's supposed to work. How would the router know where/how to resolve it?
At least with pfSense, the HAproxy is on the same device. But how is the other router going to know about pfSense or HAproxy to forward that request to? Via Port-Forwards? I already have port 80 and 443 forwarded to pfSense. And inside pfSense I have automatic (hybrid) outbound NAT rules enabled.
But I still don't understand why it doesn't work.
Here's the traceroute output:
traceroute to sub.domain.tld (99.99.99.99), 30 hops max, 60 byte packets 1 192.168.1.1 0.183 ms 0.102 ms 0.091 ms 2 192.168.2.1 0.512 ms 0.856 ms 0.960 ms 3 99.99.99.99 2.361 ms !X 2.277 ms !X 2.190 ms !X
1.1 is pfsense, 2.1 is the other router.
How do I pinpoint the problem?
-
DNS rebinding and protection for it is something else: https://en.wikipedia.org/wiki/DNS_rebinding
It sounds to me like you'll need to get your PC resolving the hostname to the LAN IP of the web server. (or the WAN of the pfSense, but you might as well just use the internal IP at that point)