Thank you everyone for your input. In working with an engineer, it
appears that since I have an interface on the FW configured as a
172.16.0.0 network, this is causing the issue. Please see the
knowledge base blurb below. The resolution we used was to,"Stop VPN-1
SecureClient", open on the client, "C:\Program
files\CheckPoint\SecuRemote\database\userc", search for the
line,"resolve_interface_ranges (True)" and change the "True" to
"False" and save the file. Start SecureClient and try to connect.=20
This worked. The modification below is a change on the firewall and
am not sure at this point if that can be overwritten when changes are
made to the firewall. So for now, we are making the change to the
client, since there are only a few until we confirm that this
attribute won't be changed automatically by the fw.

Thanks again,

This is taken from the Checkpoint secureknowledge DB, sk15830,=20

2) Symptom:"Communication with site fails"
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3 D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D
There can be a few reasons:

a. Key exchanges performed with the wrong interface IP address of the
VPN-1/FireWall-1 Module.

Explanation: By default, the parameter "resolve_interface_ranges" is
"true" in the VPN-1/FireWall-1 Module's objects_5_0.C file. This
parameter enables the module to send its topology data to the Client
during topology download. In a situation with private IP networks,
SecuRemote/SecureClient may attempt and exchange keys with the wrong
interface IP address (private instead of public).

Workaround: Set the parameter "resolve_interface_ranges" to "false" in
objects_5_0.C file.


On 7/20/05, David West wrote:
> Sounds like your ike/udp is fragmenting somewhere between the client
> and your firewall. This almost always occurs with x.509 certificate
> authentication as the cert is too big for a standard Ethernet frame
> and dropeed by many cable/dsl routers. Try using ike/tcp. On your
> gateway(s) enable support IKE over TCP in global properties and by
> enable the following on in SecureClient for your sites profile:
>=20
> + Connectivity enhancements
> + Use NAT traversal tunneling
> - IKE over TCP
> - Force UDP encapsulation
>=20
> David
>=20
>=20
> -----Original Message-----
> From: QTR [mailto:tmwhitm@gmail.com]
> Sent: Wednesday, 13 July 2005 12:09 AM
> To: firewall-wizards@honor.icsalabs.com
> Subject: [fw-wiz] Checkpoint VPN
>=20
>=20
> Hello, I was wondering if someone could point me in the right
> direction. I have come off a long run of managing Cyberguard
> firewalls and am now in the Checkpoint realm, so forgive my ignorance.
> I am having an issue with secure client. I have several SoHo users
> whose default routers place them on a 172.16.0.0 network. These users
> cannot connect to the gateway. Dumps on the checkpoint fw gateway
> show no incoming packets and a dump on the client show udp 500 leaving
> the client, which leads me to the router/firewall @ the SoHo. Router
> makes vary, anywhere from 2wire to netgear, the result is the same. I
> initially thought it had something to do with the routing topology
> since our topology pushes a static route for a 172 network, but I had
> the SoHo router changed to a 10 network that is statically routed in
> the topology and that worked fine. At this point I am at a loss. Any
> suggestions would be appreciated.
>=20
> Thank you,
> _______________________________________________
> firewall-wizards mailing list
> firewall-wizards@honor.icsalabs.com
> http://honor.icsalabs.com/mailman/li...rewall-wizards
>

_______________________________________________
firewall-wizards mailing list
firewall-wizards@honor.icsalabs.com
http://honor.icsalabs.com/mailman/li...rewall-wizards