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

Checkpoint R77 VPN - Two VPN's terminating on the same gateway

Hello 

I have two working VPN's that terminate on the same head end gateway, let's call them Site A & B for simplicity.

I want to send traffic from Site A to Site B via the same head end , i'm using source and destination NAT's so they aren't in the same encryption domain. I can see traffic coming across the the VPN from site A however i cannot see it being sent over the second VPN to site B it doesn't seem to be encrypting into the second VPN.

Is this possible ?

 

Thanks

0 Kudos
9 Replies
G_W_Albrecht
Legend
Legend

I do not really understand your configuration - i would do a Star Community with the head GW as a center and sites A and B as spokes so they are in the same encryption domain.

CCSE CCTE CCSM SMB Specialist
0 Kudos
chip
Explorer

Sorry should have added some more additional information

 

The Remote end A & B are Cisco ASA devices, the head end a Checkpoint R77 gateway .

The Checkpoint Gateway is configured as Star , with VPN domain manually defined subnet's using a group object with the local interesting traffic defined in the group.

The Remote ends are interoperable device with each having a VPN domain manual defined again with another group with the interesting traffic defined for the remote end.

I cannot change the VPN's as this is a live service and traffic works across this from local DMZ's , i just cannot get traffic From A to B via the Checkpoint head end were it traverses two VPN's 

 

Thanks

0 Kudos
PhoneBoy
Admin
Admin

Are the sites part of the same VPN Community or different ones?
Does Site A have definition for Site B as part of their encryption configuration (and vice versa)?
0 Kudos
chip
Explorer

Hello

 

Each remote site has unique networks defined  so they don't overlap encryption domains , the gateway group has defined the local networks and this is shared between A & B, so to overcome the overlaps i.e networks can't be in local and remote groups i've tried various methods of source and destination NATs either on the Gateway or on Remote A .

To complicate things further on the Gateway to Remote B we are doing source and destination NATs due to duplicate 10 networks at Remote B which is a third party site.

I can see the traffic coming in from remote A which is encrypted  / decrpted but doesn't re-encrypt the traffic back to use the second VPN which i don't think is possible, on the remote end i see nothing when i monitor the VPN or packet capture.

I think the interesting traffic is only processed once, is that correct ?

 

 

0 Kudos
chip
Explorer

Yes tried this doing source and destination NATs for Remote A and making sure they are both unique, tried all sorts of permutations with NATs, ensuring source NAT is in the correct encryption domain

I've even tried on another site to site VPN where i don't have to worry about the source and destination NATs between gateway and remote B which i can't change anything as this is a third party.

Its getting the second encryption working is the issue, in tracker i can see the traffic decrypted from Remote A , is there any way i can check to see the process of re-encryption to remote B , 

0 Kudos
mdjmcnally
Advisor

Have done this before

 

Head Office - Check Point - EncDom = It's Local Networks

Site A - unknown vendor but interoperable device

Site B - unknown vendor but interoperable device

To allow Site A to send to Site B then all that had to do was

 

Star Community

Central  - Head Office

Satellites - Site A and Site B

VPN Routing - Allow to Centre and Satellites

 

If Site A and Site B overlap then would need to be NATting at the location as could not have Site A and Site B seen the same at the Head Office.  It would not know which Gateway to goto.

So would expect that Site A Enc Domain is actually the NATed IP for Site Aand that Site B Enc Domain is the NATed IP for Site B, the NAT being done at Site A and Site B boxes., ie they are seen as just the NAT address by the other locations.

 

Site A and Site B have to be configured to send traffic for each other over the VPN to the Head Office.   How do that will depend upon what boxes they are.

So from Site A then traffic would look like

 Network A to Network B NAT, as traffic leaves for Network B NAT then Translate the Source at Site A to be Network A NAT.  Encrypt into the VPN tunnel to Head Office.

Traffic arrives as Network A NAT which see's as being from Site A, and destined for Site B NAT which it see's as going to Site B and so routes over using the VPN Routing in the VPN Community

Traffic arrives at Site B from Network A NAT to Network B NAT and translates the destination to be Network B.

 

Is how I would configure this.

 

 

 

 

 

 

 

 

 

 

 

0 Kudos
chip
Explorer

Yes tried this doing source and destination NATs for Remote A and making sure they are both unique, tried all sorts of permutations with NATs, ensuring source NAT is in the correct encryption domain

I've even tried on another site to site VPN where i don't have to worry about the source and destination NATs between gateway and remote B which i can't change anything as this is a third party.

Its getting the second encryption working is the issue, in tracker i can see the traffic decrypted from Remote A , is there any way i can check to see the process of re-encryption to remote B , 

0 Kudos
mdjmcnally
Advisor

As said previously

1 Star Community with Site A and Site B as Satellites

Enc Doms for the Site A and Site B simply need to be there Local NATed IP to avoid the overlap with those 3rd Party boxes doing the NAT so YOU do not see an overlap of IP.

Your Box as the Centre

Then under VPN Routing make sure is the middle option allowing the Satelites to talk to each other.

Have you configured like this as this is what it should be to allow the two Satellites to talk to each other.

You will see a VPN Routing log entry showing the traffic from Site A to Site B

Your box should NOT be doing any NAT for this to work.

The Third Party Boxes need to see that the opposite Network is via your Box and pass the traffic into the VPN to you,

0 Kudos
chip
Explorer

Good news 

 

I have a standard office to office VPN working now thanks "Nickel" recommendations , they key bit i was missing was on the VPN option routing to center and other satellites .

I've still got an issue as we are doing source and destination NAT between gateway and remote B as the third party doesn't want to change anything but i'm working to get that changed.

 

Thanks again

 

 

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events