Here are your two problems:
1. The ASA strips TCP Option 19. This is used by Border Gateway Protocol (BGP) for authentication.
2. The ASA randomizes the TCP sequence numbers.
Fast Packet blogger Ivan Pepeljnak explains how BOTH vCloud and VEPA fail in virtualization networking
With Option 19 being stripped, BGP routers configured for authentication will not see credentials coming from their peer and thus will not establish the BGP neighbor. You can perform a little command line kung-fu to solve this issue:
First match the BGP Traffic.
access-list BGP extended permit tcp any eq bgp any
access-list BGP extended permit tcp any any eq bgp
Next create a TCP Map that allows Option 19.
tcp-options range 19 19 allow
Now create a class-map to match the BGP ACL you created earlier.
match access-list BGP
Finally, apply the class-map to the global policy:
set connection advanced-options BGP
Now for the second issue, while you are still in the policy-map configuration mode, you need to disable the random-sequence numbering.
set connection random-sequence-number disable
There you have it: A fairly simple configuration that can solve a ton of headaches. And here's some good news: Once you learn how the ASA handles this BGP traffic, you may start to understand why you are having other issues in your networks.
- Read more Fast Packet bloggers
- Fast Packet blogger Michael J. Martin demands session-based application-aware routing
- Fast Packet blogger Josh Stephens wonders if you’re ready to deal with data center network management issues
- Fast Packet blogger Ivan Pepeljnak explains how BOTH vCloud and VEPA fail in virtualization networking
In many cases I've seen TCP maps used to deal with problems passing application traffic through ASAs by allowing or denying certain attributes of TCP. Also, when things seem a little funny it may not hurt to disable the random-sequence numbering. Some applications use the sequence numbers for authentication. If the sequence number changes, the packet may not authenticate. When in doubt, try using something like the Wireshark network analyzer to capture the packets on both sides of the ASA to see what changes, and then try to remove the ASA from the traffic path. If you can see what's changed and verify functionality without the ASA, you can often get the ASA to stop preventing successful traffic flows.
About the author: Brandon Carroll, CCIE # 23837, is a full-time instructor with Ascolta, with a focus in network security and business development. He is also the author of the GlobalConfig blog.