Greetings,
These types of problems tend to be a configuration issue on the Check Point
side for the older releases. We won't get into how Check Point didn't
follow the RFC, and no one else does subnet super netting in Phase II. I'm
just saying from the Check Point's side it's doing what it's always done
between any VPN tunnel. It doesn't matter whether it's a Cisco, Juniper, or
Nortel. This "feature" also been fixed in NGX so that you can explicitly
set the phase two subnets for the tunnel.
A little off topic, but the Juniper firewalls like to do route based VPNs
and the NGX boxes can be setup to use a route based VPN to save some of the
overhead on the Check Point enforcement module.
Jason
On 8/31/06, cisco4ng <cisco4ng AT yahoo DOT com> wrote:
I have a story that I thought I want to share with
everyone so that next time when anyone run into a similar
situation, it will save you time. Here we go.
scenario:
SiteA: Checkpoint NG with AI R55w haf-04 or NG FP3 hfa_327
running on Nokia IPSO 3.7.1
local encryption domain: 192.168.1.0/24
remote encryption domain: 10.29.10.29/32
local VPN endpoint: Nokia External interface 4.2.2.2
phase I & II: aes-256/sha/DH-5
Phase I timeout: 86400 seconds
phasw II timeout: 3600 seconds
siteB: Juniper/Netscreen firewall
local encryption domain: 10.29.10.29/32
remote encryption domain: 192.168.1.0/24
local VPN endpoint: Nokia External interface 199.0.216.222
phase I & II: aes-256/sha/DH-5
Phase I timeout: 86400 seconds
phasw II timeout: 3600 seconds
VPN tunnel comes up. 10.29.10.29/32 can ping 192.168.1.0/24
but network 192.168.1.0/24 can not ping 10.29.10.29. In
other words, one-way VPN.
Upon looking the debug ike.elg file in checkpoint, I found that
during the phase II negotiation (Quick Mode), Netscreen properly
sends its local and remote encryption domain to checkpoint so the
vpn is fine coming from Netscreen. However, whenever traffics
initiated from Checkpoint side, checkpoint sends /32 of its
local encryption domain to Netscreen. For example, let say
host 192.168.1.10 ping 10.29.10.29, checkpoint will renegotiate
Quick Mode of /32. In other words, it sends /32 to Netscreen.
VPN failed whenever traffics initiates from Checkpoint side.
I can see the problem very clearly in the ike.elg file. By the
way, the ike.elg file can be viewed with the IKEView.exe file.
the work around is to add /32 hosts in the remote encryption
domain on the Netscreen side and VPN will work bi-directional.
Hopefully, this will save people time and headache when you run into VPN
issues between Checkpoint and Juniper/NetScreen.
cisco4ng
---------------------------------
Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great
rates starting at 1¢/min.
=================================================
To set vacation, Out-Of-Office, or away messages,
send an email to LISTSERV AT amadeus.us.checkpoint DOT com
in the BODY of the email add:
set fw-1-mailinglist nomail
=================================================
To unsubscribe from this mailing list,
please see the instructions at
http://www.checkpoint.com/services/mailing.html
=================================================
If you have any questions on how to change your
subscription options, email
fw-1-owner AT ts.checkpoint DOT com
=================================================
=================================================
To set vacation, Out-Of-Office, or away messages,
send an email to LISTSERV AT amadeus.us.checkpoint DOT com
in the BODY of the email add:
set fw-1-mailinglist nomail
=================================================
To unsubscribe from this mailing list,
please see the instructions at
http://www.checkpoint.com/services/mailing.html
=================================================
If you have any questions on how to change your
subscription options, email
fw-1-owner AT ts.checkpoint DOT com
=================================================
|
