few days ago , with some friends of mine, we started a discussion about service or application that could be behind a firewall (so "Natted") and services that can't.
First of all what's a NAT ? You can find a tons of articles on internet about the Network Address Translation (RFC 1631).
Anyway the primary purpose of it is to avoid the unconscionable usage of public internet IPs.
So the NAT permit to map IPs between different address realms, in particular when one of these is not routable (ex. private IP addresses).
As the same private ranges (RFC 1918) can be used by several companies/users, they become, for their intrinsic nature, not routable in a public/common infrastructure where ranges are unique and duplicates are not admissible.
Here you have NAT !
The devices that come in play to make this communication possible usually sit at the firewall level, on the frontier.
In this way when an external customer/packet sender wants to communicate with a service that resides in a private area will comes in touch with a NAT device that make the communication possible making the "sender" unaware of the trick.
Inside the classic NAT concept we can distinguish the Dynamic NAT (i.e. an internal device use a single IP public address for a limited time and can be reached from internet) and Static NAT (i.e. when we reserve a single public IP for an internal server that deliver one or multiple services).
Let’s also talk about the NAT that include Port Translation (i.e. the internal subnet, composed by many computers, that browse the internet using only 1 public IP).
I discovered that, in most cases, the NAT is not possible due to the protocol type(i.e. IPSEC, Kerberos,X Windowing System and X-term/Telnet, RSH/RLOGIN and so on).
https://www.ietf.org/rfc/rfc3027.txt
Anyway let’s explain better.
THE IPSEC CASE
The NAT process regenerates the TCP checksums so that means that this part of the packet must be readable and not encrypted.
Some encryption methods affects only the payload; so the checksum, in the TCP header, can be recalculated….so there are no issues (i.e. SSH, SSL).
But if the header is not “readable”, the checksum, during the NAT transformation, cannot be recalculated so the header cannot be modified.
In presence of particular protocols an application layer gateway can help to “NAT” the communication. For example FTP can be aided from this kind of ALG or the DNS itself (SNMP, SIP, RealAudio,etc.)
In case of IPSEC for example :
NAT modifies the AH ( Authentication Header) that is an important part of the “new” TCP/IP packet in case of an IPSEC channel. AH is used to avoid any kind of modification (MITM,and so on) so NAT and AH will not work together.
We are talking about the ESP transport mode :
As you know the Transport mode is used between two end point (like hosts), instead the Tunnel mode is used between two gateways or firewalls.
If the endpoint can modify the IPSEC Tunnel configuration telling it to ignore the checksum verification the NAT will work with IPSEC. Why ? Because :
1. NAT verifies the integrity of the TCP part (recalculating and rewriting the checksum)…..if it cannot do the handshake will fail
2. On the other hand if NAT modifies the checksum is the ESP that will fail because when it verify the integrity of the packet it will find that it was modified.
After this first obstacle we have, in IPSEC, another one : IKE (Internet Key Exchange) that is used to authenticate endpoints in terms of IP. Since NAT translate the IP this check will fail. Is for this reason that it was introduced, in the “main mode” and “quick mode” phases, other methods of identification (i.e. FQDN or ID).
Last obstacle to our IPSEC channels is the SA (Security Association). This step could create problems in case of multiple hosts behind a device that apply NAPT (Network Address Port Translation)….consider for example multiple hosts that resides behind this kind of device : how can they rekey the request contacting the right port that was used to establish, the first time, the channel ? The workaround is on the IKE port that can vary in presence of several hosts : you can fix the rekey port assigning one fixed port to the host n.1, a second fixed port to the host n.2 and so on.
CONCLUSION
To reply to my friends the response is posted below…… POTENTIALLY an application can be natted in every situation….what can limit its “NAT attitude” is :
- Application limit : deliberately introduced into the source code
- Protocol limit : as discussed above (application layer protocols)
About CPanel :
https://documentation.cpanel.net/display/ALD/1:1+NAT
some old articles about Cpanel and NAT
https://forums.cpanel.net/threads/using-cpanel-with-nat-urgent.39978/#post671342
About WHMCS :
http://forums.whmcs.com/showthread.php?4996-Will-WHMCS-works-behind-an-NAT-firewall
About NAT
http://www.cisco.com/web/about/ac123/ac147/ac174/ac182/about_cisco_ipj_archive_article09186a00800c83ec.html
No comments:
Post a Comment