VPN-1 Checkpoint wrong gateway

VPN-1 Checkpoint wrong gateway

am 27.05.2007 12:55:12 von Christian Maier

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.

Thanks.

Christian

Re: VPN-1 Checkpoint wrong gateway

am 28.05.2007 02:28:01 von Wolfgang Kueter

christian maier wrote:

> Does anybody how does the checkpoint VPN-1 client get the gateway
> address?

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

> Some strange things are happening here.

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

> When the pc is connected directly to the modem of the internet provider
> the vpn-1 connection works fine.

OK.

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

Classic NAT-T Problem ...

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

Wolfgang

Re: VPN-1 Checkpoint wrong gateway

am 28.05.2007 03:32:33 von flamer

On May 27, 10:55 pm, christian maier wrote:
> 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.
>
> Thanks.
>
> Christian

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.

Re: VPN-1 Checkpoint wrong gateway

am 28.05.2007 17:27:13 von Robby Cauwerts

On May 28, 2:28 am, Wolfgang Kueter wrote:
> christian maier wrote:
> > Does anybody how does the checkpoint VPN-1 client get the gateway
> > address?
>
> It simply uses the routing table. 'netstat -rn' or 'route print' tells you,
> how it looks like.
>

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

> > 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.
>
> Classic NAT-T Problem ...
>

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