How do port forward negations work with 1:1 NAT?
-
In a intranet-natting-proxy combo pfSense, 1:1 NAT rules don't seem to be overridden by No RDR as the docs say the should.
The negated traffic rule is for the web traffic which is handled by in-firewall proxy listening on any address, thus in my theory if left untranslated the proxy should pick it right up, right? But that's not what happens. The docs don't specify if No RDR rules continue to take precedence over 1:1s.
I fixed it by simply overriding the traffic forwarding it to the firewall itself — well, to a VIP address for the proxy to have a little extra flexibility in the future since I was gonna NAT anyway — but I think it was more elegant not forwarding it at all before it made it to the proxy.
There's always the chance I forgot something too… made some mistake, whatever. The whole NAT ruleset is tiny, most of the work is in the reverse proxy thus it should be easy to spot, and yet I'm failing miserably. So, if you please, could you point it out if there's something wrong with it?
Here's all the NAT:
Thanks!
-
@senseivita 1:1 NAT rules do not have any automatic firewall rule generation capabilities.
If you use 1:1 NAT it is up to you to make the necessary firewall rules to pass inbound traffic.
Port forwards will, by default, maintain these firewall rules automatically.
Maybe that's the difference. The rules in this case would be on Firewall > Rules, BACKBONE and pass traffic to the destination POST-NAT address (The 1:1 internal address).
-
@Derelict That didn't even cross my mind when posting, fortunately because of <see-below>, I was forced to think about it when I originally did the rule set (
rfc1918is a huge misnomer. Here, it just means "known addresses"):
What you mentioned about the automatically-maintained rules got me thinking though; OSPF rules wouldn't work if there was a higher, ultra-broad
rfc1918→*rule. There had to be an explicit rule for it or it wouldn't work. I don't know if it was the protocol or the multicast range, I was too sleep deprived already to keep going, but could there be some of that too with NAT?It's supposed to be basic, but for me, NAT (after multicast routing) is probably the most confusing thing to do, so I appreciate you answering even if it's not beyond of what you have, because you already indirectly helped me confirm some things. Thanks!
-
@senseivita It is impossible for anyone to know what that rule set actually does without seeing the contents of those aliases too.
@senseivita said in How do port forward negations work with 1:1 NAT?:
(rfc1918 is a huge misnomer. Here, it just means "known addresses")
It is whatever you define in the rfc1918 alias.
-
@Derelict It's a misnomer only because it's much broader than than RFC1918, I thought it was implied with IPv6, sorry about that.
rfc1918is a network(s) type alias, including:- IPv4: Former classes A, B and C
- IPv4: APIPA
- IPv4: 2x public addresses
- IPv6: 2x global /64s
- IPv6: 1x global /48
- IPv6: Unique local range
- IPv6: Link-local range
Though, it only needs to cover class A as you mentioned, the VIP address is the C range but the post-NAT is in the A. Everything is the A, C is for p2p soft-of-connections in /31s (tunnels) and /32s (VIPs, routed with OSPF).
-
@senseivita Still no way to know why you are experiencing issues looking at that rule set. With the 1:1 in place you need to pass the desired inbound traffic to 10.7.0.229 and 10.16.0.35. Like I said, port forwards, by default, make this rule for you. 1:1 NAT does not.
