NATD problem

[David DeSimone]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Patrick Oonk <patrick.oonk at ictu.nl> wrote:
>
> host A
> -redirect_address 192.168.0.2 128.1.1.2
> 
> Host B
> -redirect_address 192.168.0.3 128.1.1.3
> 
> I have a webserver running on host A.
> When I try to reach either host A the 'outside', that works fine.
> 
> When I try to reach host A from host B on it's external address,
> i.e. when I try to reach port 80 on 128.1.1.2 with source address
> 192.168.0.3, I get 'connection refused'.
> 
> Do I have to do anything special to make this possible?

This is a classic NAT problem.  Picture what happens each step of the
way:

    Packet (src = 192.168.0.3, dst = 128.1.1.2) goes to the firewall,
	because routing for 128.1.1.2 follows default route to firewall.

    Firewall applies NAT, so packet is now (src = 192.168.0.3, dst =
	192.168.0.2).  Firewall routes the packet back to the internal
	network that it came from.

    Host A receives packet (src = 192.168.0.3, dst = 192.168.0.2).

    Host A sends back a reply packet (src = 192.168.0.2,
	dst = 192.168.0.3).  Routing table finds a connected route, so
	reply goes DIRECTLY to host B over internal network.  Firewall
	does not see reply, so there is no chance to apply reverse NAT.

    Host B receives packet (src = 192.168.0.2, dst = 192.168.0.3).  The
	packet is unrecognized, however, because the packet that host B
	originally sent was for (src = 192.168.0.3, dst = 128.1.1.2). 
	Host B sends a RST.  Connection fails.

The way I have solved this problem in other environments is with "double
NAT" where the firewall translates both the Source and Destination IP
for internally-receive traffic.  The firewall applies the correct
destination NAT, but also applies NAT to the source IP, giving its own
IP.  This causes the web server to reply back to the firewall so that
the traffic can be de-NAT'd correctly.

However, I am unaware of the ability to perform Double NAT using FreeBSD
tools.  There is no reason the kernel could not do it; it is just a
missing feature in the toolset.

Many people argue that Host B should "know" that it should not contact
Host A using the external IP.  Either a host file, or special internal
DNS server, or some other such mechanism should help internal hosts to
know how best to contact other internal hosts.

- -- 
David DeSimone == Network Admin == fox at verio.net
"This email message is intended for the use of the person to whom
 it has been sent, and may contain information that is confidential
 or legally protected.  If you are not the intended recipient or have
 received this message in error, you are not authorized to copy, dis-
 tribute, or otherwise use this message or its attachments.  Please
 notify the sender immediately by return e-mail and permanently delete
 this message and any attachments.  Verio, Inc. makes no warranty that
 this email is error or virus free.  Thank you."  --Lawyer Bot 6000
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFHhUoaFSrKRjX5eCoRAnoUAJ9jv4zBy6MeYXJZQryTi2jIM0yfsACbBs3x
EOIg9lwBVJd9EaMCJ/oxFCw=
=Y28j
-----END PGP SIGNATURE-----