Hi Tim,
In R80.20 jumbo hotfix Take 47 they introduced a command to turn off the acceleration just for some VPNs based on remote end IP address. This is limited to just two IP addresses.
Here's a snip of the CP docs:
Overview
A new CLI interface called vpn accel has been introduced for controlling acceleration of VPN tunnels.
The vpn accel interface only affects VPN connections, and does not have any impact on clear-text traffic.
The vpn accel interface supports disabling acceleration of VPN tunnels per VPN peer.
Usage
The behavior of VPN acceleration from R80.20 and above will be controlled by the following options:
syntax: vpn accel [SWITCH_OPTION] [ALLOW_OPTION]
SWITCH_OPTIONS:
off [peer_1_ip] [peer_2_ip] ............. # switch off vpn acceleration (see Notes below)
on ................................................... # switch on vpn acceleration for all peers
stat ................................................ # show vpn acceleration status
ALLOW_OPTION:
-y .................................................... # do not prompt for confirmation
Disabling acceleration of VPN per peer versus globally disabling acceleration of VPN
The command allows you to disable acceleration of VPN tunnels for a given peer by typing the peer IP address (supports disabling acceleration for up to two peers). When acceleration is switched off for given peers, this will cause the deletion of the IPSEC SAs associated with them.
If no address was provided, the acceleration will be switched off for all peers and it will cause the deletion of all IPSEC SAs immediately.
Reenabling acceleration of VPN tunnels
Reenabling acceleration of VPN tunnels after switching off acceleration for given peers will cause the deletion of all IPSEC SAs that belong to these peers.
If no address was provided when acceleration is switched off, reenabling acceleration of VPN tunnels will cause the immediate deletion of all IPSEC SAs.
How to persistently disable VPN acceleration (will survive reboot)
Refer to sk148872 - VPN Traffic drops due to decryption error "Tunnel is accelerated but packet was not decrypted by SecureXL"
Impact on VPN connections
By disabling tunnel acceleration and specifying a particular peer, every VPN accelerated connection with this peer will be lost.
By disabling tunnel acceleration without specifying a particular peer, every VPN accelerated connection with any peer will be lost.
Limitations and Important Notes
In R80.20, 'vpn accel' is supported since R80.20 jumbo hotfix Take 47.
The feature does not support disabling acceleration of VPN tunnels of a specific peer IP if it is a DAIP gateway.
When you run 'vpn accel on' (enabling acceleration of VPN tunnels), fwaccel status will not be effected. This means that new VPN tunnels cannot be accelerated if SecureXL has been stopped. You can check the status by running 'fwaccel stat'.
Each time the command 'vpn accel off' is run, the non-accelerated peers list will be overridden with the last IPs that were inserted.
Packets of accelerated VPN connections will be dropped by SecureXL. The following drops are legitimate at the time of disabling VPN acceleration:
1. " sim (vpn_encrypt): drop due vpn_ipsec_encrypt returns PKT_DROP(3) ----> handle_vpn_encryption: ipsec_encrypt failed. Dropping packet "
2. " forward_before_encrypt: No forwarding destination before encrypt ----> do_packet_finish: SIMPKT_IN_DROP "
3. " invalid in_corr_info => dropping packet, in_corr_info(sxl_dev_id:32, flags:0x0, pkt_flags:0x0) "
Examples
'vpn accel off': All existing Tunnels (IPSEC SAs) will be deleted and become non-accelerated upon renegotiation (new IPsec SA establishment).
'vpn accel off 192.168.15.200 172.23.43.54': Tunnels (IPSEC SAs) of given peers (192.168.15.200,172.23.43.54) will be deleted and become non-accelerated upon renegotiation (new IPsec SA establishment).
'vpn accel on': All existing non-accelerated tunnels (IPSEC SAs) will be deleted and become accelerated upon IPsec SA establishment (if algorithms and other tunnel parameter allow that)
