NAT Reflection (Pure NAT) not working for same subnet (v2.2.2)
-
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
-
@johnpoz said in NAT Reflection (Pure NAT) not working for same subnet (v2.2.2):
Maybe its a bug for when people use insane masks and try and do nat reflection ;)
Perhaps, but seems unlikely. Especially given that the OP seems to have used 10.121.12.0/24.
-
The OP was using version 2.2 of pfsense.. So whatever has ZERO to do with today... Unless your using version 2.2 of pfsense?
Thought you said pfsense IP was 0.1 here there are nat rules to 0.2
no nat on igb1 proto udp from (igb1) to 192.168.0.2 port 53
-
@johnpoz said in NAT Reflection (Pure NAT) not working for same subnet (v2.2.2):
The OP was using version 2.2 of pfsense.. So whatever has ZERO to do with today... Unless your using version 2.2 of pfsense?
Nope, I am using 2.4.5-RELEASE.
These get created when I do nat reflection, just did another one for 6666 port
Again, I believe that it works for you.
But, it does not work for me.Thought you said pfsense IP was 0.1 here there are nat rules to 0.2
This is unrelated to the issue at hand.
0.2 is my DNS server.
0.1 is pfsense. -
Have no idea what else is unique to your setup... Someone using a /18 mask prob has all sorts of nonsense setup ;)
-
If anyone is interested in debugging this at a later date, please let me know.
I am very interested in working with anyone who has any constructive ideas for how to move forward.For now, the hack I described above, (The manually created outgoing NAT rule) seems to patch over the bug, so I will go ahead and use that.
Cheers
