Re: ftp-proxy's inability to proxy using arbitrary source ip addresse s

[Adam Herscher <adam@xtime.com>]

On Sat, 9 Mar 2002, Daniel Hartmeier wrote:

> I've never seen anyone use NAT to translate outgoing packet's source
> addresses to something other than the external address of the firewall.
> The router obviously sends packets for 64.1.1.1 to the firewall,
> otherwise the setup wouldn't work at all. Why don't you give the
> firewall's external interface the address 64.1.1.1?

Let's say 64.1.1.1 is part of a /29.  The router routes the entire /29 to
the firewall, which routes it to a network of machines on the inside.  It
would be impossible to actually number the outside interface 64.1.1.1 and
at the same time route the /29 to the other side.  You could break up the
/29, but then you would have significantly less useable addresses.

The next obvious question is if you're routing public IP space, why NAT at
all (which is why a simplified example does not do justice to the issue).
Perhaps your firewall has an outside interface, a dmz interface where the
public IP addresses are routed, and another inside interface where private
IP addresses are used (and must in turn be translated).

> If the router forwards packets with private addresses, it would _have_
> to do NAT itself. If it doesn't, why use private addresses between the
> router and the firewall?
> 
> Daniel

The router doesn't necessarily forward packets with private addresses; it
just routes packets with public addresses over a point to point connection
that uses private addresses.

Using private address space for point to point connections is pretty
common these days.  Whether or not doing so is good practice is a constant
flame war on NANOG, and I already see it's generated some passionate
responses here.  For what it's worth, in the network described above,
using private address space will not cause problems for the following
reasons:

1) ICMP responses are translated to a routed public IP address by pf after
they are generated -- won't break PMTUd.

2) Every link on the network behind the router has the same MTU.

3) Private address space will not show up in an inbound traceroute.

Since I sent out my original email raising the issue yesterday (Friday
afternoon), I did receive a response from someone in the same situation.
ipf used to handle this scenario seamlessly, but pf+ftp-proxy will require
a workaround (perhaps the option to set the source ip address, or to read
the active nat rules and adjust accordingly).

By the way, thanks for taking an interesting in this thread Daniel, and
for all of the hard work you've put in to make pf what it is =)