Home page logo

firewall-wizards logo Firewall Wizards mailing list archives

Re: Terminating Secureclient on a private address range
From: stevewillis () optusnet com au
Date: Tue, 19 Sep 2006 10:22:58 +1000

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 

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> 

     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 - 
firewall-wizards mailing list
firewall-wizards () listserv icsalabs com
firewall-wizards mailing list
firewall-wizards () listserv icsalabs com

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]