Whether IPSEC will work with NAT depends on what you're doing
and how you're doing it.
What IPSEC mode are you using? Transport mode: won't ever work.
Tunnel mode: might possibly work.
What IPSEC protocol are you using? AH: won't ever work.
ESP: might possibly work.
What NAT are you using? PAT/NAPT: won't ever work.
true-NAT: might possibly work.
How are you establishing sessions? Manual keying: will generally
work (but is so insecure you're wasting your time) IKE: might
possibly work.
What IKE authentication are you using? Pre-shared secrets: won't ever
work. Raw public keys: won't ever work. Certificates: might
possibly work.
What implementation are you using? True IPSEC: might possibly
work (see above) IPSEC+Vendor-proprietary extensions: might work
in more environments, ask your vendor.
In general, using vendor-interoperable products, you an get
IPSEC to work if you use ESP tunnel mode, true NAT, and your
IKE authentication is based on certificates which are bound
to the client using something other than IP address (such as
rfc822address). However, there is an SPI collision potential
which is unlikely but which can cause failure to interoperate.
The short answer is: no, it probably won't work, why don't you NAT
BEFORE the IPSEC instead?
Second short answer: since you're asking about Checkpoint products
talking to Checkpoint products, ask Checkpoint---they may have done
something to make this work in a proprietary way.
(shouldn't this qualify as the most-frequently-asked IPSEC question?)
jms
Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719
Phone: +1 520 324 0494 (voice) +1 520 324 0495 (FAX)
[EMAIL PROTECTED] http://www.opus1.com/jms Opus One
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
