VPN - Only one way traffic

[NorthernNetGuy]

I have an issue with one my my VPN tunnels only allowing one way traffic. its a B2B tunnel for an APN. My APN connected devices are able to communicate to on site resources over the tunnel, but my on site devices can't communicate with the devices on their encryption domain. (r81.20, 3.10)

Checking the logs I found the following : 

"dropped by fw_ipsec_encrypt_on_tunnel_instance Reason: No error - tunnel is not yet established;"

This VPN is configured as a Star community, the Encryption settings are all correct and match. It is configured as "One VPN tunnel per Gateway Pair",  with VPN routing of "To center or throug hthe center to other satellites..." , and "disable nat inside the vpn community"

We have a few tunnels that probably have poor configurations. Multiple have our encryption domain as 10.0.0.0/8.

My other tunnel are functioning fine. I expect we have a configuration issue that I'm not seeing.

Help is appeciated. Thank you

[Lesley]

Tunnel is Check Point to Check Point?

10/8 is quite big, maybe there is an overlap? 

[NorthernNetGuy]

Tunnel is Checkpoint to unknown from a different business, they wouldn't provide their platform.

10/8 is  huge, but the destination is 172.16.160.0/20, so no overlap within the tunnel.

[Timothy_Hall · Accepted solution]

One tunnel per gateway pair will cause your Check Point as the initiator to negotiate a universal tunnel (0.0.0.0/0,0.0.0.0/0) in IKE Phase 2, which the other side will not usually accept (unless they are configured for route-based VPN which does not appear to be the case).  However when the other side initiates the tunnel they will negotiate specific subnets that are a subset of a universal tunnel, which your Check Point will accept.

Set it to pair of subnets, then on the community members screen override the VPN domains for the two members and make sure they PRECISELY match the peer's config.  Check Point and Cisco will generally accept proposed subsets of their VPN domains, whereas most other vendors will not and silently drop the Phase 2 proposal, leading to the "tunnel is not yet established" error.

After doing this if the problem still exists and you are set for IKEv2, try IKEv1 which tends to be a bit more interoperable. 

[NorthernNetGuy]

Hi Tim,

Thank you for the explanation. Does the gateway pair setting  force IKEv2 even if I have the 'IKEv1 for IPV4 and v2 for ipv6' encryption method? (we dont use 6).

Also does the gateway pair setting, forcing a 0.0.0.0/0 domain, overwrite any VPN domain entered in the gateways section?

I'll validate what the other site has as our encryption domain, and book a window to perform and test this change.  I believe they are using Cisco, but I'll wait for their confirmation.

[PhoneBoy]

The "one tunnel per gateway pair" does not change the actual encryption domain, only what is negotiated with the VPN peer.

[NorthernNetGuy]

Cycling back way later, but finally had a maintenance window and this worked for me, all working as expected now