NAT Reflection Controversy
-
People can rail against NAT reflection ("hairpinning") all they want. But from what I see in the RFC's it is a NAT requirement. It is a legitimate capability to be used for meeting certain requirements. Not everyone's requirements center around elegance and performance, etc. Though from a configuration and management standpoint it is fairly elegant.
Those who have a problem with NAT reflection being an RFC NAT requirement/standard should take it up with the IETF. Making emotional demagoguery rants about it here does little good for anyone. Though I do appreciate seeing who has closed minds with what essentially amounts to an emotional do it "this way" or you're an idiot mentality. Without any consideration for what the specific requirements are.
NAT reflection ("hairpinning") has been an RFC compliance requirement since at least 2007 (RFC 4787). And continued in 2008 (RFC 5382). Far as I could find has not be rescinded in any subsequent updates. These folks involved with the RFC's probably know a thing or two on the subject.
https://tools.ietf.org/html/rfc4787
Network Working Group F. Audet, Ed.
Request for Comments: 4787 Nortel Networks
BCP: 127 C. Jennings
Category: Best Current Practice Cisco Systems
January 2007https://tools.ietf.org/html/rfc4787#section-12
12. RequirementsThe requirements in this section are aimed at minimizing the
complications caused by NATs to applications, such as realtime
communications and online gaming. The requirements listed earlier in
the document are consolidated here into a single section.It should be understood, however, that applications normally do not
know in advance if the NAT conforms to the recommendations defined in
this section. Peer-to-peer media applications still need to use
normal procedures, such as ICE [ICE].A NAT that supports all the mandatory requirements of this
specification (i.e., the "MUST"), is "compliant with this
specification". A NAT that supports all the requirements of this
specification (i.e., including the "RECOMMENDED") is "fully compliant
with all the mandatory and recommended requirements of this
specification".REQ-9: A NAT MUST support "Hairpinning".
a) A NAT Hairpinning behavior MUST be "External source IP address
and port".https://tools.ietf.org/html/rfc5382
Network Working Group S. Guha, Ed.
Request for Comments: 5382 Cornell U.
BCP: 142 K. Biswas
Category: Best Current Practice Cisco Systems
B. Ford
MPI-SWS
S. Sivakumar
Cisco Systems
P. Srisuresh
Kazeon Systems
October 2008https://tools.ietf.org/html/rfc5382#section-7.2
7.2. Hairpinning BehaviorNATs that forward packets originating from an internal address,
destined for an external address that matches the active mapping for
an internal address, back to that internal address are defined in
[BEHAVE-UDP] as supporting "hairpinning". If the NAT presents the
hairpinned packet with an external source IP address and port (i.e.,
the mapped source address and port of the originating internal
endpoint), then it is defined to have "External source IP address and
port" for hairpinning. Hairpinning is necessary to allow two
internal endpoints (known to each other only by their external mapped
addresses) to communicate with each other. "External source IP
address and port" behavior for hairpinning avoids confusing
implementations that expect the external source IP address and port.REQ-8: A NAT MUST support "hairpinning" for TCP.
a) A NAT's hairpinning behavior MUST be of type "External source
IP address and port".Justification: This requirement allows two applications behind the
same NAT that are trying to communicate with each other using
their external addresses.
a) Using the external source address and port for the hairpinned
packet is necessary for applications that do not expect to
receive a packet from a different address than the external
address they are trying to communicate with.https://tools.ietf.org/html/rfc5382#section-8
8. RequirementsA NAT that supports all of the mandatory requirements of this
specification (i.e., the "MUST") and is compliant with [BEHAVE-UDP],
is "compliant with this specification". A NAT that supports all of
the requirements of this specification (i.e., included the
"RECOMMENDED") and is fully compliant with [BEHAVE-UDP] is "fully
compliant with all the mandatory and recommended requirements of this
specification".REQ-8: A NAT MUST support "hairpinning" for TCP.
a) A NAT's hairpinning behavior MUST be of type "External source
IP address and port". -
I want to thank you for this post. Every time I mentioned using NAT Reflection I get blasted by a few individuals. My configuration only works with NAT Reflection and works very well. If it was such a bad thing I would imagine the PFsense designers would not have made it an option to use with port forwarding.
-
Simply because it's part of the NAT spec says nothing about whether it's a good choice to use it…
There are plenty of users around here with lots of professional networking experience and their opinions about which network configurations are "best" should be respected.
At the end of the day though, if some uncommon, sub-optimal configuration works for you then use it.
-
Uncommon, sub-optimal - good words I would use.. Abomination, Borked - other terms that also fit it nicely ;)
This is the point right here that makes is "sub-optimal" "hairpinning"
In what scenario would you what to do this??? Hairpinning in networking is never a desired configuration.. It should always be avoided if possible..
So to comments like this
"My configuration only works with NAT Reflection"
I say nonsense just plain nonsense.. all these sorts of comments point out is you don't how to do it any other way.. Doesn't mean it will only work that way.. Doesn't mean the way your doing it is any way shape or form the "optimal" way to do it.. The fact that it has a hairpin makes it a sub-optimal configuration.. Be it the rfcs say nat needs to support reflection or not..
edit: So what about req-7? This RFC is has a lot of just nonsense in it..
REQ-7: A NAT device whose external IP interface can be configured
dynamically MUST either (1) automatically ensure that its internal
network uses IP addresses that do not conflict with its external
network, or (2) be able to translate and forward traffic between
all internal nodes and all external nodes whose IP addresses
numerically conflict with the internal network.So this is saying that your nat needs to be able to work when you use the same network on both sides of it.. When exactly is a client even going to send a packet to the nat device if the IP in question is local to its own network..
This is just freaking GOLD ;)
ISP's "intermediate" privately-addressed network and the customer's internal privately-addressed network will not use numerically identical or overlapping RFC 1918 IP subnets. Furthermore, customers of consumer-level NATs cannot be expected to have the technical knowledge to prevent this scenario from occurring by manually configuring their internal network with non-conflicting RFC 1918 subnets.
An RFC that calls users stupid ;) heheheheheeh
-
Lots of negativity but no reasoning. I use what works and NAT Reflection works perfectly. And it is the only choice for my current configuration. Which I must say also works perfectly. Yes there is a bit of a performance loss, but that is not a concern for this project. Just because I don't have the "optimal" setup doesn't mean that it isn't a viable one.
By the way johnpoz, one of the lawyers wrote one of the programs and also has a degree in computer science, do you?. Another attempt by a so called "professional" to make tons of judgements based on no knowledge of the situation because it's not done the way they see it.
-
Lots of negativity but no reasoning. I use what works and NAT Reflection works perfectly. And it is the only choice for my current configuration. Which I must say also works perfectly. Yes there is a bit of a performance loss, but that is not a concern for this project. Just because I don't have the "optimal" setup doesn't mean that it isn't a viable one.
By the way johnpoz, one of the lawyers wrote one of the programs and also has a degree in computer science, do you?. Another attempt by a so called "professional" to make tons of judgements based on no knowledge of the situation because it's not done the way they see it.
I think you are perceiving negativity where there is none.
johnpoz stated his reasons. Simply because NAT reflection is the only option that worked for you doesn't mean there aren't better options to be discovered, just like when I learned that double-NAT was stupid and my networking knowledge was far worse than I'd assumed.
-
"to make tons of judgements based on no knowledge of the situation because it's not done the way they see it."
You are doing a HAIRPIN.. By that statement a lone its not optimal - this is just FACT!!! Sorry if you don't like people calling you out on the BORKED setup you have..
Your the one with some server running some storage app that is multihomed using different ports so it can talk to itself right.. [rolleyes] And your lawyers needed a EV cert.. Which has ZERO to do with actual security..
I can tell you for sure with sparse and lacking info that has been given is your setup is not optimal that is for DAMN SURE!!!
-
Every time I mentioned using NAT Reflection I get blasted by a few individuals.
I know. Some people cannot comprehend that network packet flow efficiency is not always the be all end all of network design. Sometimes there are other things that are more valued and beneficial. Especially when there is no significant negative performance related impact.
Keep your head up and don't let the rhetoric from a bunch of zealots keep you from doing what best serves your customers/employer. My guess is they probably value the benefits of functionality over that last nth degree of performance. So if the router has the power to handle it then so be it. There are probably better ROI things to allocate resources to.
In due time apps, equipment, etc. get replaced. Those can be good times to make changes to the way things work. Likely better than re-engineer an existing environment just for the sake of eliminating something that isn't causing a problem.
Enjoy your functionally.
-
Every time I mentioned using NAT Reflection I get blasted by a few individuals.
I know. Some people cannot comprehend that network packet flow efficiency is not always the be all end all of network design. Sometimes there are other things that are more valued and beneficial. Especially when there is no significant negative performance related impact.
Keep your head up and don't let the rhetoric from a bunch of zealots keep you from doing what best serves your customers/employer. My guess is they probably value the benefits of functionality over that last nth degree of performance. So if the router has the power to handle it then so be it. There are probably better ROI things to allocate resources to.
In due time apps, equipment, etc. get replaced. Those can be good times to make changes to the way things work. Likely better than re-engineer an existing environment just for the sake of eliminating something that isn't causing a problem.
Enjoy your functionally.
I haven't seen these "zealots" mention performance as the primary argument against NAT reflection but maybe I missed it.
Perhaps I am just confused that you two are crapping all over some of the most respected members (IMO) on this forum.
The emotion in these conversations are a bit strange. Personally, I am happy to see that there are numerous ways to solve networking problems… neither is really right or wrong I suppose. I don't really understand the hesitance towards trying all available options. So NAT reflection works, but just for fun, maybe research ways to avoid it? In my limited experience, only broken clients have required it and ultimately I was happy to find "proper" replacements/fixes.
-
Nullity its not worth continuing this thread.. If they want to run a borked setup, that is on them and their users. No skin off my nose that is for sure.
You can make as many arguments as you want for the need for to support nat reflection, and sure if you were in a situation described then you might have to use it.
The rfc clearly spells out a justification for supporting it
Justification: This requirement allows two applications behind the same NAT that are trying to communicate with each other using their external addresses.
But as you have stated and is impossible to not see - this is not an optimal setup. But as you see there are many users that don't want optimal or for that matter to even understand their applications their networks support. They just want to know what button to click..
The justification from the rfc and the part I underlined is the only reason you would ever need to reflect a nat or hairpin it, or loopback portforward it - lots of terms for it.. If you were on some system where you could not control what address an application used.. Ok.. Lets say it was hard coded to a public IP.. Bad application for doing such a thing - but you do what you have to to make it work.. until such time that you can get the application fixed ;)
If they want click its easy, let them use click its easy. I have been running corp and smb networks for going on 30 years.. Since before there even was tcp/ip and nat of any sort.. I have had to deal with many a homegrown application and such. And I can say for sure I have never seen any sort of application that would require a server to be multihomed in the same network so it could talk to itself via different ports ;) But clearly that is the sort of application this user is working with.. And the other thing with this application is it seems it has to use the same fqdn to talk to these 3 different IPs…
And he can not just use different names because he has a EV with that fqdn..
I love it how your making judgement without knowing gets thrown out there - well then draw it up, spell it out so we all know. And if nat reflection is the only answer than I will be the first to say that.. But it sure an the F would not be my first choice.. But hey if your a button clicking, hey look at that it works - not sure why but it does sort of guy.. Than have at it ;)
edit: Also seems my comments on nat reflection have gotten me some smites.. Isn't that nice when you want to debate the merits of how to do something correctly in IT.. The guy said my system was borked... Bad guy on the internet - I smite you!!!
-
Simply because it's part of the NAT spec says nothing about whether it's a good choice to use it…
There are plenty of users around here with lots of professional networking experience and their opinions about which network configurations are "best" should be respected.
At the end of the day though, if some uncommon, sub-optimal configuration works for you then use it.
But it also says nothing about being a bad choice. Id love to hear why it is a bad choice, instead of "your setup is borked!" I would love to hear the reasoning. Because I want to better myself. I am not going to believe just because someone told me on a forum.
I have people try and tell me my primary job all the time and while Im patient I will just let you believe your way and go mine at a very early point. Ive been in my game for just north of 30 years. So I do understand when people wont listen but Im very willing to explain patiently till they get it.
Can someone please explain why this is a bad choice without interjecting their opinion on the matter. I promise I wont smite anyone for their opinions either way. ;)
Hairpinning or not.. Is it not secure? Im not after speed. Im after results.
-
Can someone please explain why this is a bad choice without interjecting their opinion on the matter. I promise I wont smite anyone for their opinions either way. ;)
Hairpinning or not.. Is it not secure? Im not after speed. Im after results.
Mostly it seems to be just the inefficiency of hairpinning. Don't recall seeing anyone cite a security concern.
Here is a non opinionated answer for you. And dcol was sure to give the poster a thank you for it. Maybe I should go do the same.
Re: Why is NAT Reflection not a good thing?
https://forum.pfsense.org/index.php?topic=124880.msg690112#msg690112Like you when I use NAT reflection performance/efficiency is not of concern and I have other reasons for wanting to use it sometimes even though split DNS would be functional too.
-
Like you when I use NAT reflection performance/efficiency is not of concern and I have other reasons for wanting to use it sometimes even though split DNS would be functional too.
Thanks NOYB!
One very definite objection to NAT reflection is that it makes traffic that was never meant for the router/firewall in the first place to traverse it, every single packet of the redirected traffic. This may be a major performance issue depending on the set up. With split DNS this is never an issue because the local traffic stays local.
Yep- I just don't care about that.. There is not enough of it to cause us any issues. I don't like split DNS because it can come back to haunt users from time to time. (i.e. DNS resolving the wrong site and needing to be flushed from a poorly written piece of software.)
In my opinion I don't (as Ive seen others agree) believe that a server available from outside should be on the same LAN as your users.. Oh wait.. thats just good security sense. Or so Im told. :o If thats the case then anything from my working LAN that needs to see the server is going through the router anyways (multiple subnets.) Since my ISP can't seem to redirect it back my direction (don't get me started) then I have to use NAT reflection to keep my sanity. -
:)
-
Since my ISP can't seem to redirect it back my direction (don't get me started)
They don't do that because why would they, how could they, and reflection sucks.
If it works for you, great. Use it.
-
" If thats the case then anything from my working LAN that needs to see the server is going through the router anyways (multiple subnets.) "
But not through the nat engine.. For it to work the source has to be natted to the external IP. So when 192.168.1.100 wants to talk to 192.168.2.100, he is using the public IP of pfsense to get there lets call it 1.2.3.4.. So now to send the traffic to 192.168.2.100 pfsense has to nat that source IP to 1.2.3.4 so that it can be returned through the same path.. If not you have a asymmetrical, and that part of it even stated in the rfc cited.
a) A NAT's hairpinning behavior MUST be of type "External source IP address and port".
What if your 2 segments are on a downstream router.. Now you have to transverse all the way up to the edge just to come back down..
Its always the same common theme with these threads asking about nat reflection - they don't understand how to resolve the IP they want to get to its local IP vs its public IP.. I agree if there is NO way for you to use the local IP.. Like a hard coded public IP in the application. Or the system uses some method of finding the other system it wants to talk to via some outside 3rd party method that can only return the public IP.. Then you don't really have any choice.
But I have not seen that case ever brought up in all my years here that I can recall. So it seems it comes down to laziness.. I don't want take the time to resolve to the local IP and not have to nat if another segment, or just talk to the guy next to me.. So I am just going to use the public IP and make the firewall do extra work, and or even hairpin my traffic through its interface..
This is clearly not a optimal configuration - so it blows my freaking mind why anyone, that actual finds or is told there is another way would continue to do such a thing.
dcol setup is clearly a boondoggle of massive proportions.. EV cert provide no extra security.. It might make business sense if your site is hit by the masses.. But from what I can make of it its some sort of file sharing system for doctors. And is non-profit so he can only get 1??? But the lawyers and doctors want them?? But can not spend the few extra bucks for more?? Come on give me a break. Why would you spend $ on something like that.. So this forces him to use only 1 fqdn??? That has to talk to multiple ips which are really on the same box - so now he is running different parts of this application on different ports - and they need to talk to each other it seems? So if I read that right and they are using the public IP.. This server has to use nat reflection to talk to itself even?? How and the hell could that be optimal..
If you don't read that thread of his and think its a borked config – you shouldn't be in networking that is for damn freaking sure!! Or even IT of any fashion at all - shouldn't even be handling the support contracts ;)
Normally how it should go when talking between networking engineers..
eng1: Hey look I have this setup xyz, here is the drawing here are the details.. What do you think??
eng2: WTF dude - that is borked beyond anything I have ever seen..
eng1: Really - how would you do it..
eng2: Well you could do ABC, here draw it up for you - what do you think.
eng1: But how does Z work in that setup..
eng2: Like this - see the packets route here.. And now are not natted.
eng1: Hmmm so all I have to do is X and and then it doesn't do all that extra..
eng2: Yeah
eng1: Well F me.. Thanks dude..