VPN-1 Checkpoint wrong gateway

It simply uses the routing table. 'netstat -rn' or 'route print' tells you, how it looks like.

No, the effects you observe are pretty normal when running a VPN client behind a NAT gateway.

OK.

Classic NAT-T Problem ...

IPSeC and NAT can be a bit of a problem ...

Wolfgang

you can create a rule to say when traffic from xx going to yy keep the original source and destination address (ie. do not nat this packet)

Flamer.

Nope, the vpn client looks up the vpn gateway topology in the userc.C file under: "C:\\Program Files\\CheckPoint\\SecuRemote\\database"

Does your private LAN ip address falls into a subnet located behind the vpn gateway? If yes: the vpn client looks into the userc.C and thinks that he's direclty connected on a subnet behind the vpn gateway and will try to connect to the ip address of the firewall on that subnet instead of the public ip.

sk sk15830 will give you more information about this:

"Symptom:"Communication with site fails"

There can be a few reasons:

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. "

Br. Robby