This is a discussion on Re: [fw-wiz] Terminating Secureclient on a private address range - Firewalls ; --===============1944102188== Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary 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 ...
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
> On 9/13/06, email@example.com
> > 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
Content-Type: text/plain; charset="us-ascii"
firewall-wizards mailing list