Here is what the documentation tells you about VPN traffic in 6.3. It’s an interesting read. Pay attention to the part I bolded:
- Sysopt Connection Permit-vpn Not Working
- Sysopt Connection Permit-vpn Command
- Sysopt Connection Permit-vpn Asdm
- Sysopt Connection Permit-vpn Vti
- Sysopt Connection Permit-vpn Default Setting
“sysopt connection preserve-vpn-flows” This commands allows the VPN to preserve the TCP state across the tunnel during re-keying. I added this statement to the tunnel, and it cleared up the drops the customer was having. If you have a VPN to a cloud provider from a Cisco ASA, make sure that this command is on your ASA. I was trying to get anyconnect to anyconnect phone call audio working when I stumbled upon sysopt connection permit-vpn. The person on the ancient forum post identified the exact issue I was trying to solve and said that, alongside allowing intra-interface traffic, enabling sysopt connection permit-vpn allowed audio to work. From what I understand about 'sysopt connection permit ipsec', this statement allows decrypted VPN traffic to bypass any ACL bound to the crypto interface as well as any conduit statements. The 'crypto map.match address' defines the 'interesting traffic' that will initiate the tunnel. The 'sysopt connection permit vpn' command does take effect on any interface where a crypto map is applied or SSL VPN is enabled. This command is to bypass the ACL but not the NAT rule, so you still need a NAT from DMZ to Outside to allow the traffic flow from a lower to a higher security level interface, if NAT-CONTROL is enabled. The 'sysopt connection permit vpn' command does take effect on any interface where a crypto map is applied or SSL VPN is enabled. This command is to bypass the ACL but not the NAT rule, so you still need a NAT from DMZ to Outside to allow the traffic flow from a lower to a higher security level interface, if NAT-CONTROL is enabled.
Quote From 6.3 Release notes:
Changed default behavior for VPN traffic handling in the access control policy (sysopt connection permit-vpn ).
The default behavior for how VPN traffic is handled by the access control policy has changed. Starting in 6.3, the default is that all VPN traffic will be processed by the access control policy. This allows you to apply advanced inspections, including URL filtering, intrusion protection, and file policies, to VPN traffic. You must configure access control rules to allow VPN traffic. Alternatively, you can use FlexConfig to configure the sysopt connection permit-vpn command, which tells the system to bypass the access control policy (and any advanced inspections) for VPN-terminated traffic
So, if you go an configure the Remote Access VPN through the GUI, you will see this screen now available. I had to look at it a couple times to make sure I was clear on what I was seeing.
The flexconfig option for this command was available in 6.2.3 and works in 6.3 also, but the release notes don’t mention the GUI option.
Sysopt Connection Permit-vpn Not Working
Hey, either way, we finally got our sysopt permit-vpn command with an easy to remember GUI click!
When configuring a VPN (crypto map or VTI) on a Cisco ASA firewall, by default all traffic is permitted. The command sysopt connection permit-vpn is enabled by default, with this command the interface ACLs will be ignored for traffic traversing the VPN tunnel, therefore permitting all traffic over the VPN tunnels. In order to restrict traffic within the VPN tunnel on an ASA a VPN Filter must be configured, multiple VPN Filters can be and assigned per group-policy, therefore per VPN tunnel.
The VPN Filter uses an Access List, however the ACE are not written as per a normal ACL, the SOURCE network/port is always the REMOTE network and the DESTINATION is always the LOCAL network/port. The VPN Filter is stateful and will therefore permit the return the traffic without having to explicitly permit the traffic.
This post will not cover the configuration of a VPN on the ASA, this has been covered in the following posts: – VTI or Crypto Map.
In this example a VPN between HQ_ASA and BRANCH-3_ASA is already configured and operational. A VPN Filter will be configured and applied only to the HQ ASA. Important to remember as far as the VPN Filter ACL is concerned the SOURCE network is BRANCH-3 network (10.30.0.0/22) and the DESTINATION will be HQ network (10.10.0.0/22).
Network Objects
Define network the local (HQ) and remote networks (BRANCH-3)
Access List
The following ACL is configured on the HQ ASA, the Access List is configuring with the SOURCE as the REMOTE network + port and the DESTINATION as the LOCAL network + port
Sysopt Connection Permit-vpn Command
The following ACE will permit telnet from BRANCH-3 network to HQ network
The following ACE will permit SSH (tcp/22) from HQ network to BRANCH-3 network
Sysopt Connection Permit-vpn Asdm
All traffic not matching the ACE above will be denied.
Group Policy and Tunnel Group
The group-policy assigned to the VPN tunnel must be configured with the command vpn-filter value ACL_NAME
Sysopt Connection Permit-vpn Vti
The tunnel-group already configured for the VPN tunnel should already be referencing the group-policy
Sysopt Connection Permit-vpn Default Setting
To confirm the VPN Filter has been applied to the VPN tunnel, run the command show vpn-sessiondb detail l2l. Observe the output of the Filter Name and confirm the VPN Filter ACL has been applied. If the VPN Filter is applied to a VPN tunnel that has already been establish this must be reset in order to apply the Filter.
To test telnet from BRANCH-3 (this is the REMOTE network), connect to a device in the 10.30.0.0/22 network and telnet to 10.10.0.1 (LOCAL network), telnet should confirm the connection to 10.10.0.1 is Open
The output of show access-list VPN_FILTER should confirm a hit on the correct rule #1
Now connect to the host 10.10.0.1 (LOCAL network) and ssh to 10.30.1.1 (REMOTE network), confirm the login prompt is accessible.
The output of show access-list VPN_FILTER should confirm a hit on the correct rule #2
Panoweaver 10 crack.
Any traffic not matching rule #1 or #2 will hit the deny ip any any rule and therefore denied.