The DNAT-mistake page

I don't know how many times this problem has emerged in various forums I visit, but it's more than 6 and less than 30. Since it can be hard to understand, I made this page to explain, why

DNAT does not work from the LAN side!

This is how it usually goes: You try to run an ftp server or a web server and tell your router to forward the neccessary port (usually 21, 80 or 25, depending on what service you run) to your server machine. It works fine from the outside, but does not work from the LAN side. Packets just seem to vanish, you get no answer whatsoever - not even a refused connection.

To illustrate whats going on, I have taken the liberty to draw some graphics. First let's see, what happens, when you

Try to open a connection from the internet

Say you are running a SMTP mail server and try to open a connection to the server. You create a packet and send it to the host you think is the server:

The packet is sent to the apparent server

But it is not the server, it's just a router, that rewrites the packet destination according to its forwarding rule:

The server turns out to be a router, doing DNAT

Since the new destination host is on the LAN, the router must forward the packet there:

The packet is forwarded to the real server on LAN

The mail server accepts the connection and constructs a response packet by switching the destination and the source. It sends the packet out. However, as the destination is not on the LAN, the packet must be sent out through the router:

The response packet is sent to the router

The router notices that the packet is a response packet to a connection it is currently forwarding and thus changes the destination field to the original source field, forwarding the packet to the Internet:

The response packet is unNATted and sent to the client somewhere on the net

The packet reaches the original sender that is pleased to see an answer packet. The connection has been established and mail sending may commence:

The client is exhiliarated for seeing a response packet and data transfer commences

Now, it does not always work out that great, for example, when

Sending a packet from the LAN

At first, it works quite similarily. A new packet is constructed and sent to the "presumed" mail server:

The packet is sent to the apparent server

The destination NAT also works similarily, changing the destination address and forwarding the packet to LAN:

The packet is forwarded to the real server

Now we get to the tricky point. You would imagine, that the response packet (the one that has the source and destination switched) would go back the same way it did when we opened a connection from the internet. Well, guess again. Look at the packet. The destination is on the LAN this time. There is no point to bother the router about it:

The response isn't sent back through the router

Instead, we send it back directly, straight to the original source:

UnNATting doesn't take place, the packet is sent straight to the client on the LAN

This, however, it's not okay. The original source does not recognise the answer packet. It did not send a packet to 192.168.0.1, it sent the packet to 12.0.0.1! "This is a mistake," it presumes and discards the packet:

The client doesn't recognize this connection and discards the response packet

Luckily, there is a way to fix this behaviour

Using source NAT

You need to make sure, that your packet traverses thorugh the router on it's way back as well. If your router supports this functionality, you must tell it to change the source address to it's own address at the same time when forwarding the packet to LAN. Some routers might do it by default, but I haven't seen any.

I also haven't seen any, that allow you to configure source NAT at all, so reading this page was propably a huge waste of time. Sucks, doesn't it?