6

Each interface on a Cisco ASA has a security level. By default the ASA ACL allows traffic from higher to lower security level, but not the other way around.

Question: Which security level does a site-to-site remote VPN network have? Is it the same security level as the interface that the connection profile is associated with?

Improve this question
2
  • Good question. I know by default VPN traffic bypasses interface access-lists. However, I don't know whether they bypass interface security-level requirements.
    – Eddie
    Mar 3, 2016 at 18:58
  • I'm pretty sure the security level for the remote network(s) is actually the same as the level for the interface on which the VPN is terminated, usually meaning the outside interface and security level 0. Traffic flows because of the ACLs that are created to explicitly allow the traffic through even though it is moving from a lower to higher security level.
    – Todd Wilcox
    Mar 3, 2016 at 19:38

2 Answers 2

Reset to default
5

See this: What is the ASA packet process order when there is both a VPN and route in place?

Documented information:

  • Non-encrypted packets go through the packet process partially quoted at the bottom of this answer. They must be part of an existing connection or have an interface ACL allowing them in or they are dropped (they can be dropped for other reasons also).
  • Encrypted packets bypass interface ACLs and but are still subject to ACLs associated with their tunnel. The tunnel for an encrypted packet (and thereby which ACLs are relevant) is determined by the cryptomap that the packet matches.

Conclusion based on the answer linked above:

  • An encrypted packet goes through the packet process twice, bypassing the interface ACLs the first time and then matching the tunnel ACLs the second time and therefore not being dropped. On the second pass it passes the NAT steps in the process via the "nat 0" command that is part of the VPN config.
  • As far as I can tell, the only thing that security levels actually do in an ASA is cause a default "allow any to any" ACL to be created for traffic going from a high security to low security interface. Packets are not checked against security levels during packet processing, they are checked against ACLs. It seems that the security levels are just a construct to help administrators understand how the ASA works out of the box.

See below, all emphasis is mine:

For an inbound, encrypted packet, the security appliance uses the source address and ESP SPI to determine the decryption parameters. After the security appliance decrypts the packet, it compares the inner header of the decrypted packet to the permit ACEs in the ACL associated with the packet SA. If the inner header fails to match the proxy, the security appliance drops the packet. It the inner header matches the proxy, the security appliance routes the packet.

...

By default, the ASA lets IPsec packets bypass interface ACLs. [...] IPsec authenticates and deciphers packets that arrive from an IPsec tunnel, and subjects them to evaluation against the ACL associated with the tunnel.

Source

  1. The packet is reached [sic] at the ingress interface.
  2. Once the packet reaches the internal buffer of the interface, the input counter of the interface is incremented by one.
  3. Cisco ASA first looks at its internal connection table details in order to verify if this is a current connection. If the packet flow matches a current connection, then the Access Control List (ACL) check is bypassed and the packet is moved forward.
  4. If packet flow does not match a current connection, then the TCP state is verified. If it is a SYN packet or UDP (User Datagram Protocol) packet, then the connection counter is incremented by one and the packet is sent for an ACL check. If it is not a SYN packet, the packet is dropped and the event is logged.
  5. The packet is processed as per the interface ACLs...

Source

Improve this answer
1
  • Note: Sometimes "implicit permit" and "implicit deny" rules are mentioned. I think "implicit permit" is a misnomer, because if I'm not mistaken the permit ACL from high to low security is actually explicit and is visible in ASDM. The "deny ACL" is truly implicit because there is no actual ACL. Instead packets are dropped if they don't match any permitting ACLs. The "implicit" permit rule is destroyed by an explicit permit rule, but the implicit deny rule never goes away, because it's just a way of looking at the dropping of packets, not an actual ACL. "Default permit" might be clearer.
    – Todd Wilcox
    Mar 4, 2016 at 17:15
3

VPNs bypass the security level function/component of the ASA, so the security-level rules don't apply to it.

Improve this answer
2
  • This is what I was thinking as well. But then I thought it required testing to be sure. If you have a simple inside/outside ASA with a site-site VPN configured, and no ACLs applied to any interfaces on the ASA, will VPN traffic get through?
    – Eddie
    Mar 4, 2016 at 16:08
  • 1
    Only the VPN traffic as defined by the Cryptomap
    – Ron Trunk
    Mar 4, 2016 at 16:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.