vpn access broken after setting up a cluster in high avaliablity

[rmasprey]

Hi Everybody,

We have a client who had a single 3100 series device and vpn worked with L2TP and the windows client no problem, for other reasons we where not able to use the checkpoint client vpn. This solutions has worked perfectly and been in place for a number of years.

We upgraded the client to two 3600 series devices, and setup the cluster in high availability mode, so far everything else is working except the vpn. The VPN worked once when I tested it and now nothing happens.

The internet is on eth1, fw1 x.x.x.98, fw2 x.x.x.99, cluster ip x.x.x.100. which is the ip we always connected to. We sent checkpoint the debug files last night.

I have noticed in testing, when connecting I don't get the normal prompt to enter a user name and password.

Has anybody else had issues with L2TP vpn connectivity in a high availability cluster ? My colleague has had no issues at other sites with a similar setup but those sites are using the checkpoint vpn software to connect.

[Chris_Atkinson]

Were there other changes such as version involved at the same time, does it work when a specific cluster member is active?

[rmasprey]

Thank you for the reply @Chris_Atkinson ,

I have tried with disconnecting one of the devices, then the other, no luck. I have tried using the IP on each physical firewall, and also no luck.

Same versions on the old and new devices. R81.20 and the same blades are active.

Still waiting on checkpoint support for an update.

[PhoneBoy]

What version of code was it working on and what version is it failing on?
Other than testing the L2TP client, what debug/information did you gather from the gateway?
The following SK might help in terms of debug: https://support.checkpoint.com/results/sk/sk17957 

[rmasprey]

Thank's for the SK @PhoneBoy , we followed sk180488  which checkpoint directed us to. Will try the debug you have suggested and see if that gives us some insight.

We looked through the logs we generated for checkpoint but have not spotted a reason why its failing yet.

[the_rock]

Can you share logs here so we can have a look?

Andy

[rmasprey]

Thanks for the reply Andy, I spoke to my boss he doesn't want me sharing logs in an open forum unless we can make sure none of the public IP information is visible.

I will try to make sure I keep this thread updated once we have found the solution and the steps taken to resolve.

Checkpoint support are normally pretty quick, the client has pro support plus if I am not mistaken. I raised this issue on Friday, the 24th, and still no proper feedback from them. I hope its not other issues in the world causing challenges.

[the_rock]

Thats totally fair, understood. If you can share whatever possible, would help us.

Best regards,

Andy

[D_Schoenberger]

The issue you're describing, where the client could only connect once, sounds very similar to what happens when you have your Link Selection settings set to "Main IP" when the main IP of your cluster is not the IP address your VPN will terminate on.

If you have not already, please collect a tcpdump packet capture on your gateway, filtered only for the public IP address of your L2TP client and share that alongside the debugs for TAC to review.

[CheckPointerXL]

In case like this the client connects in Visitor mode and it disconnects after 60mins in my experience

[rmasprey]

Thank you for your reply. We are still trying to get this resolved with the assistance of checkpoint support. We had a remote session this morning with a T3 engineer who collected some more logs wile I was attempting to connect.

I had a look on the ipsec VPN on the cluster and link selection is set "Selected address from topology table" and the public facing ip is chosen.

[the_rock]

One thing I would do personally is when you examine the logs collected, search for public IP of the client, as well as whatever external IP is they are connecting to and see what you can find.

Not saying that will give you clear resolution, but at least it may "steer" in the right direction.

Best regards,

Andy

[rmasprey]

Thank you to everybody who has commented. Checkpoint Support came back to us last night, it looks like we have a mismatch in encryption.

We re added the clients 3100 to our management server after updating all the ip's to new ones as a possible alternative. Last week checkpoint support removed the device in case it was causing a conflict.

When testing we got the vpn connection but the connection to the lan was not working. After 15 minutes I then started to get a response to a ping to a local device.

Last night I did some changes on the GW, under IPSec VPN, Traditional Mode. The bellow screen shots are from our 3100 device:

Advanced Tab

If I click okay it gives me an error "check one data integrity method", so I have clicked cancel, and if I open it again I get the same.

In my testing last night I cleared the traditional mode on cluster settings as they had all been ticked, then tried to set it to what windows l2pn connection wanted then matched it to what the 3100 showed as we could establish the connection to that device.

The cluster shows the following under Traditional mode IKE Properties:

Under Advanced settings, I have only selected group 2, previously 19 and 20 where also ticked.

The 3600 member's had new IP Addresses assigned to their network ports and we changed the main ip address on the 3100 and unplugged it from the network when we added the virtual Ip addresses on the cluster to match the 3100 ip addresses.

The cluster virtual IP column is what we had on the 3100 device.

In my testing the vpn to the 3100 on a different public ip is working today as it always use to. The vpn to the cluster and the normal public ip does nothing. It almost looks like the policy for the Gateway settings are not applying properly. The 3100 was our main firewall, which was replaced with 2 3600 in high availability mode.

[rmasprey]

Checkpoint T3 support is still investigating the issue. In the Debug the negotiation is failing on phase2, and the other error that is seen is :

TransMatchFailure: prop# 1 propID ISAKMP trans# 1 transID 1 reason <Wrong value for: Authentication Method>
TransMatchFailure: prop# 1 propID ISAKMP trans# 2 transID 1 reason <Wrong value for: Hash Algorithm>

We getting vpn connectivity on the old 3100 no issues, but for some reason the 3600 in cluster mode is giving the above errors.

Checkpoint Support checked through out settings, and we have them set the same as the 3100.