ALERT: Some images may not load properly within the Knowledge Base Article. If you see a broken image, please right-click and select 'Open image in a new tab'. We apologize for this inconvenience.
Pass-to-master flow rule doesn't work for IPsec traffic
Article ID: 167998
Flow rules for inbound IPsec traffic terminated on X-series must have priority 25 or higher when remote gateway isn't Check Point.Symptoms:
Traffic through IPsec tunnel terminated on X-series VAP group running Check Point experiences intermittent failures
Check Point log contains various drop entries for traffic sent through the tunnel, for example packets sourced on well known ports are dropped by the last rule:
fw_log_drop: Packet proto=6 10.0.51.180:25 -> 192.168.200.66:42317 dropped by fw_handle_first_packet Reason: Rulebase drop - rule 87;
Some IPsec traffic is seen on non-master VAP, although flow rules are configured with the action pass-to-master and priority 20 (or lower)
The remote VPN gateway is not Check Point firewall
IPsec VPN is typically terminated on VRRP IP address. When VPN is established between Check Point firewall running on X-series and a 3rd-party VPN gateway, this traffic cannot be load balanced to multiple VAPs. Unlike Check Point firewalls, 3rd party products typically don't support multiple Security Associations (SA) received from a single peer for the same encryption domain. For this reason it is required to configure pass-to-master flow rules when peering with a non-Check Point remote gateway.
Since XOS automatically creates default flow rules for VRRP addresses with priority 21 (action load-balance), it is necessary to override these rules and set priority to 25 or higher for the pass-to-master flow rules. These rules should match inbound IPsec traffic (i.e. protocols IKE, ESP and possibly AH). Otherwise default rules for VRRP addresses take precedence and inbound VPN traffic would be incorrectly load balanced to all VAPs in the vap-group.
Flow rule(s) must also exist for traffic passing in the opposite direction, i.e. outbound into the VPN tunnel. Such rule(s) must match the traffic before encryption, for example based on the destination IP network that exists behind the remote VPN gateway. The priority of such rule(s) need to be higher than priority of the main load-balance rule defined for the vap-group.
1) Flow rules for incoming IPsec traffic terminated on the chassis must have priority 25 or higher when remote gateway isn't Check Point:
2) The traffic in the opposite direction enters the chassis unencrypted. This traffic is sent from local clients and will be encrypted into the VPN tunnel. Flow rules for the unencrypted traffic must have priority higher than the main load-balance rule defined for the VAP group. Since the main flow rule has usually priority 10 (the default priority value for user-defined flow rules), any priority higher than 10 should be sufficient.
One possible way to specify the interesting traffic is to match the remote network address space. It should be identical with the remote encryption domain set in Check Point VPN properties: