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 (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.

Tobias Lachmann

11 thoughts on “Exclude the external address of VPN peer gateway from encryption domain

  1. 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.

  2. 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.

  3. 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.

  4. 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.

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

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

Leave a Reply

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

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>