VPN S2S from CP 1550 to FG 30E not PING

[luk89as]

Hello,

I have a configured and active VPN tunnel between CP 1550 and FG 30E (VPN Site to Site)

The tunnel is active with FG I can ping and access the network on the Checkpoint side. However, I cannot ping from Chackpoint to Fortigate.

I attach entries in the firewall in the post.

[G_W_Albrecht]

Why the second Outgoing Rule - Source behind FG target CP ??? And i see no rules defined in incoming & VPN traffic, so i wonder how this should work ?

I would just follow Quantum Spark 1500, 1600 and 1800 Appliance Series R80.20.25 Locally Managed Administration Guide pp.26ff !

[luk89as]

I'm sending an additional screen.

I don't know how to set up static routing from CP1550 to VPN.

I don't know VPN in static routing settings - next hop

[G_W_Albrecht]

Just follow the admin guide - i think your manual rules are wrong... Usually, no manual routing is needed as we have a VPN community.

[G_W_Albrecht]

This is part of my rulebase from 1550, Policy normal, VPN working:

[luk89as]

Hello,

As you saw on the screen sent by me, I have the same rules.

With time, I added manually the ones that you can see.

Since I can ping from the FG 30E side, the Checkpoint network (I have access to LAN) insists that IKE Phase 1 and Phase 2 are ok on both sides.

It looks like the CP 1550 is not letting traffic into the VPN tunnel from its LAN, although the LOGs show that traffic is entering the tunnel but no response.

I also don't understand that I am getting an error on my VPN test.

If I had an error in IKE Phase 1 or Phase 2 configuration, the connection would not be active and I certainly wouldn't be able to get from the FG 30E LAN to the CP 1550 network.

[Timothy_Hall]

When the Check Point attempts to initiate the tunnel to Fortigate the proposed subnets/Proxy-IDs in IKEv1 Phase 2 must PRECISELY match how the Fortigate is configured, whereas if the Fortigate initiates the tunnel the Check Point will accept a subset of the Phase 2 subnets in lieu of a precise match and still allow the VPN tunnel to start.  There have been numerous prior CheckMates threads about this, see scenario #1 of  sk108600: VPN Site-to-Site with 3rd party

[luk89as]

Hello,

So I have to execute the command in the console: disabling the R80.20 "disable supernetting per community

---
This new feature will still work once ike_enable_supernet is set to "true".

Access the relevant gateway.
Run fw ctl set int enable_supernet_per_community 0
Note: It can take some time until user.def tables start to take effect, as current connections can still invoke tunnels using the old ranges.

In order to save this change after reboot of the gateway, set this configuration variable: "enable_supernet_per_community = 0" in the $ FWDIR / boot / modules / fwkern.conf file of the gateway.

---

This also applies to my firmware

R80.20.20 (992001869)

[G_W_Albrecht]

There is also an Advanced Setting that may help:

[luk89as]

Hello,

The setting you suggest is already running. It didn't change anything.

I still have FG to CP traffic but no CP to FG traffic.

Could I only have the option to edit the crypt.def file and change the ike_enable_supernet is set parameter to "true".

Will I do it via the console? However, am I forced to set up a GAIA server?

[G_W_Albrecht]

No, you have to uncheck the option ! This is the default and makes trouble with some 3rd party GWs...

[luk89as]

I turned off the option according to your recommendation, but still unchanged.

Network traffic from FG to CP - works

Network traffic from CP to FG - not working

When performing the test, I still get the error: Conecction to remote site filed

Do you have any more ideas?

[Timothy_Hall]

Read my last post again.  The IKE Phase 2 subnet proposals from the CP must exactly match those on the Fortigate or it will silently discard your Phase 2 proposal and appear to not be responding.  You need to set subnet_for_range_and_peer.

[G_W_Albrecht]

The only way forward is to contact TAC to resolve this issue - locally managed SMBs can not set subnet_for_range_and_peer in user.def. You can try crypt.def, but it does not contain these lines:

#ifndef __user_def__
#define __user_def__

//
// User defined INSPECT code
//

#endif /* __user_def__ */