NAT Reflection (Pure NAT) not working for same subnet (v2.2.2)
-
I know you are dead set in your opinion that NAT reflection should work like you want it to but I think you are going to be disappointed.
Your real problem is you expect something to perform NAT but the client and servers are on the same subnet. Anything that will make that happen will be firmly in the "ugly hack" category.
Put your servers behind an OPTX interface and NAT to them from WAN
Then since your ports have to be translated, use split DNS to point your LAN hosts directly at the inside (real) IP address of the servers and translate the ports (not the addresses) with rules on LAN similar to those on WAN.
Set it up that way and it'll just work.
-
…
Then since your ports have to be translated, use split DNS to point your LAN hosts directly at the inside (real) IP address of the servers and translate the ports (not the addresses) with rules on LAN similar to those on WAN.
Set it up that way and it'll just work.
I already have this functionality. And it appears that you don't realize that your proposal requires the functionality of the "ugly hack" you eschew. Translating the ports is the same functionality as translating the IP: it's all Network Address Translation.
The problem explained in the initial post is that the pfSense-supported feature of NAT Reflection is not completely working, because the necessary pf rule is not being set. It's a single checkbox. I'm asking for people to offer help as to why the functionality offered by this checkbox wouldn't be working. Perhaps there's a related setting or feature-set that is documented to interfere with it? I don't know; that's why I'm asking. If there was a supported way for me to manually add in a persistent pf rule as a workaround, that would be a possibility.
It's like I'm asking about why my backup-camera isn't working on my new car. But instead of trying to help, people decide that time is better spent pontificating about how stupid backup-cameras are, and that I just shouldn't use them.
-
You need to enable "Enable automatic outbound NAT for Reflection", which adds the "nat on …" rules to accommodate routing traffic back out the same interface it came in on.
-
Sounds like you have that box checked. You're not looking for nat-to on a pass out, first make sure you're actually looking for the right thing.
Example for a port forward to WAN IP 192.0.2.127 port 1234 to internal host 192.168.111.100, where vmx0 is WAN, vmx1 is LAN.
# grep "rdr on" /tmp/rules.debug rdr on vmx0 proto tcp from any to 192.0.2.127 port 1234 -> 192.168.111.100 rdr on vmx1 proto tcp from any to 192.0.2.127 port 1234 -> 192.168.111.100 # grep "nat on" /tmp/rules.debug no nat on vmx1 proto tcp from vmx1 to 192.168.111.100 port 1234 nat on vmx1 proto tcp from 192.168.111.0/24 to 192.168.111.100 port 1234 -> 192.168.111.1 port 1024:65535If you don't have such rules, most likely it's because you have a gateway chosen on the interface in question under Interfaces>LAN or whatever the internal interface is. That's strictly for Internet connections, and outbound NAT for reflection is only for non-Internet connections. If that's not the case, we'll need some more details about your config. This definitely works in general.
-
@cmb:
Sounds like you have that box checked. You're not looking for nat-to on a pass out, first make sure you're actually looking for the right thing.
I see my mistake: I conflated OpenBSD with FreeBSD. FreeBSD doesn't currently implement the "nat-to" stuff, so yes, I looked for the wrong thing in filter.inc.
@cmb:
Example for a port forward to WAN IP 192.0.2.127 port 1234 to internal host 192.168.111.100, where vmx0 is WAN, vmx1 is LAN.
# grep "rdr on" /tmp/rules.debug rdr on vmx0 proto tcp from any to 192.0.2.127 port 1234 -> 192.168.111.100 rdr on vmx1 proto tcp from any to 192.0.2.127 port 1234 -> 192.168.111.100 # grep "nat on" /tmp/rules.debug no nat on vmx1 proto tcp from vmx1 to 192.168.111.100 port 1234 nat on vmx1 proto tcp from 192.168.111.0/24 to 192.168.111.100 port 1234 -> 192.168.111.1 port 1024:65535If you don't have such rules, most likely it's because you have a gateway chosen on the interface in question under Interfaces>LAN or whatever the internal interface is. That's strictly for Internet connections, and outbound NAT for reflection is only for non-Internet connections. If that's not the case, we'll need some more details about your config. This definitely works in general.
I do not have a gateway set on my (internal) "BETA" interface. The config I have in /tmp/rules.debug does not have anything like the 2 "nat on" rules you listed.
However, I manually recreated the necessary "nat on" rule on the "Firewall: NAT: Outbound" page, and now NAT Reflection is completely working as expected. So, at least I have a workaround for now. Thanks for the example. When I first attempted a workaround by manually creating an outbound NAT rule, I didn't know that "rdr" applies before "nat", I mistakenly put the WAN IP:port for the destination.
If ever I get time, I expect that I'll have to rebuild my config on a test platform to discover what's interfering with this functionality. In the mean time, this is the relevant part of /tmp/rules.debug now. ( betaweb resolves to 10.121.12.131, and re2_vlan2 serves 10.121.12.0/24 ):
... BETA = "{ re2_vlan2 }" ... betaweb = "<betaweb>" ... # Outbound NAT rules (manual) ... nat on $BETA proto tcp from 10.121.12.0/24 to 10.121.12.131/32 port 443 -> 10.121.12.1/32 port 1024:65535 ... rdr pass on re0 proto tcp from any to x.x.x.198 port 443 -> $betaweb # Reflection redirect rdr pass on { re1 re2_vlan2 openvpn } proto tcp from any to x.x.x.198 port 443 -> $betaweb ...</betaweb>…and the same thing, as displayed by pfctl:
... nat on re2_vlan2 inet proto tcp from 10.121.12.0/24 to 10.121.12.131 port = https -> 10.121.12.1 port 1024:65535 ... rdr pass on re0 inet proto tcp from any to x.x.x.198 port = https -> <betaweb>round-robin rdr pass on re1 inet proto tcp from any to x.x.x.198 port = https -> <betaweb>round-robin rdr pass on re2_vlan2 inet proto tcp from any to x.x.x.198 port = https -> <betaweb>round-robin rdr pass on openvpn inet proto tcp from any to x.x.x.198 port = https -> <betaweb>round-robin ...</betaweb></betaweb></betaweb></betaweb> -
I suspect it's something to do with the round robin you're doing. Would you mind sharing a copy of your config with me? If you copy/paste it from status.php it'll sanitize it to remove certs, passwords, etc. Can email to cmb at pfsense dot org or attach to a PM here and I'll delete it after testing.
-
I'm interested in a fully integrated solution to this as well. I've been using pfsense as an enterprise firewall for a long time, and freebsd for even longer; roughly 20 years now. There are use cases (like mine) where split DNS is simply not an option.
For example, a current project of mine has me using pfsense in a multi-wan environment protecting a corporate internal LAN as well as separate LAN subnets for machines (VMs) the company is hosting for customers. These segments are all in their own VLAN and intentionally disallowed from accessing other customer subnets as well as the corporate LAN subnet.
For example, imagine the following five networks:
WAN1 : 1.0.0.0/28 (VLAN 1)
WAN2 : 2.0.0.0/28 (VLAN 2)
LAN: 3.0.0.0/24 (VLAN 10)
CUST1 : 4.0.0.0/24 (VLAN 100)
CUST2 : 4.0.1.0/24 (VLAN 101)This is very similar to a setup I'm currently working with. All of the public IPs are assigned as virtual IPs on a single pfsense install. LAN and CUST networks are allowed nearly unrestricted outbound traffic to the internet. LAN traffic is allowed into each CUST subnet for management. CUST networks are not allowed to initiate traffic to the LAN or to other CUST networks.
Desired operation looks basically like this:
WANx -> LAN : Restricted. Some explicit port forwards.
WANx -> CUST* : Restricted. Some explicit port forwards.
LAN -> CUST* : Unrestricted.
CUST1 -> CUST1 : Unrestricted
CUST2 -> CUST2 : Unrestricted
CUST -> LAN : Rejected
CUST1 -> CUST2 : Rejected
CUST2 -> CUST1 : RejectedThere are other ways to do it, but "NAT reflection" is the simplest, requiring the fewest changes to existing infrastructure.
-
Not working for me too.
Version 2.2.4 (amd64)
Old instalation 2.1.5 (amd64) is work.
Update 2.1.5 to 2.2.4 too workNew instalation 2.2.4 not work
-
Still not working :o
-
Pure NAT for same subnet works fine. You also need to enable the source NAT option, "Enable automatic outbound NAT for Reflection".
-
I know this is a bit of thread necromancy on my part, but I had the same issue as the OP, and was able to use the discussion here to put together a fix for the bug. (Yes, I really do think it is an actual bug).
I figured I would put my findings here for future people googling the issue.
HOWEVER.. when I try to submit, I am being told that I am spam. "Post content was flagged as spam by Akismet.com" Grr.
So here is my analysis:
https://docs.google.com/document/d/1DCtqI2q3RlaK6HkTgp_xFw6poxWg6wiJlzw0V7lDtGU/edit?usp=sharing -
And do you have this checked?
-
Yes.
-
Well works fine here..
I just created a port forward to 192.168.9.10 port 80..
I enabled nat reflection, pure nat... Hit my wan IP 64.53 - and there you go it WAD..
You can see it natted my traffic from 192.168.9.100 to 64.53.x.x to souce IP of my lan interface 192.168.9.253
-
Ok. I believe that it works for you. But, It does not work for me.
Whatever this bug is, it is clear that it is not happening to everyone.I don't know what would be peculiar about my setup.
It is relatively fresh, only a few weeks old, and I have only a few rules set up (so far). Nothing complex at all. This NAT reflection was the first "interesting" thing I tried.I don't know what I could do to convince you that I really am experiencing this issue, but I'm happy to try if you have suggestions.
-
@rossc719 said in NAT Reflection (Pure NAT) not working for same subnet (v2.2.2):
Whatever this bug is
A "bug" can be duplicated and normally easy to replicated...
Whatever is going on with your specific scenario is not a bug, unless you can show other people having the issues that is not from 5 years ago - which I just tried and works as designed..
When create the port forward and you have that checked, it will auto create the rule that does the source natting... Did you check that after the fact? After you have created your port forward?
To be honest they really could just rip out and remove all the nat reflection shit to be honest.. Its NOT how things should be done in the first place... I would never in a million years setup such a hack ;) If I wanted to get to my webserver next to me, then I would resolve its fully qualified domain to that IP, or use that IP... Makes ZERO sense to hit my wan IP in the first place ;)
But as you can see, even someone that doesn't use nat reflection, and hates it at professional level - it clearly WAD.. It was couple clicks to get that nonsense working. Simple 1 click setting up host override easier and cleaner solution ;)
BTW - what mask are you running on your network?
I've got a web server running @ 192.168.5.1. I am testing using my phone @ 192.168.10.1. My LAN interface of the pfsense is @ 192.168.0.1.To any sane person that would be 3 different networks.. Are you using a /16 or something? To allow for the 65K devices you have on it? ;)
-
When create the port forward and you have that checked, it will auto create the rule that does the source natting... Did you check that after the fact? After you have created your port forward?
Yes. It was not there.
Specifically, there were no "nat on" lines that related to port 80 at all.In fact, there still aren't:
[2.4.5-RELEASE][admin@juno.wombat.net]/root: grep "nat on" /tmp/rules.debug nat on $LAN inet from 192.168.0.0/18 to 192.168.0.0/18 -> 192.168.0.1/32 port 1024:65535 nat on $WAN inet from $tonatsubnets to any port 500 -> WAN_ADDRESS/32 static-port nat on $WAN inet6 from $tonatsubnets to any port 500 -> (igb0) static-port nat on $WAN inet from $tonatsubnets to any -> WAN_ADDRESS/32 port 1024:65535 nat on $WAN inet6 from $tonatsubnets to any -> (igb0) port 1024:65535 no nat on igb1 proto udp from (igb1) to 192.168.0.2 port 53 nat on igb1 proto udp from 192.168.0.0/18 to 192.168.0.2 port 53 -> 192.168.0.1 port 1024:65535But as you can see, ... It was couple clicks to get that nonsense working.
Indeed. For you.
Again... I really do believe that it works for you.
It does not work for me.BTW - what mask are you running on your network?
192.168.0.0/18
-
@rossc719 said in NAT Reflection (Pure NAT) not working for same subnet (v2.2.2):
192.168.0.0/18
Use something sane! ;)
-
@johnpoz said in NAT Reflection (Pure NAT) not working for same subnet (v2.2.2):
Use something sane! ;)
I don't see that this is related to the issue at hand.
-
Maybe its a bug for when people use insane masks and try and do nat reflection ;)
2.4.5-RELEASE][admin@sg4860.local.lan]/root: grep "nat on" /tmp/rules.debug no nat on igb0 proto tcp from (igb0) to 192.168.9.10 port 6666 nat on igb0 proto tcp from 192.168.9.0/24 to 192.168.9.10 port 6666 -> 192.168.9.253 port 1024:65535 [2.4.5-RELEASE][admin@sg4860.local.lan]/root:These get created when I do nat reflection, just did another one for 6666 port
