IPFIREwall

Index
Homepage di Giacomo.
Scenarios index.

Scenario 5.
Destination nat: connection redirected from external host X to internal ssh server Y.

158.110.144.168->80.104.111.96:222 becomes 158.110.144.168->192.168.0.2:22

External host primergy.dimi.uniud.it contacts ssh server on 80.104.111.96, port 222. Really, connections towards port 222 in network gateway are IPFIRE-redirected to an internal ssh server on 192.168.0.2. So, external node will communicate with the internal host 192.168.0.2, port 22. This is a failry frequent case in which one wants to redirect connections towards an internal server, e.g. a web or DNS server.
In the picture below you can see what happens. Note that 192.168.0.2 sees traffic as coming from the real external host, and responds to it directly, always passing through IPFIRE gateway, of course (a port de-dnat translation is still needed).
This kind of external - internal translation differs in behaviour if compared to internal - internal one: the former requires a step less than the latter. This is due to the fact that in every case internal host that is contacted by an external one responds through the gateway and the external machine always talks towards external IP gateway's address. In internal redirection instead, if A talks to B and gets redirected to C, A waits for answers from B, not from C. At the same time, C needs to talk to B, it does not know that connection was setup by A.

Ipfire output, scenario 5

In the picture above, you can see what happens in IPFIRE destination nat.

Valid XHTML 1.0!

Top of page
Back to index
Next page (Scenario 6)
Previous page (Scenario 4)