If the hashes do not match, somebody has translated the address or port. If the sender of the packet does not know his own IP address in case of multiple interfaces, and the implementation does not know which IP address is used to route the packet out , the sender can include multiple local hashes to the packet as separate NAT-D payloads. In this case, NAT is detected if and only if none of the hashes match.
Each payload contains one hash, so in case of multiple hashes, multiple NAT-D payloads are sent. In the normal case there are only two NAT-D payloads. All data inside the HASH is in the network byte-order. The port number is encoded as a 2 octet number in network byte-order.
If the first check fails i. They are added to the hash to make precomputation attacks for the IP address and port impossible. Take the common case of the initiator behind the NAT. All subsequent packets sent to this peer including informational notifications MUST be sent on port If these are successful, the responder MUST update local state so that all subsequent packets including informational notifications to the peer use the new port, and possibly the new IP address obtained from the incoming valid packet.
The IP address will seldom be different from the pre- changed IP address. If a negotiation starts on port , then it doesn't need to change anywhere else in the exchange. Once port change has occurred, if a packet is received on port , that packet is old. If the packet is an informational packet, it MAY be processed if local policy allows this. If the packet is a new Main Mode or Aggressive exchange, then it is processed normally the other end might have rebooted, and this is starting new exchange.
In this case, the initiator still changes both ports to The responder uses an algorithm identical to that above, although in this case Y will equal , as no port translation is happening. A different port change case involves out-of-band discovery of the ports to use. Those discovery methods are out of the scope of this document. For instance, if the responder is behind a port translating NAT, and the initiator needs to contact it first, then the initiator will have to determine which ports to use, usually by contacting some other server.
This is similar to the responder rekey case above in that the ports to use are already known up front, and no additional change has to take place. Also, the first keepalive timer starts after the change to the new port, and no keepalives are sent to the port If there is a NAT box between hosts, normal tunnel or transport encapsulations may not work. Sending the Original Source and Destination Addresses To perform incremental TCP checksum updates, both peers may need to know the original IP addresses used by their peers when those peers constructed the packet see [RFC], section 2.
For the initiator, the original Initiator address is defined to be the Initiator's IP address. The original Responder address is defined to be the perceived peer's IP address. For the responder, the original Initiator address is defined to be the perceived peer's address. Then, the peers start sending UDP packets to each other.
This is generally true of UDP, but especially true here. Our laptop and workstation are now listening on fixed ports, so that they both know exactly what ip:port to talk to. The corporate firewall on the other end blocks the packet, since it has no record of 7. However, Windows Defender now remembers that it should expect and allow responses from 7. Additionally, the corporate firewall now remembers that it should expect responses from 2. Encouraged by the receipt of a packet from the workstation, the laptop sends another packet back.
What do we need to keep in mind when managing firewall-traversing connections? Both endpoints must attempt communication at roughly the same time, so that all the intermediate firewalls open up while both peers are still around.
One approach is to have the peers retry continuously, but this is wasteful. This may sound a little recursive: to communicate, first you need to be able to communicate. Stateful firewalls have limited memory, meaning that we need periodic communication to keep connections alive. If no packets are seen for a while a common value for UDP is 30 seconds , the firewall forgets about the session, and we have to start over. To avoid this, we use a timer and must either send packets regularly to reset the timers, or have some out-of-band way of restarting the connection on demand.
As long as they are stateful and allow outbound connections, the simultaneous transmission technique will get through any number of layers. Well, not quite.
For this to work, our peers need to know in advance what ip:port to use for their counterparts. This is where NATs come into play, and ruin our fun. We can think of NAT Network Address Translator devices as stateful firewalls with one more really annoying feature: in addition to all the stateful firewalling stuff, they also alter packets as they go through. The most common use of SNAT is to connect many devices to the internet, using fewer IP addresses than the number of devices. In the case of consumer-grade routers, we map all devices onto a single public-facing IP address.
NATs let us have many devices sharing a single IP address, so despite the global shortage of IPv4 addresses, we can scale the internet further with the addresses at hand. Your laptop sends UDP packets from This is exactly the same as if the laptop had a public IP. Enter the home router. It knows that From now on, whenever it sees packets that match that mapping, it will rewrite the IPs and ports in the packet appropriately. Only now, the packet is from 2.
It goes on to the server, which is none the wiser. The laptop is also none the wiser, from its perspective the internet magically figured out what to do with its private IP address. Our example here was with a home router, but the same principle applies on corporate networks. The usual difference there is that the NAT layer consists of multiple machines for high availability or capacity reasons , and they can have more than one public IP address, so that they have more public ip:port combinations to choose from and can sustain more active clients at once.
We now have a problem that looks like our earlier scenario with the stateful firewalls, but with NAT devices:. Worse, strictly speaking there is no ip:port until the other peer sends packets, since NAT mappings only get created when outbound traffic towards the internet requires it.
How do we break the deadlock? The main thing we care about for now is the network protocol. So, the server can tell you what ip:port it saw. That way, you know what traffic from your LAN ip:port looks like on the internet, you can tell your peers about that mapping, and now they know where to send packets! We can ignore all of that stuff for address discovery. Incidentally, this is why we said in the introduction that, if you want to implement this yourself, the NAT traversal logic and your main protocol have to share a network socket.
Some NAT devices behave exactly in line with our assumptions. Their stateful firewall component still wants to see packets flowing in the right order, but we can reliably figure out the correct ip:port to give to our peer and do our simultaneous transmission trick to get through. Other NAT devices are more difficult, and create a completely different NAT mapping for every different destination that you talk to.
On such a device, if we use the same socket to send to 5. These are terms that come from early research into NAT traversal. That terminology is honestly quite confusing. More recent research and RFCs have come up with a much better taxonomy.
Second, they came up with words that more plainly convey what the NAT is doing. You might be wondering how 2 kinds of endpoint dependence maps into 4 kinds of cone-ness. The answer is that cone-ness encompasses two orthogonal dimensions of NAT behavior.
One is NAT mapping behavior, which we looked at above, and the other is stateful firewall behavior. If you throw all of these into a matrix, you can reconstruct the cone-ness of a NAT from its more fundamental properties:.
Our simultaneous transmission trick will get through all three variants of firewalls. So, for practical code, we can simplify the table down to:. Back to our NAT traversal. It only takes one of them in the whole path to break our current traversal plans. A lot of NAT traversal code out there gives up and declares connectivity impossible.
We could use a relay that both sides can talk to unimpeded, and have it shuffle packets back and forth. Sort of. There will be a bit more latency, maybe less bandwidth. And keep in mind that we only resort to this in cases where direct connections fail. We can still establish direct connections through a lot of different networks. Additionally, some networks can break our connectivity much more directly than by having a difficult NAT.
No amount of clever NAT tricks is going to get around the firewall eating your packets. So, we need some kind of reliable fallback no matter what. Also in some cases, depending on the level of encryption, the payload and in particular the headers are encrypted when using IPsec ESP mode.
The NAT device cannot change these encrypted headers to its own addresses, nor do anything with them. The NAT device in the middle breaks the authenticity, integrity and in some cases cannot do anything at all with the packet. Additionally, enabling NAT-Traversal on the gateway devices resolves the problem with the authenticity and integrity checks, as they are now aware of these changes.
0コメント