Externally Mananged VPN Gateway Setup

[Charles_Hurst]

Hi all,

I'm trying to setup an Externally Managed VPN Gateway using a Mesh VPN community.

I've got as far as completing the setup using exported Certificates from the :18264 website of each peer. Setup the Mesh Community, configured the Externally Managed VPN Gateway objects, all NAT and policies in place, however something is causing it to not bring up the tunnel.

In SmartView Monitor I get a message to state that GW not Responding so I made sure they two IP's can communicate and that routing is all fine, I'm able to get ICMP packets back and forth.

I can also see Key Install logs on both sides which would again suggest network accessibility is ok.

I tried to run some diagnostics and collect an IKE file to read however because of the state of the tunnel I'm unable to try and reset the tunnel to collect any information in an IKE.

I'm struggling to find any information on GW not Responding when googling.

Any ideas what I can try next? Happy to provide any configuration to help not sure what will help so let me know and I'll reply with it.

Thanks,

Charles

[Vladimir]

Please describe your topology in a bit more detail.

I would like to know if:

1. Any of the two gateways are behind a NAT router(s)

2. Are they both Check Point devices

3. What is the "Externally Managed Gateway" is actually managed with

[Charles_Hurst]

Hi Vladimir,

Thanks for coming back.

The two Check Point gateways are both sitting on two ESXi's independent boxes on the same 'LAN'. I've given the two Check Point devices external IP's and they use RIP routing from the central Cisco router to communicate. So in effect the traffic comes out of the ESXi Ethernet Port, through a Cisco Switch, to a Cisco Router then get pushed back to a second Cisco Switch and two a separate ESXi box which hosts the other 'site' both on separate VLAN's. Therefore if I go out to the actual Internet its double nat'd (at CP and at Cisco Router Internet NAT) however to communicate between the Check Point devices only uses the NAT being done is by the CP GW's themselves which for the internal ranges I've disabled using this:

*This is a network group containing all internal IP ranges for both sites.

Yep both Open Server R80.10.

Both sides are managed using their own local Security Management Server. I know you can do the same type of thing using Interoperable Device however I guessed that if they are both CP's this is the preferred method? My understanding is that Interoperable Device is more for third party devices? Basically I'm trying to simulate what would happen if two companies both with CP GW's needed to bring up a VPN but had their own Admin and Management Server.

To further explain where I'm going, I'm in essence building a Lab to help me prepare for both my upcoming exams and real world situations. I plan on this lab to contain both a internally managed VPN (which I have setup and works perfectly), externally managed CP VPN and a third party Interoperable Device VPN which I plan to use a Juniper SRX to get this up and running. So four sites in total, I have ClusterXL running on the main site with a primary and secondary Security Management Server. I know you have answered a number of my posts on here so far, starting to really get my head around most of it, so again thanks for all your help!

Thanks Again,

Charles

[Vladimir]

OK then. Let's start by looking into definition of encryption domains on both sides and the confirmation that you've successfully imported cross-site CA's certs.

Then confirm that you have antispoofing configured and that there are no asymmetric routing in play that allows return packets to come back via different interfaces.

And verify that you've defined the topology of the externally managed gateways accurately on both sides of the tunnel.

Post the key exchange messages, as well as a rudimentary topology sketch for me to get my bearings please.  

[Charles_Hurst]

Thanks Vladimir,

I do most my drawings on a white board so I've just quickly knocked up this to hopefully give you a better insight:

Following information is setup on Site01 SMS using information I followed on Site to Site VPN R80.10 Administration Guide :

One thing I didn't fully understand on the guide is this line:

Does this mean to manually define the topology, obviously due to the nature of this setup you are not trusted to 'get' the topology so I done is manually is that correct?

Then I basically replicated this exact setup on Site03 but obviously imported the certificate from Site01 instead of its own Cert. I can show you that as well if it would help please let me know.

Many Thanks for your time once again,

Charles

[Vladimir]

The key exchange messages from both sides please...

[Charles_Hurst]

Hey Vladimir,

Would that be these (sorry not 100% sure where the key exchange messages are..):

Interesting that they send to the destination of the MGMT internal IP or is that because this it the traffic from that IP range to that IP range trying to bring the tunnel up?

Thanks,

Charles

[Charles_Hurst]

I've just realized these these are both going in the same direction towards SITE03 I can't see any in the other direction coming back...

[Vladimir]

The "Define Topology" for the peer gateway on each site  requires you to simply replicate opposite gateway's properties:

on the other site's "Externally Managed Gateway".

!!!Interface names are case sensitive!!!

[Charles_Hurst]

Excellent I think that is all done correct then... What about ClusterXL Sync Interface I haven't bothered creating that one? Would that cause a problem?

[Vladimir]

Would not hurt to include it in the topology, but in the "Encryption Domain" properties on both sites you'll have to exempt it and specify either only your internal networks corresponding to each cluster or the group containing your internal networks.

Also, check at least one of the "Matching Criteria":

on both sides of the tunnel. IP Address seem to be the easiest option.

[Charles_Hurst]

Just making that change now...

Strange logs keep appearing also like this:

What I find odd is that 1. its not NAT'in that traffic even though the whole 10.1.1.0 range is set to Auto which would make sense over the VPN but then 2. its not trying to send it over the VPN either...

Could these have something to do with it?

Thanks,

Charles

[Vladimir]

What are the rules in the policy for the site to site communication?

Just screenshot the policy and post it here.

As to NAT between sites, you have explicit:

[Charles_Hurst]

I've got these rules and NAT on both sides:

And than pretty much exactly the same on the other side.

I used very similar rules as I did for my internally managed Mesh VPN.

Thanks,

Charles

[Charles_Hurst]

The rabbit hole gets deeper.. Sorry I know I'm spamming you at the minute...

I setup an any any rule for CPD_AMON obviously not best practice but its a lab so...

Afterwards I got three Encrypted Logs:

Then I thought ah its comes up...

Then got an IKE failure no response from peer log:

I've obviously done something very wrong but can't figure out what..

Thanks,

Charles

[Charles_Hurst]

Right... wasn't getting that before wonder why that certificate is wrong... got something to work on now at least!

Thanks

[Charles_Hurst]

After some tinkering with the Cert (I guess in a real world you would have a root CA so these Cert's would be fine).. I now have this:

So I have a tunnel up and it appears to be working but SITE03-CP-GW01 shows as a tunnel and is not responding I don't really understand why or what this object is. I'm guessing that the Externally Managed VPN Gateway makes the object like a self contained VPN but either way that isn't working.

I'm also a bit confused by having to open up the CPD_AMON all over my security policy first I have to put it in my main policy access rules and then before my Stealth rule after the VPN came up to stop those rejected/drop logs from appearing constantly. Surely this is not right to have to open this up quite so much as it would be a security risk?

Thanks for all your help Vladimir and on a Saturday as well what a hero,

Charles

[Vladimir]

your tunnel is up.

Are you attempting to see its status from the point of view of the peer's gateway?

You do not have to open CPD_AMON in the rules at all within your own security domain.

It is, I believe, define in the implied rules. (Check the Global Properties and "Show Implied Rules").

[Charles_Hurst]

Just on SmartView Monitor on both sides I see the object as a VPN Tunnel stating its not responding still... little bit odd but not a massive problem..

Ok so I've removed all rules for CPD_AMON and disabled implied logging (forgot I turned that on Doh!) tunnel is still up and your right those rejected/denied logs have gone it is an implied rule or some sort.

Thanks Vladimir

[Vladimir]

You may also consider that for monitor to communicate with remote gateway, it should have its own IP statically NATed by local gateway.

[Vladimir]

"Obtain the certificate of the CA that issued the certificate for the peer VPN Security Gateways"

The issuer CA being peer's management server.

In my case:

Subject: CN=GW8010 VPN Certificate,O=SMS8010..bhska4
Issuer: O=SMS8010..bhska4
Not Valid Before: Tue Sep 19 13:51:38 2017 Local Time
Not Valid After: Mon Sep 19 13:51:38 2022 Local Time
Serial No.: 18621
Public Key: RSA (2048 bits)
Signature: RSA with SHA256
Subject Alternate Names:
IP Address: 192.168.7.31

To get the certs of the CAs on each side:

Add these to each peer's trusted CA list.

[Charles_Hurst]

My setup seemed to have a problem with ticking that IP address field... I don't know if its because the IP is the internal IP of the SMS and not the External IP it is trying to peer with. Once I un-ticked that again it sprung to life..

It seems like the CPD_AMON thing was the main problem not having that opened up in the access policy which as mentioned above has got me slightly puzzled.

Thanks,

Charles

[Luigi_Vezzoso1]

Just to be more clear...here a schematic of the architecture.... sorry but I have deleted some information from the schema

How you will configure the external gateway on dashboard for this configuration in order to permit also tunnel_test packets?

Should I need to configure the gateway with the public IP (80.x.x.x) or private/after nat IP (192.168.x.1)? I know that in the topology I should set the real IPs?

[Vladimir]

Apologies, somehow I've missed a notification of your reply in this thread.

If you are still working on this problem, I have to admit that I've got derailed somewhere in my thinking about the issue:

You cannot monitor VPN status of the externally managed gateway, as it is managed by a different management server.

There is a different SIC channel between remote gateway and the server that managing it.

You can only see the status of VPNs of the locally managed gateways.

[JozkoMrkvicka]

https://community.checkpoint.com/docs/DOC-2175-howto-set-up-certificate-based-vpns-with-check-point-...