S2S-VPN issues wrong peer ip ?

[Gurke]

Dear Checkpoint and Community,

we are facing S2S-VPN issues that we are not able to resolve at all.

We have two sites where we want to replace our existing non-Checkpoint firewalls with new Checkpoint Quantum Spark appliances and a Checkpoint management server. Also these sites are currently connected via VPN since fileservers and other stuff is located at the "main office" and the people from the branch need to access it.

In order to replace the existing devices we try to setup the appliances at the main office and try to get VPN to work there so that we know the configuration steps before we do the actual migration/deployment. Since we have an IPv4-block available at the main office, we put a dumb switch behind the ISP router and connected our current firewall and the two Checkpoint firewalls to it giving each device a unique public ip-address from our block. The current setup is like folllows (left the current working non-Checkpoint firewall out, since it doesn't matter; also ip addresses have been changed for privacy reasons):

Since the management server is behind the 2000 Appliance, we needed to add the 2000 Appliance it with its local/private ip as the main ip-address to the server, whereas the 1575 Appliance is added with its external/public ip. For this we also added the NAT-rule to the management server object, as described in the documentation:

Internet connection and connection to the management server is working. However when we want to setup a meshed S2S-VPN community (domain based vpn) for the 3 networks 192.168.42.0/24, 192.168.199.0/24 (mainoffice-gateway) and 192.168.99.0/24 (branch-gateway) it is not working. I suspect this is because the mainoffice gateway is added to the management server via its local address and the remote peer wants to connect to that local address. Even though we configured link selection:

It looks like these settings are ignored since "SmartView Monitor" shows the "Peer IP" for the tunnel direction branch-gateway->mainoffice-gateway as the local ip 192.168.42.13 instead of the external ip. Also sometimes the tunnel comes up for a short amount of time and its possible to e.g. ping from mainoffice to branch network but later goes down with an log message e.g.:

The routing tables at the two devices are as follows:

Mainoffice gateway "show route" output:
The 192.168.199.0/24 network is not shown since nothing is connected to the interface at the moment, however you can ping the interface 192.168.199.254 from e.g. 192.168.42.0/24:
S 0.0.0.0/0 via 100.0.0.1, WANX1, cost 0, age 9740
C 127.0.0.0/8 is directly connected, lo
lo
C 192.168.42.0/24 is directly connected, LAN1
LAN1
S 192.168.99.0/24 via 100.0.0.6, WANX1, cost 0, age 9740
C 100.0.0.0/28 is directly connected, WANX1
WANX1

Branch gateway "show route" output:
The 192.168.99.0/24 network is not shown since nothing is connected to the interface at the moment, however you can ping the interface 192.168.99.254 from e.g. the gateway itself:
S 0.0.0.0/0 via 100.0.0.1, DMZ, cost 0, age 423
C 127.0.0.0/8 is directly connected, lo
lo
S 192.168.199.0/24 via 100.0.0.2, DMZ, cost 0, age 423
C 100.0.0.0/28 is directly connected, DMZ
DMZ

There is also a firewall policy installed on the two gateways that allows all traffic from and to the networks specified in the VPN domain / community settings.

Am i missing something here or is it simply not possible to have this kind off setup. Any suggestions where to look next or what could be the issue are welcome since i am completely lost now.

Thanks in advance. Kind regards,

[PhoneBoy]

Are both gateways actually on the same network?
Does that also apply in the real environment you're trying to replicate?
In the real environment, is the management server actually behind one of the gateways, as shown here?

As far as more debugging on the issue: https://support.checkpoint.com/results/sk/sk62482 

[Gurke]

> Are both gateways actually on the same network?

No (besides from the WAN interfaces as shown in the picture).

> Does that also apply in the real environment you're trying to replicate?

The real environment will be the "branch gateway" moved to the branch (different geographical location) but the management server stays in the main office behind the maingateway as depicted above.

> In the real environment, is the management server actually behind one of the gateways, as shown here?

yes

[the_rock]

Excellent explanation @Gurke 

Personally, I would do vpn debug and examing vpnd* and iked* files from $FWDIR/log dir

vpn debug truncon

vpn debug ikeon

-generate some traffic (wait 1 or 2 mins)

vpn debug ikeoff

fw ctl debug 0

Check the files I mentioned.

Hope that helps.

Andy

[Gurke]

Thanks a lot to both of you. Will give this a shot.

However is this "normal" behaviour that the gateways ignore the "link selection" settings or does it only look like they ignore it.

Thanks again and have a nice day.

Kind regards,

[the_rock]

Its not normal behavior, for sure, it should not happen.

Andy

[the_rock]

Hey,

I just had a look at the set up large hospital I often work with has and attached is exactly how they have it configured (example from my lab, but you get the idea). They have vpn tunnels with so many different vendors, I have not heard about any issues in few years...hope I did not jinx it now lol

Andy

Andy

[G_W_Albrecht]

Did you contact CP TAC for help already ?

[Gurke]

No, just wanted to make sure first that i am not missing something easy/simple or the whole setup is not supported kind of stuff, etc. But will do this then. Thanks.

[Lesley]

Trial and error the settings on the right window. -> link selection - source IP address settings. And see if this makes any difference.

Make sure to change it and push policy to both. 

You can also try this parameter on CLI, note this is for normal GAIA only and this is GAIA embedded. So this tip is best effort!

https://support.checkpoint.com/results/sk/sk160672

[Gurke]

Thanks alot all.

Was able to reproduce the failure consistently. If the branch gateway is e.g. rebooted, the tunnels fails to establish no matter what link selection settings are applied. However if the main gateway is rebooted the tunnel builds up correctly afterwards. So it is probably the issue with choosing correct peer ip, even though tried all above suggested and other possible settings that exist =(

Anyway, was able to collect the logs with your guidance from above and my boss will open case with CP-support. If the issue will be revealed / solution is found, i will let you know in this post so it may help some1.

Anyway thank you all alot.

Kind regards,

[the_rock]

Please do that. In the spirit of this amazing community, we always post solutions to any issue, as it helps a LOT of other people.

Thanks!

Andy

[the_rock]

I was talking to one of my colleagues who teaches CP CCSA/CCSE and told him about this issue and he asked me to have you check below guidbedit settings and make sure they are set to FALSE. Though, I believe they should be, but just to be positive. In the old days, this was related to supernet, though since R80 came out few years ago, I had not seen it as much.

Andy

ike_enable_supernet

ike_p2_enable_supernet_from_R80.20

ike_use_largest_possible_subnets

[G_W_Albrecht]

Look into this SK sk101219: VPN features in R80.x and R81.x versions