Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
An_Tran
Participant
Jump to solution

IPSec VPN Site to Site_Checkpoint send wrong Proxy-ID in proposal phase 2

Hi all, 

I meet the trouble when deploy  VPN Site to site between Checkpoint cluster XL and Cisco ASR. 

In the QM packet 1, Checkpoint sent to Cisco the Proxy-ID with the External IP. 

QM packet 1 

ID:
(172.30.1.4) - (172.30.1.5)     <---- This is external IP b/t 2 sites

Transport: UDP (IPv4)
PeerIP: ac1e0105
PeerPort: 500
Peer Name: bv-wan-p04

==> Sent to peer 172.30.1.5

I already have unchecked Disable NAT in VPN Community but still change this behavior. 

Anyone please support to reslove this issues. 

Many thanks

0 Kudos
1 Solution

Accepted Solutions
Houssameddine_1
Collaborator

 whenever you configure checkpoint gateways for vpn you have only one encryption domain for all your peers, for that you have be specific and make a unique encryption domain to avoid supernetting and phase two negotiation issues (You can customize the encryption domain per peer by editing the user.def.x. on the management server which is documented in  VPN Site-to-Site with 3rd party).

based on your description for seeing the external IP of checkpoint gateway in the proposal either you are hide NATing the traffic behind the gw (which you might disable NAT inside the community unless you want to apply NAT inside the tunnel you need to adjust it using manual NAT rules). The other reason you might see the external IP of Checkpoint gw in the proposal because you might have permanent tunnels option enabled which should work only between checkpoint gws not 3rd party (by default checkpoint external IP is part of the encryption domain for IKEV1 but not sure about IKEV2)

For the ICMP issue we need to understand that any traffic matches implied rules will not get encrypted.Make sure to change the settings for Accept ICMP request to before last and that will check your rule based before it hits this implied rules

View solution in original post

12 Replies
XBensemhoun
Employee
Employee

Hi An, did you look at VPN Site-to-Site with 3rd party documentation?

And this question too

Information Security enthusiast, CISSP, CCSP
An_Tran
Participant

Hi Xavier, 

This issues have resolved. But now, i meet another problem. After IPSec tunnel between both sites, i can not ping between local site. It seem that the traffic does not pass through the IPSec tunnel. 

In the Cisco site apear this log


May 14 14:15:12.838: %IOSXE-3-PLATFORM: F0: cpp_cp: QFP:0.0 Thread:125 TS:00000554896302735181 %IPSEC-3-RECVD_PKT_NOT_IPSEC: Rec'd packet not an IPSEC packet, dest_addr= 192.168.50.2, src_addr= 192.168.255.20, prot= 1

0 Kudos
XBensemhoun
Employee
Employee

icmp is part of Excluded Services in the community => delete it from the list.

Information Security enthusiast, CISSP, CCSP
0 Kudos
Houssameddine_1
Collaborator

 whenever you configure checkpoint gateways for vpn you have only one encryption domain for all your peers, for that you have be specific and make a unique encryption domain to avoid supernetting and phase two negotiation issues (You can customize the encryption domain per peer by editing the user.def.x. on the management server which is documented in  VPN Site-to-Site with 3rd party).

based on your description for seeing the external IP of checkpoint gateway in the proposal either you are hide NATing the traffic behind the gw (which you might disable NAT inside the community unless you want to apply NAT inside the tunnel you need to adjust it using manual NAT rules). The other reason you might see the external IP of Checkpoint gw in the proposal because you might have permanent tunnels option enabled which should work only between checkpoint gws not 3rd party (by default checkpoint external IP is part of the encryption domain for IKEV1 but not sure about IKEV2)

For the ICMP issue we need to understand that any traffic matches implied rules will not get encrypted.Make sure to change the settings for Accept ICMP request to before last and that will check your rule based before it hits this implied rules

An_Tran
Participant

Thank you so much. I have resolved this case. 

Thank you one more time.  Smiley Happy 

Currently, I deploy another solution, Cisco site with DAIP and Checkpoint with Static IP. As I verified, Cisco already have sent MM1 to Checkpoint, but CP does not respone Cisco. So the IKE phase 1 does  not complete. 

Please help how to configure on Checkpoint witch the case remote site use DAIP. 

Many thank. 

0 Kudos
Houssameddine_1
Collaborator

When you deal with DAIP gateways, we need to know the following:

- You have to use certificate for authentication (you can use any Certificate authority) you can't use presahred key

- You always need  to start the tunnel from the DAIP gw side

Thanks

0 Kudos
An_Tran
Participant

Hello buddy, 

-  I have configured certificate for authentication (using Checkpoint internal CA). 

-  I have started the tunnel from the DAIP gw side. The packets from DAIP side went to Checkpoint but they does not response anything. 

0 Kudos
Houssameddine_1
Collaborator

if you can share screenshot of the configuration and vpnd debugs and  IKE debugs and traffic captures I might be able to find what is the problem + zdebug drop | grep for DAIP IP. 

0 Kudos
An_Tran
Participant

Hey buddy, 

Sorry for feedback late. 

Follow your instruction, i did this task. 

Thank you. 

Now, i am deploying the Remote Access VPN authentication base on User-Group by Radius server on Cisco ACS. 

I followed step by step in Sk105542 and R80.10 Admin Guide to configure on Checkpoint and Cisco ACS. 

But it is unexpected working, the Cisco ACS have responded the Access-Acept packet included the attribute 25 - Class Group. On the other hand, the CP did not tie this attribute into thier behavior. I create two policy matching 2 groups but there are not packet match the policy. 

The showed when tcpdump on CP

20:00:19.350737 Out 00:1c:7f:85:5e:3b (oui Unknown) ethertype IPv4 (0x0800), length 107: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 91) bv-int-fw02.48968 > 10.39.121.10.radius: RADIUS, length: 63
Access Request (1), id: 0xe4, Authenticator: da1fb726052960a63fb58e366554a211
Username Attribute (1), length: 7, Value: ctin1
0x0000: 6374 696e 31
Password Attribute (2), length: 18, Value:
0x0000: b701 030e c4d8 6794 36b6 f16f e088 266a
Service Type Attribute (6), length: 6, Value: Login
0x0000: 0000 0001 [|radius]

20:00:19.359403 In 00:23:eb:02:5f:e0 (oui Unknown) ethertype IPv4 (0x0800), length 116: (tos 0x0, ttl 60, id 0, offset 0, flags [DF], proto: UDP (17), length: 100) 10.39.121.10.radius > bv-int-fw02.48968: RADIUS, length: 72
Access Accept (2), id: 0xe4, Authenticator: 43e16daa10949447c34e7aa2f9652d47
Username Attribute (1), length: 7, Value: ctin1
0x0000: 6374 696e 31
NAS IP Address Attribute (4), length: 6, Value: 172.30.1.4
0x0000: ac1e 0104
Class Attribute (25), length: 7, Value: TEST1
0x0000: 5445 5354 31
Class Attribute (25), length: 32, Value: [|radius]
0x0000: 4341 4353 3a44 522d 4143

20:02:06.397796 Out 00:1c:7f:85:5e:3b (oui Unknown) ethertype IPv4 (0x0800), length 107: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 91) bv-int-fw02.48968 > 10.39.121.10.radius: RADIUS, length: 63
Access Request (1), id: 0xe5, Authenticator: dd00bd73b7f4a1edf4e66b036ab06ead
Username Attribute (1), length: 7, Value: ctin2
0x0000: 6374 696e 32
Password Attribute (2), length: 18, Value:
0x0000: 0d9f c172 7cf5 b6ae 0fa9 fc20 2aeb 51f4
Service Type Attribute (6), length: 6, Value: Login
0x0000: 0000 0001 [|radius]

20:02:06.406418 In 00:23:eb:02:5f:e0 (oui Unknown) ethertype IPv4 (0x0800), length 116: (tos 0x0, ttl 60, id 0, offset 0, flags [DF], proto: UDP (17), length: 100) 10.39.121.10.radius > bv-int-fw02.48968: RADIUS, length: 72
Access Accept (2), id: 0xe5, Authenticator: 1d1f84df246c278a8d5f865c4d2f875a
Username Attribute (1), length: 7, Value: ctin2
0x0000: 6374 696e 32
NAS IP Address Attribute (4), length: 6, Value: 172.30.1.4
0x0000: ac1e 0104
Class Attribute (25), length: 7, Value: TEST2
0x0000: 5445 5354 32
Class Attribute (25), length: 32, Value: [|radius]
0x0000: 4341 4353 3a44 522d 4143

Please support! 

Thank you in advance.

0 Kudos
Houssameddine_1
Collaborator

Tran,

I never worked with external groups before (I dealt most of the time for Authentication purposes not the groups reside inRadius or tacacs server), most people use LDAP and that part I know pretty much. I did some research you might need to check the remote access admin guide

https://sc1.checkpoint.com/documents/R80.10/WebAdminGuides/EN/CP_R80.10_RemoteAccessVPN_AdminGuide/h...

and look for "NT Group/RADIUS Class Authentication Feature" because I see some tweaking in guidbedit and objects.C Which I believe  this is outdated and needs to be fixed because R80.10 doesn't use it unless it is for backward compatibility.

The SK that you mentioned is related to operating system level not to checkpoint software (Remember we have the OS Gaia and checkpoint software on top off it).

you might run vpnd debugs beside the traffic capture and check the flow for associating the Groups might be checkpoint looking for different attribute like attribute 26 not 25? vpnd should tell you the story. Please get vpnd debugs and I will try to look at it.

Thanks

0 Kudos
An_Tran
Participant

Hello buddy, 

This is vpnd debug file. Please try to look at it. 

Link: Dropbox - vpnd52.elg 

Thanks

0 Kudos
Houssameddine_1
Collaborator

Tran,

I looked a vpnd and I see that the user ctin1 is authenticated using radius server using Generic profile but I don't see the group assignment. I'm not sure the attribute to have the gw to consider the radius groups is on or not. we might need to extend the debug to vpnk to see the enforcement portion 

Please check the following link, which shows step by step the configuration

https://community.checkpoint.com/thread/6321-using-radius-groups-radgroup-to-assign-permissions 

Thanks

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events