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

17 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

  6. Is there a way to list the IPs one each row like this:

    #define NON_VPN_TRAFFIC_RULES (dst=300.18.60.112
    or dst=400.6.19.14
    or dst=500.23.12.52
    or dst=600.23.41.52)

    The indentation above (done with Notepad++) results in compilation error.

    Moreover, is there an appropriate syntax for commenting each IP raw that won’t generate compilation errors?

  7. Hi,
    I tried the below way and it worked.
    #define NON_VPN_TRAFFIC_RULES ((src in vpn_exclude_dst) or (dst in vpn_exclude_dst))

  8. Hey all,

    I know this is a “not so recent” post, but just to add to this problem, wanted to let you guys know that this is also an issue when you have for example a site to site between two checkpoint firewalls (managed by same sms) and one of them has a Mobile Access Blade SSL Portal. The issue is specifically on subnets not part of the encryption domain. The traffic goes out non encrypted and is dropped at the MAB gateway saying clear packet should have been encrypted.. This is pretty bad and I’m pushing for a better fix than crypt.def to exclude the checkpoint’s MAB SSL Portal external IP from “any” and to “any” ..

    Also if you have an MPLS/VPN redundant topology the issue again presents itself when the MPLS link is up. Traffic to the ssl portal gets detected as being part of the encryption domain (by default the checkpoint’s peer IP is part of it) and the traffic of course does not get there because it’s not going out on the internet link..

    Really hoping for a better fix than crypt.def!


Leave a Reply

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