The implementation challenges arise from how the SSL appliance (using inline deployment) determines which traffic to re-encrypt. The SSL appliance accomplishes this using Plaintext Marking. There are two choices, each with different interoperational challenges.
1. Source MAC address rewrite. All decrypted packets have the source MAC address re-written to 00:15:4D:00:00:D5. The MAC address is not configurable.
2. VLAN tagging. All decrypted packets are tagged, while non-decrypted traffic is left untagged. The VLAN number for the tag is configurable, but the configured value will apply to all decrypted traffic.
Note: The SSL connection setup (TCP handshake, certificate and key exchange) are not classified as decrypted traffic, and are therefore not marked.
Method 1: Source MAC address rewrite
Source MAC address rewrite creates the following limitations:
1. The security context of the ASAFP interacting with the SSL appliance must be in transparent mode. Otherwise the ASAFP will modify the source MAC address.
2. MAC learning must be disabled. Otherwise, the ASAFP will see the same source MAC address on two distinct interfaces, and will therefore drop packets.
3. Because MAC learning is disabled, all MAC addresses that the transparent context needs must be manually entered with the mac-address-table static command.
If MAC learning is enabled, encrypted traffic may be sent in one direction (client to server or server to client). But as soon as traffic sent in the other direction, the packet is dropped. You can see the dropped packets using the following command:
show asp drop | inc host FP host move packet (host-move-pkt) 4 ? or some other number
Method 2: VLAN tagging
VLAN tagging puts the decrypted and non-decrypted traffic on separate VLANs. This cannot be integrated with the ASAFP. This can be seen by combining two observations.
1. If somehow the traffic from the VLANs where merged, there would be no way to “un-merge” them after they passed through the ASAFP. So there would be no way for a switch to tag the decrypted traffic, but leave the un-decrypted traffic untagged.
2. If the SSL handshake is on one VLAN and the SSL traffic is on another VLAN, we can segregate them. Since the security context processing the SSL traffic never sees the TCP handshake, TCP State Bypass must be enabled for this context. But if TCP State Bypass is enabled, the ASA will not forward TCP traffic to the SFR, so inspection will not take place.
Imported Document ID: 000027717
Subscribing will provide email updates when this Article is updated. Login is required.
Thanks for your feedback. Let us know if you have additional comments below. (requires login)
Subscribed to the Article.
Unable to subscribe
Thanks for your additional feedback !!!
Enterprise Support Virtual Agent
Rate Me :
Tell us more:
Welcome! My name is Sami, the Enterprise Support Virtual Agent answering technical support questions.