VPN Security – Security Level of Remote Site-to-Site VPN Network

ciscocisco-asa

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?

Best Answer

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

Related Topic