Ikev2 Phase2 is not getting up

[MaheshCheck]

Can anyone help me to resolve the issue

IKEv2 Phase2 is not getting up and configuration seems to be fine from both the sides

Version :R81.20

[AkosBakos]

Hi @MaheshCheck 

Everyone of us, were is similiar situations. Please provide more  info about the issue.

I suppose this is a s2s VPN connection.

What is GW version and jumbo take?

Until this try the followings:

• reset the tunnel on both sides
• check the ENC_DOMs on both sides, maybe eg.: somewhere the netmask is wrong

And check this SK: https://support.checkpoint.com/results/sk/sk60318

Akos

[MaheshCheck]

Yes ,its S2S VPN 

Firewall version is R81.20 Jumbo Hotfix Take 84

When we select single host ,the tunnel is getting up however whenever we select network , the tunnel is not coming up

We have checked the configuration from both the sides and all network details are correct

• reset the tunnel on both sides-tried but not working

[the_rock]

We need way more info in order to help properly. 

First of all, what is the other side? Do enc settings match? route or domain based? star or mesh? How is tunnel mgmt option configured? ikev1 or ikev2?

Any logs indicating the failure?

Andy

[MaheshCheck]

Domain based ,Star,IKev2

Cisco is peer

[the_rock]

If its combo of hosts/subnets. then please try "per gateway"

If that fails, run simple vpn debug.

vpn debug trunc

vpn debug ikeon

-generate traffic

vpn debug ikeoff

fw ctl debug 0

Get ike* and vpnd* files from $FWDIR/log dir

Message me directly, we can do remote, Im confident I can help you.

Andy

[MaheshCheck]

There are so manu Ike fiels so which one i have to take

attached screenshot for reference

[the_rock]

I would review whatever is today's date. Honestly, I feel your best bet is to call TAC, do remote session and Im sure they would be able to figure it out quick. Its not so easy to tell based on these screenshots. 

Andy

[the_rock]

Hey Mahesh,

Im sure you are sleeping as Im writting this, but in case tunnel still does not work when Cisco side checks, they can use below simple commands to do a debug and its very light. This is what guy I used to work with who worked for Cisco TAC gave me once.

Hope it helps (if needed)

Andy

debug vpn:

debug crypto condition peer x.x.x.x

debug crypto ikev1 200

debug crypto ipsec 200

to cancel all debugs-> undebug all

[MaheshCheck]

Thanks Andy. I have shared the above output with Vendor and will let you know results once i hear back from him.

[the_rock]

Sounds good, I feel good about the outcome...fingers crossed!

Andy

[MaheshCheck]

Hi Andy,

The tunnel is not coming up .I took debug output from cisco vendor and also attached Tunnel details

Could you please look into debug output and is cisco sending wrong proposal? please suggest

attached files

[the_rock]

Thats a bummer : -(. O well, lets see what we can do. I will review soon.

Andy

[the_rock]

Okay, can you make sure it shows ikev2 as per my screenshot below? Also, debug shows crypto map errors, which as far as my knowledge of Cisco goes, literally means phase 2 vpn domain proposals are NOT matching, so can you ask them to verify 100% they have right vpn domain for your side?

Andy

IKEv2-PROTO-4: (44926): Processing IKE_AUTH message
IKEv2-TIMER: Created an IKEv2 timer of type External service timeout
IKEv2-TIMER: Set an IKEv2 timer of type External service timeout for 25 seconds with 0 jitter
IKEv2-PLAT-4: (44926): Crypto Map: No proxy match on map Outside_map seq 1
IKEv2-TIMER: Destroy an IKEv2 timer of type External service timeout
IKEv2-PROTO-7: (44926): Failed to verify the proposed policies
IKEv2-PROTO-2: (44926): There was no IPSEC policy found for received TS

 

[the_rock]

Something else I thought of...so say external peer is 1.2.3.4 (just for sake of commands I want you to run on CP end), please run below when you try to communicate to something on their end (run commands from expert mode of active fw, check which one is active by running cphaprob roles)

tcpdump -enni any host 1.2.3.4 and proto 50

fw ctl zdebug + drop | grep 1.2.3.4

fw ctl debug 0 (to turn off all debugs)

Andy

[MaheshCheck]

Hi Andy,

Thanks for supporting me 

I have attached requested logs.

[the_rock]

This 100% tells me enc domains are NOT matching, so please confirm it again and ask them to verify their Cisco side for YOUR enc domain to make sure it is correct.

Andy

[Expert@checkpointfw01:0]# fw ctl zdebug + drop | grep 172.20.138.198
@;1274658776.23010;[kern];[tid_16];[SIM4];sim (vpn_encrypt): drop due vpn_ipsec_encrypt returns PKT_DROP(3), conn: <10.10.20.121,50629,172.20.138.198,80,6>;
@;1274658776.23011;[kern];[tid_16];[SIM4];handle_vpn_encryption: ipsec_encrypt failed: failed to find SA. Dropping packet... conn: <10.10.20.121,50629,172.20.138.198,80,6>;
@;1274658776.23012;[kern];[tid_16];[SIM4];sim_pkt_send_drop_notification: (0,0) received drop, reason: Encryption Failed (5), conn: <10.10.20.121,50629,172.20.138.198,80,6>;
@;1274658776.23013;[kern];[tid_16];[SIM4];sim_pkt_send_drop_notification: sending packet dropped notification drop mode: 0 debug mode: 1 send as is: 0 track_lvl: -1, conn: <10.10.20.121,50629,172.20.138.198,80,6>;

[MaheshCheck]

Hi Andy,

Thank you for your response.

Could you please guide me on how to check what proposal Checkpoint is sending? Additionally, where can I locate that file, and how can I view it using the IKEview tool?

[the_rock]

You can download ikeview from below.

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

To check proposals, you can see it from smart console community object.

Andy

[the_rock]

I would also use commands from below video (what I showed you on zoom the other day). Those can be super useful as well in troubleshooting the tunnel.

Andy

[the_rock]

Hey Mahesh,

Forgot to mention before, when you download debug files from $FWDIR/log dir, see if there is ike trace file, that one would give you lots of details if you "dump" it into ikeview utility.

Andy

[CaseyB]

Sorry for jumping in so late on this. It does appear to be a mismatch from what I am picking up.

Based on previous replies, are you still doing the tunnel sharing mode of gateway on the Check Point side? If so, does the Cisco side know you are sending a 0.0.0.0/0 IKE ID? 

My recommendation would be to use a custom VPN Domain on the Check Point side and go back to tunnel sharing mode of subnet. Just build a new network group object, and add the following items as networks:

10.20.0.0/20
10.12.0.0/21
10.10.20.121/32

As long as Cisco has those 3 subnets defined as "interesting traffic" on their side, it should be fine. 

[the_rock]

Hey @CaseyB 

When Mahesh and I did zoom remote, he advised me this was combo of subnets/hosts, so thats why I suggested "per gateway", but they did also try per subnet and it failed.

I am fairly positive at this point something with vpn domains is not matching, hence the reason why this does not work.

Andy

[CaseyB]

The "per gateway" is the Check Point way to go for a mix of network and host objects, agreed, but then Check Point sends 0.0.0.0/0, so the other side would have to know to update to that as well. For Cisco, not sure what that configuration looks like.

I did see the per subnet option was not working, but was that using the global encryption domain? If so, how were the networks defined within that; hopefully, they matched how the workbook was filled out.

I still think for any IPsec VPN your best bet is to use granular encryption domains for every tunnel.

The Cisco debug shows if anything was going to work at that time, it would have been the 10.10.20.121/32.

[the_rock]

Thats true, but I think the only way for us to know for sure would be to see what their config looks like. 

Andy

[the_rock]

Also, if you think it would help, Im more than happy to explain this to them, because Im 99.99% sure thats the issue why tunnel is not working.

Andy

[the_rock]

Hey,

Im in the zoom meeting waiting, so if you are free, please join, Im good till 2.30 pm est.

Andy

[the_rock]

Hey Mahesh,

Just send me your email in direct message, we can connect offline. Not sure what country you are in, but Im in Canada EST (GMT-5)

Andy