Re: Terminating Secureclient on a private address range

[stevewillis () optusnet com au]

HI Martin,

     Thanks for  your reply, I will research some of these articles for future reference as I didn't think this would 
work. The only reference I found before was based around an unsupported workaround by Check Point, I don't have it to 
hand (its at home, but I will post a reference to it once I get home)

Here is the response I received from Nokia


IPSec and NAT are inherently not compatible protocols, as IPSec protects the packet's integrity, whereas NAT changes 
the IP header and TCP/UDP header. If both IPSec and NAT operations are supported in the same security device (like 
Check Point), then the problem can be avoided by performing the NAT operation before doing IPSec and making sure that 
the IPSec end-points are in the public address space.

For scenarios where there is a NAT device in-between (NAT-in-the-middle problem), the IPSec standards group at IETF has 
proposed a new protocol called "NAT traversal (NAT-T)". Here, the IPSec packet is encapsulated within a UDP packet 
using the IKE UDP port 500. Negotiation of NAT-T support of the peers as well as detection of NAT presence in the path 
is done during IKE phase-I.

So, if your ISP router can provide NAT-T functionality then it's possible but it will add complexity and performance 
will be little slow as there will be twice the encryption (Packet to IPSEC + IPSEC to UDP). I would suggest to use 
valid IP addresses like your current setup to avoid issues (performance and connectivity).



After discussions with the ISP it transpires that they are now going to give us public addresses for our external 
interfaces. 


Many thanks to everyone who passed on advice






> Martin Hoz <martinhoz () gmail com> wrote:
>
> On 9/13/06, stevewillis () optusnet com au <stevewillis () optusnet com au> 
> wrote:
> >      Thanks for the input, unfortunately I'm running NGAI R55 HFA17
>
> You still should be able to put a "fake" external interface on your
> topology, enable
> dynamic interface resolving and get into business as a known workaround.
>
> As well, If you search for "SecuRemote" and "NAT" on SecureKnowledge
> you will find a few articles talking about this type of scenario. I've
> tried myself some of those tricks
> and they work ;-)
>
> Good luck!
>
> - Martín.
>
> -- 
> **** ¿Hoy qué haz hecho para ahorrar agua? - What have you done today
> to save water? - O que você têm feito hoje para conservar a água?
> ** Mi página web: http://gama.fime.uanl.mx/~mhoz/
> * "Somos consecuencia del pasado, y causa de nuestro futuro."
> ** My Linux - http://www.slackware.com == My BSD - 
> http://www.openbsd.org
> _______________________________________________
> firewall-wizards mailing list
> firewall-wizards () listserv icsalabs com
> https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
_______________________________________________
firewall-wizards mailing list
firewall-wizards () listserv icsalabs com
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards