blog.lachmann.org

My Check Point blog – Notes from a CCSE+

blog.lachmann.org - My Check Point blog – Notes from a CCSE+

Exclude the external address of VPN peer gateway from encryption domain

When you define a peer gateway for a VPN community, you also have to define the topology of the gateway that is used for VPN connections. This is the encryption domain.

Defining an encryption domain for external VPN peer

What you don’t see is that the encryption domain does not only include the IP addresses of networks associated with the gateway, but also the gateway IP address itself.

This behaviour is not shared by others vendors like Cisco for example, they only use the explictly defined encryption domains.

Common scenario:

You have a VPN with a partner and exchange encrypted traffic. In addition, the partner offers you webpages available over the Internet and reachable over the official IP address of his VPN gateway.

When you try for example to access this webpage from within your network, the traffic will be send encrypted to the remote gateway, let’s say a Cisco ASA Firewall.

The Cisco ASA does not see it’s outside IP address as within the own encryption domain and refuses to create a SA. So your connection attempt will fail.

The solution to this is to exclude the external IP address of the remote VPN peer gateway from VPN.

For this purpose edit the file $FWDIR/lib/crypt.def on the Security Management and change the line
#define NON_VPN_TRAFFIC_RULES 0
to:
#define NON_VPN_TRAFFIC_RULES (dst= IP_Address_Of_VPN_Peer)

Please be aware that this is the way for version R70 and above.

If you have a R75 Security Management that is managing R70 or R71 gateways, you have to edit the file in the compatibility package directory instead.
/opt/CPR71CMP-R75/lib/crypt.def

Tobias Lachmann

  • Murat says:

    what is going to be if there is more than one VPN peer and also IP address?

    November 30, 2011 at 3:37 pm
    • Tobias Lachmann says:

      Just combine the IP addresses with OR

      #define NON_VPN_TRAFFIC_RULES (dst=x.x.x.x or dst=y.y.y.y)

      December 1, 2011 at 2:21 pm
  • Mrevilnerd says:

    Awesome post, this issue has been annoying me for years, when I turn up site to site VPN’s the other side always wants to ping my gateway but it fails because the gateway tries to tunnel the connection even though its not in my encryption domain.

    January 24, 2012 at 10:48 pm
  • Spawn says:

    hmm is this mentioned in any SK at checkpoint.
    I don’t think checkpoint also shares the behavior just like other vendors with its administrators, until they get into a hole and knock the doors of the support.

    April 10, 2013 at 5:23 pm
  • tomo says:

    Hi Tobias,

    I run on this blog googling similar problem. I have CP-Cisco VPN, and need to pass another VPN (which is not under my control, some crypto boxes) through this one. This another VPN is working for few hours, than it don’t work and so on. I see that esp packet from CP local side are droped with “there is no valid SA…” message,IKE packets are encrypted without errors,and esp packets from other side are decrypted without errors.
    Is this checkpoint behaviour normal to treat all esp packet different than “normal” IP packet. SecureXL is enabled, maybe this is cousing problem?
    I guess this setup is possible since it is working from time to time.
    Is there any trick like one you’ve desribe in your blog?
    Can this be because timers for both SA (inner and outer) are not synchronized.

    March 5, 2014 at 12:48 pm
  • Pavel says:

    I just had to tweak the command a little bit.
    With (dst=x.x.x.x) it wouldn’t work, got compiling errors while trying to install the policy.
    With (=x.x.x.x) it works.

    April 1, 2014 at 5:42 pm
    • Pavel says:

      Bah, website edited my comment.
      I wanted to say that you need to put “dst” in “lesser than/greater than” brackets.

      April 1, 2014 at 5:44 pm
  • Andreas says:

    On R76 and above you have to add a bit more to the crypt.def file. It’s described in sk44014.

    https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk44014#Procedure for R76 and above versions

    May 23, 2014 at 1:30 pm
  • Vilius says:

    Great stuff! goes into bookmarks.. since this ‘feature’ was quite a shock to me when all unencrypted traffic from partner gateway died

    June 28, 2014 at 12:26 am

Your email address will not be published. Required fields are marked *

*