Re: IP in IP and FW1

[keithcha () clark net]

At 05:36 PM 9/23/97 +1000, you wrote:
Hi

> Hi,
>
> I have been asked to advise on a problem with a RFC1918 subnet that needs
> to communicate with the Internet via FW-1 and NAT. 
>
> A picture is worth a thousand words, so:
>
>                            Internet
>                               ^
>                               |
>     NET1 ------ R1 ---------- R2 ---- FW1------ NET2
>
> The main complication here is that both NET1 and NET2 are using RFC1918
> addresses, and R2 also has the default route to the internet.  Ideally
> Internet traffic from FW1 SecuRemote clients on NET1 would be directed to
> the FW1 and NATed to assigned address space before venturing to the
> internet.
>
> Anyone know if/how IP packets from NET1 can be *encapsulated* in FW1-1

One way would be to change the architecture so that FW-1 would use more
than 2 interfaces and move the segment from net1 and r1 to the firewall's
third interface. 
Otherwise, I don't see how the traffic for net1 would
ever pass through fw-1 unless destined for net2

Of course I may be missing something here ... the day is
still young.

> SecuRemote (as distinct from, and in addition to being encrypted) for
> transport to NET2 and only then turned around to be NATed in FW1-2 before
> finally making it to the Internet (obviously the reverse route needs to
> work too ;-)? 
>
> Taking FW-1 documentation at face value, this may not be doable with just
> FW1 (as they claim to merely encrypt the payload of each IP packet, and
> diligently leave the IP headers untouched - but the documentation appears
> a little vague in this respect). Any contrary opinions and/or experiences
> would be most welcome. 

It is possible that the documentation may be correct here.  I have not read
it and am not a firewall-1 wizard.  Good luck

char


> TIA,
> Neale.
> (another apprentice wizard)
>
> PS: yes, we realise the whole problem would go away by *exclusively* using
> proxys (proxies?) on NET2 or the subnet between R2 and FW1 (or a tunnel
> terminating on NET2), but that's not the question we are grappling with.