Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Pradeep_Salunke
Explorer

IPSEC tunnel issue

Created the IPsec site to site tunnel. however it was showing as down. 

Checked traffic with peer ip address traffic however IKE traffic was dropped. Allowed the same now showing accepted. Still 4500 traffic was dropped.

logs below 

AK 0: Get before set operation succeeded of simple_debug_filter_off
[Expert@bu2-fw-01:0]# fw ctl zdebug + drop | grep 154.52.35.150
@;2332418538;[cpu_11];[fw4_0];fw_log_drop_ex: Packet proto=17 154.52.35.150:4500 -> 193.53.133.17:4500 dropped by vpn_drop_and_log Reason: Clear text packet should be encrypted;
@;2332434814;[cpu_11];[fw4_0];fw_log_drop_ex: Packet proto=17 154.52.35.150:4500 -> 193.53.133.17:4500 dropped by vpn_drop_and_log Reason: Clear text packet should be encrypted;
@;2332469207;[cpu_11];[fw4_0];fw_log_drop_ex: Packet proto=17 154.52.35.150:4500 -> 193.53.133.17:4500 dropped by vpn_drop_and_log Reason: Clear text packet should be encrypted;

 

Please help for this

0 Kudos
10 Replies
Blason_R
Leader
Leader

Check Your encryption domains. Looks like the subnets are not added in encryption domains or some thing wrong with those. But worth a check at encryption domains.

Thanks and Regards,
Blason R
CCSA,CCSE,CCCS
0 Kudos
the_rock
Legend
Legend

I agree with @Blason_R . That error means enc domain issue 9 times out of 10, so phase 2 problem. But, to be 100% sure, just do basic vpn debug:

vpn debug trunc

vpn debug ikeon

-generate some traffic

vpn debug ikeoff

Get ike.elg and vpnd* files from $FWDIR/log dir and examine ike.elg to confirm the failure point (use ikeview tool to open it, but notepad++ will do as well).

Andy

0 Kudos
Nishant12
Explorer

There could be two possibility for that.

1 4500 port is not in the exclude services in the vpn community 

2 Either of one or both IP is part of the encryption domain, and these IP looks like the IP used to make the tunnel up so this should not be part of encryption domain.

0 Kudos
Blason_R
Leader
Leader

No Need to exclude 4500 and 4500 can never be a part of encryption settings as per RFC. UDP/4500 is a NAT-T port and will not be part of encrypted traffic. 

Thanks and Regards,
Blason R
CCSA,CCSE,CCCS
0 Kudos
Nishant12
Explorer

In past I faced the same issue when i excluded the 4500 it started working i am not sure why checkpoint is not considering this as exclude only 

0 Kudos
Pradeep_Salunke
Explorer

@Nishant12 , how you excluded the 4500 port?

0 Kudos
Ilya_Yusupov
Employee
Employee

Hi @Pradeep_Salunke,

 

Can you share more info about the gw's that are doing vpn? Is the peer is behind NAT? Is the topology of the peer configured correctly aka, external and internal configured correctly?

 

The exclusions is needed only in case you disabled implied rules, otherwise no need an exclusion.

 

Thanks,

Ilya

Blason_R
Leader
Leader

This is correct - There is no need to exclude the port and @Ilya_Yusupov is 100% correct. 4500 port will never be encrypted since its carrying the NAT data

Thanks and Regards,
Blason R
CCSA,CCSE,CCCS
Nishant12
Explorer

It was working without exclusion but after the upgrade of HFA 156 in R80.40 stopped working not sure why but CP support also agree to exclude when we ask them as i am also agree it should not exclude 

0 Kudos
Ilya_Yusupov
Employee
Employee

@Pradeep_Salunke from which jhf the upgrade was done?

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events