VPN-1 Checkpoint wrong gateway

Does anybody how does the checkpoint VPN-1 client get the gateway address? Some strange things are happening here. When the pc is connected directly to the modem of the internet provider the vpn-1 connection works fine. When the pc is connected to the private LAN, it can not connect to the vpn-gateway (gateway not responding). The problem is, that the client now wants to connect to a private gateway ip address and not to the official address. And of course it can not reach a private address over the internet.



Reply to
christian maier
Loading thread data ...

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.


Classic NAT-T Problem ...

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


Reply to
Wolfgang Kueter

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)


Reply to

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

Reply to
Robby Cauwerts

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.