From: Menga, Justin (Justin.Menga@xxxxxxxxxx)
Date: Thu Aug 02 2001 - 23:02:13 GMT-3
Hi,
1. Ensure you are using one-to-one NAT on your Cisco Router for any ESP
traffic. You cannot use many-to-one (in Cisco speak 'overload') on your ESP
traffic, the packet is dropped. Ensure ISAKMP and Checkpoints Topology
protocol (TCP 258 or something) is NAT'ed or PAT'ed to the same one-to-one
global address. If you need to support overload for other applications on
the same global address, then use route maps/acls with your NAT statements
to get around this
e.g.
ip nat pool IPSEC 200.1.1.1 200.1.1.1 255.255.255.0
ip nat inside source list 110 pool IPSEC
ip nat inside source list 120 interface s0 overload
access-list 110 permit esp any any
access-list 120 permit tcp any any
access-list 120 permit udp any any
int s0
ip address 200.1.1.1 255.255.255.0
ip nat outside
2. To simplify your NAT concerns, use Checkpoints UDP Encapsulation
(supported in version 4.1 SP2 onwards on both Firewall and SecuRemote).
This encapsulates the IPSec traffic in UDP port 2746 (or similar), thus
allowing any NAT to work (one-to-one or many-to-one). If the Checkpoint
firewall detects that the ISAKMP source port has changed, then the firewall
steps to UDP encapsulation and somehow notifies the client - however Cisco
NAT devices don't seem to change the source port when PAT'ing, so you need
to FORCE UDP encapsulation). I recommend using SP4 of the client and SP3+on
the firewall as SP4 on the client has a GUI option to force UDP
encapsulation (rather than modifying a C file in prev versions) and SP3 on
the firewall fixes some major issues. However I recommend option 1 above
(UDP encapsulation requires more processing and has higher overhead) with a
Cisco router as you can configure your Cisco router to get around the
one-to-one and pool issues.
3. In both scenarios 1 and 2, REMEMBER the native traffic that reaches your
server on the destination network is addressed from the private address on
the SecuRemote client. Thus your routing topology must route that address
towards your firewall OR you must NAT the source address of decrypted
packets at the firewall before forwarding to the destination to something
that will route back to the firewall. THIS IS THE MOST COMMON THING PEOPLE
FORGET.
Regards
Justin Menga CCIE #6640
Network Solutions Architect
Wireless & E-Infrastructure
Compaq Computer New Zealand
DDI: +64-9-918-9381 Mobile: +64-21-349-599
mailto: justin.menga@compaq.com
web: http://www.compaq.co.nz
-----Original Message-----
From: Tom Daniel [mailto:twdaniel@bellsouth.net]
Sent: Friday, 3 August 2001 12:13 p.m.
To: ccielab
Subject: OT:Checkpoint SecureRemote VPN Client
I am trying to Use checkpoints SecureRemote VPN client from behind a Cisco
Router performing NAT. Has anyone ever gotten this to work? I have followed
many suggestions from newsgroups, etc. However, they do not seem to work.
After a succesful authentication, the Translation fails on the Cisco Router.
I have successfully mapped port 500 as instructed on www.phoneboy.com. If
you have a sample config of the router, I would greatly appreciate it.
thanks,
Again, sorry for the OT but it is a real world problem.......
**Please read:http://www.groupstudy.com/list/posting.html
**Please read:http://www.groupstudy.com/list/posting.html
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:31:44 GMT-3