VPN community routing not working

[isuckatthis]

Hello smarter than I people!

I have a Checkpoint to Checkpoint VPN. We're using a community. The traffic gets to the Checkpoint FW VPN concentrator and is not routed across the VPN.

How do I troubleshoot this?

The encryption domain on the remote side shows the correct subnets.

I've attached images showing the community, logs showing the traffic is not encrypted, a traceroute showing the FW is sending the traffic back to the router then the router back to the FW then the FW back to the router until the end of time (or TTL expires).

I have no idea how to troubleshoot this. Help! 😞 

[the_rock]

How is routing set in vpn community object?

Andy

[isuckatthis]

We've got it configured as a hub and spoke. We're not using any dynamic routing protocols so we have Route Injection Mechanism (RIM) disabled.

[the_rock]

Which option applies to you here? center only?

Andy

VPN Routing Options

• To center only . No VPN routing actually occurs. Only connections between the satellite gateways and central gateway go through the VPN tunnel. Other connections are routed in the normal way

• To center and to other satellites through center . Use VPN routing for connection between satellites. Every packet passing from a satellite gateway to another satellite gateway is routed through the central gateway. Connection between satellite gateways and gateways that do not belong to the community are routed in the normal way.

• To center, or through the center to other satellites, to internet and other VPN targets . Use VPN routing for every connection a satellite gateway handles. Packets sent by a satellite gateway pass through the VPN tunnel to the central gateway before being routed to the destination address.

[isuckatthis]

Should I see VPN Community encryption domain routes here?

[the_rock]

You should.

Andy

[isuckatthis]

Looks like we have it configured the same as in your screen shot.

[the_rock]

Right, but is that correct? I ask because if there is routing supposed to happen through the tunnel, that that setting would be incorrect.

Andy

[isuckatthis]

Good question and perhaps I'm not understanding your ask. If you're asking dynamic routing protocols, no. We are expecting static routes via the VPN community to handle routing.

I understand that the encryption domain itself handles encryption and routing across the tunnel. Using my original image showing 10.59.78.0/24 within the encryption domain at the remote site, I'm expecting my hub to route the traffic across the tunnel.

Here's a simple diagram of what we're trying to accomplish. The VPN community lists 10.59.78.0/24 on the spoke side. The VPN community lists 10.59.0.0/16 on the hub side.

[the_rock]

Ok, so option you have is fine, BUT, here is your issue, you have supernet problem. 10.59.0.0/16 definitely contains the other subnet. Make sure below options are set to FALSE in guidbedit, push policy, reset the tunnel and try again.

Andy

ike_enable_supernet

ike_p2_enable_supernet_from_R80.20

ike_use_largest_possible_subnets

[isuckatthis]

Thanks Andy! I feel like we're getting closer now!

Do I understand correctly, the more specific mask network isn't automatically used, like in traditional routing?

I'll take a look at dbedit, I've seen someone use it before to hack their way through a problem. "oh, the firewall isn't doing what I want? Let's change registry settings!" 😆

Fingers crossed! Thanks for all your help so far, I'll be back!

[the_rock]

Glad we can help you. Btw, not sure how long you been around CP, but in the old days (R77 and before versions), that was big issue for supernet, specially with Cisco.

What I mean by that is say Cisco expects /28 subnet, but CP would always send largest possible, ie min /24 or larger. Thats why folks always had to go to guidbedit and change those values.

In R80 +, thats not really such a huge problem, but I would still verify.

Andy

[isuckatthis]

I've been around CP for about 4 months. I'm an amateur and hence the name "isuckatthis" 😐

[isuckatthis]

I found them! Two are true and one is global.

Since these are all "ike" tagged, is there any impact anywhere else within Checkpoint when I change these settings? We have no production VPNs from a checkpoint firewall so if this only affects IKE, I feel confident in changing these settings. If this could impact any other functionality, I don't feel comfortable until I understand the full impact.

The second option talks about being global and not a true or false.

[the_rock]

I would 100% change it to false. I had people change this probably 100+ times before and I had NEVER seen an issue, even when they had multiple vpn communities. Worst thing that could happen is if tunnel did go down, you just reset it and its back up.

R82 mgmt has all those values false by default.

Andy

[isuckatthis]

Bummer, no dice.

I set all three values to false, pushed policy to both firewalls, bounced the tunnel. 

Same behavior. The hub does not forward across the tunnel.

[the_rock]

That sucks...o well. Okay, question...is tunnel showing up from vpn tu?

Andy

[isuckatthis]

It is, I have SAs on both FWs

[the_rock]

But from vpn tu, does it show both ike and ipsec sa's as up? If yes, can you run fw ctl zdebug + drop | grep x.x.x.x command? Just replace x.x.x.x with IP thats failing.

Andy

[isuckatthis]

I'm pretty confident that since they're listed here, it means they are UP state.



I ran the fw ctl zdebug command using both the source and destination of our troubleshooting IPs. No traffic shows up, a lot of logs pop up outside of the IPs that I entered, none of it matches either of my IPs

I am running that command from the hub in our case.

I confirmed my guidbedit changes are still set to false

[the_rock]

Hang on, lets confirm something basic. What are vpn domains set on both ends? 

Andy

[isuckatthis]

You got it! I somewhat posted it above but I'll provide more detail. I'm blocking out the names because of the environment we're in, people would be mad if they saw names and especially IPs posted on the Internet.

I've obfuscated (someone took their Sec+ exam 😉 ) some of the text. The names do indeed match.

Behind my hub, I have a loopback on a router with the IP 10.59.40.69. I am trying to ping our remote site switch IP 10.59.78.2. 10.59.78.1/24 is a sub-interface on the remote FW and the default gateway for the switch.

The encdom VPN Domain object is configured for the HUB
The ThompsonTesting VPN Domain object is configured for the SPOKE

[Zee]

Hi Andy,

Is this related to CP-CP as well? I am stuck at Phase1 Issue between our HQ and one of the GW. All other GWs are working fine. The random Phase1 stuck issue is observed on just one FW having VPN with HQ in the Meshed VPN community. Tried with Star as well, still the same issue. TAC could not find or resolve till now, so just wanted to see if that is related. We have R81.20. 

[the_rock]

Sorry, if whats related?

[Zee]

ike_enable_supernet

ike_p2_enable_supernet_from_R80.20

ike_use_largest_possible_subnets

These configurations. I am facing Phase1 issues which are pretty random and I am unable to resolve it till now. And yes I am new to CP as well, so looking out for suggestions and possible solutions. lol

[the_rock]

Ah kk lol, got it! Those dont matter as much these days, BUT, I would still set them to flase in guidbedit.

[Zee]

I actually could not find alot about Phase1 Stuck issue, but in my case, there is no overlapping between these two firewalls, Encryption, tunnel management, Renegotiation configurations and everything has been verified and tested but still it is getting stuck at Phase1 and the only solution is to reset the tunnel.

[Duane_Toler]

IPsec Phase 1 (IKE) is all about the identity of the local and remote peers with the parameters to encrypt that traffic.  This is separate from IPsec Phase 2 (originally "IPsec") is about the traffic selectors (subnets) between the sites and the parameters to encrypt that traffic.

If you have problems with Phase 1, then you need to focus on peer identities first.  What do you see in the logs for the error messages?  Filter your logs for "blade:VPN and action:reject"  to get started.

[Zee]

I do not see anything  from (blade:VPN and action:reject) related to these two FWs which are having issue. I have shared the tcpdump,fwmontior, zdebugs with TAC but they are still unable to resolve it. So the issue is like when it stucks at Phase1 (as per tunnel monitoring), VPN of Site B gets disconnected but sometimes, like today I was able to connect to VPN of Site B but was unable to access resources of Site A although it was still showing Phase1 stuck, and both these issue get resolve after tunnel reset but all other site are working fine. 

[the_rock]

Phase 1, as Duane said, its always related to enc. algorithms, so if thats what keeps breaking, can you maybe try ike v1 instead of ike v2 or other way around, maybe weaker settings for testng?