Fake address for NAT connection support (IPv4)

My ISP assigns me a public static IP address but for my gateway
machine's WAN connection they give me a static RFC1918 address. They
must do some static transformation of my packets at their end, mapping
between the RFC1918 address and the public address.

This messes up my ability to use connection tracking to support
protocols that cross my gateway's IP masquerading: it's putting the
wrong address into the protocols when it rewrites the content.

Is it possible to have it write the public IP address into them somehow?
I can imagine I can do it if I give its WAN interface the public
address, then have another not-connection-tracking 'outer gateway'
between the gateway and my ISP that does the reverse of the
transformation they do.

But, can I achieve the same effect without needing another machine?
(Or another ISP. (-:)

-- Mark

Mark T.B. Carroll wrote:
> My ISP assigns me a public static IP address but for my gateway
> machine's WAN connection they give me a static RFC1918 address. They
> must do some static transformation of my packets at their end, mapping
> between the RFC1918 address and the public address.

So they are doing NAT from the RFC 1918 address to the public address.

> This messes up my ability to use connection tracking to support
> protocols that cross my gateway's IP masquerading: it's putting the
> wrong address into the protocols when it rewrites the content.

Why?

If your traffic is outbound, you put the WAN address into the
outbound packets and into the great world they go. In the
same way, the reply packets get translated by the ISP and you
can re-translate from the WAN RFC 1918 address into your own
internal addresses.

There's a limitation: Your internal network must not use
a RFC 1918 address conflicting with the ISP's address.

The system limits your inbound traffic, so it may be more
difficult to have a server at your connection - and precisely
this may be the base cause of the address translation at
the ISP.

If the ISP's address translation is pretty constant and one-to-one,
a dynamic DNS solution might work (e.g. http://www.dyndns.org/).

> Is it possible to have it write the public IP address into them somehow?
> I can imagine I can do it if I give its WAN interface the public
> address, then have another not-connection-tracking 'outer gateway'
> between the gateway and my ISP that does the reverse of the
> transformation they do.
>
> But, can I achieve the same effect without needing another machine?

Not that way.

> (Or another ISP. (-:)

A suitable bunch of money might make the miracle
with your current ISP also.

--

Tauno Voipio
tauno voipio (at) iki fi

Tauno Voipio <tauno.voipio@INVALIDiki.fi> writes:

> Mark T.B. Carroll wrote:
>> My ISP assigns me a public static IP address but for my gateway
>> machine's WAN connection they give me a static RFC1918 address. They
>> must do some static transformation of my packets at their end, mapping
>> between the RFC1918 address and the public address.
>
> So they are doing NAT from the RFC 1918 address to the public address.

Yes.

(snip)
> If your traffic is outbound, you put the WAN address into the
> outbound packets and into the great world they go. In the
> same way, the reply packets get translated by the ISP and you
> can re-translate from the WAN RFC 1918 address into your own
> internal addresses.

Unfortunately, they don't rewrite protocols (e.g., for active FTP) in
their translation: not being protocol-content-aware, their translation
is not transparent. It's the correct rewriting I want (achieved with
some of the CONFIG_IP_NF_* options) but if I do that naively with the
RFC1918 address on my WAN interface it'll be wrong.

> There's a limitation: Your internal network must not use
> a RFC 1918 address conflicting with the ISP's address.

Indeed it doesn't.

(snip)
> If the ISP's address translation is pretty constant and one-to-one,
> a dynamic DNS solution might work (e.g. http://www.dyndns.org/).

Yes, it's constant and one-to-one.

(snip)
> A suitable bunch of money might make the miracle with your current ISP
> also.

True. They seem to be sort of intending to getting around to fixing it
anyway, although I'm not holding my breath.

-- Mark

Hi Mark -

On Tue, 27 Mar 2007 11:00:01 -0400, Mark.Carroll@Aetion.com (Mark T.B.
Carroll) wrote:

>But, can I achieve the same effect without needing another machine?
>(Or another ISP. (-:)

With my DSL modem the default configuration was to function in NAT
mode, however it was easy to change it to bridge mode, which allowed
my own Linux-based router to have my public static IP address on the
WAN interface.

--
Ken
http://www.kensims.net/

Ken Sims <ng3122@kensims.#nospam#.net.invalid> writes:

> Hi Mark -
>
> On Tue, 27 Mar 2007 11:00:01 -0400, Mark.Carroll@Aetion.com (Mark T.B.
> Carroll) wrote:
>
>>But, can I achieve the same effect without needing another machine?
>>(Or another ISP. (-:)
>
> With my DSL modem the default configuration was to function in NAT
> mode, however it was easy to change it to bridge mode, which allowed
> my own Linux-based router to have my public static IP address on the
> WAN interface.

Unfortunately, I can't currently do that with my ISP: to get my traffic
in and out I /have/ to have on my WAN interface the RFC1918 static
address they assigned to me. If I could have my public static IP address
on the WAN interface there'd be no problem whatsoever. (So I was
wondering if I can have the protocol-content-rewriting work as if my WAN
interface had a different IP to what it actually does.)

-- Mark