cluster is using the physical IP address instead of cluster IP address

Advanced search

[CPbier]

Is there any reason why a CP cluster might use its physical IP address instead of cluster IP address suddenly when negotiating it's VPN?
Link selection is configured properly and this happens only with one particular VPN which terminates on this cluster. I started a "vpn debug trunc" and the resulting vpnd.elg file shows the below

Code:

[vpnd 740 3060224]@ttn[26 Feb 17:04:56] tnlmon_db_get: Failed to get gateway = 10.10.10.10, type = 257 values
[vpnd 740 3060224]@ttn[26 Feb 17:04:56] GotALifeSign: object IP 10.10.10.10 does not exist in database, ignoring peer
[vpnd 740 3060224]@ttn[26 Feb 17:05:00] UDPProtocol::NewConnection: Entering...

To troubleshoot this further I would like to know at which stage this is happening.
The ike.elg does not show any problems...

I also noticed that SA's are there for both sides and new ones are being made all the time. There 60's SA's per gateway which is not normal.

Z.

[CPbier]

To be more specific the huge amount of SA's are all IPSec SA's.
The IKE there are only 2 per gateway (in and outbound).

[juve]

What are the link selection settings?

[CPbier]

On both sides they have been set to main at first (vpn is using the main interface) and after it was set to "selected address from topology table" and the correct ip was selected.
The "Source IP address setting" was configured the same.
The "Link selection - responding traffic" under the setup button was set to "Reply from the same interface".

I just noticed the following weird behaviour.
At this moment the firewall with physical address 10.10.10.219 is the VRRP master.
The cluster IP is 10.10.10.218 and the physical address of the VRRP slave is 10.10.10.220.
Now check the below communication on the other VPN endpoint (taken from the vpnd.elg)

[vpnd 25743 3060224]@ttn[27 Feb  9:34:58] TunnTest_packet_arrived : entering ...
[vpnd 25743 3060224]@ttn[27 Feb  9:34:58] TunnTest_packet_arrived: packet_type = 1
[vpnd 25743 3060224]@ttn[27 Feb  9:34:58] send_packet : could not send tunnel test packet, error = 49
[vpnd 25743 3060224]@ttn[27 Feb  9:34:58] tnlmon_db_get: Failed to get gateway = 10.10.10.218, type = 257 values
[vpnd 25743 3060224]@ttn[27 Feb  9:34:58] GotALifeSign: object IP 10.10.10.220 does not exist in database, ignoring peer

Weird!!!!

[juve]

Are all tunnels setup from 10.10.10.220? Is this a natted address towards a public IP or are all VPN's private?

[CPbier]

Are all tunnels setup from 10.10.10.220?

Yes they are, or at least they should.

Is this a natted address towards a public IP or are all VPN's private?

No I changed it to 10.10.10.x to use it on this forum.
So 10.10.10.x can be considered a public IP address.
The VPN is meant to be a backup link for a leased line between 2 branch offices.

Z.

[juve]

hmmmmz difficult to tell without cpinfo/cst what could be the problem.

What are the versions of the firewalls/IPSO?

[CPbier]

IPSO 4.2-BUILD042_HF003 releng 1515
This is Check Point VPN-1(TM) & FireWall-1(R) NGX (R62) - Build 120

At the moment I have some guru on the phone from CP
Let's see how far we get

[juve]

I hope you mean TAC Israel and I do hope you get lucky with the engineer 

[juve]

Did it work out with the TAC engineer?

[CPbier]

No it didn't.
I think the engineer is good enough but the problem seems not logical.
He requested kernel debugs and an fw monitor of all traffic.
All these things together gives the fw just enough cpu time to allow my ssh connection. 
I will need some maintenance window to do all these things.

Z.

[CPbier]

Ok, the problem is at R&D now.
A case at Nokia was opened as well without results.


Z.

[CPbier]

The problem is still @ CheckPoint and Nokia without any progress (on their side) but I have noticed some weird things.
Each VPN peer has 2 routers behind it's internal interface.
Those routers try to setup a GRE tunnel with the other side, so they sent out GRE traffic continuously to the other router behind the other VPN peer.
router A sends GRE to router C
router B sends GRE to router D

Code:

routerA----+                                                     +----routerC
           +-----VPN1 clusterA----(Internet)----VPN1 clusterB----+
routerB----+                                                     +----routerD

What we did to make it work:
- execute "shut" for each GRE tunnel on each router
- delete all ike and ipsec SA's on each VPN1 cluster
- check if theer is any other traffic triggering the setup of the tunnel
- execute "no shut" for each GRE tunnel on each router

Bamm, tunnels are up running!!!

Crazy bug software!
I wonder I will get the same situation again if one of devices gets rebooted or something like that.

Z.

[juve]

Did you change anything to the address selection? I've noticed this behaviour too. You need to shut all vpn traffic and sometimes even clear the connection tables for it to work.

[CPbier]

Nope I didn't change anything at all except the removal of the cookies.
I guess it won't work if permanent tunnel is set to on.

Z.

• Articles
• Knowledge base