Asymmetrical traffic on ASA

[cisco2016]

Hello

I have the following scheme (in the attachment).

We have 2*ASA 5525 (in failover scheme) on the edge of network and BGP peering with two of IPSs, one of them is primary ISP, and the another is backup ISP (by setting local weights to appropriate interfaces and setting AS-path prepend to the backup ISP).

For certain reasons with this scheme when we are use for NAT source address one of our announced IPv4 addresses, not all inbound traffic is going through the primary ISP (it connects with the peering relationship high-level ISP and we can do nothing with this). And ASA is blocking asymmetrical traffic when outbound traffic goes from one interface (primary ISP), and inbound  - from another (backup ISP), and some internet resources are no available.

As I understand, there are two ways to resolve this issue - tcp state bypass and asr-group, but I don't understand how useful they are in my case?

Could someone to help me how to use asr-group  and/or tcp state bypass in my case?

[Mark DeLong · Accepted solution]

Artem,

It's hard to tell from your diagram but it seems that you have two ASA's in an Active/Standby failover configuration with two ISP connected to them via BGP.

That said, both solutions that you mention aren't really made for this setup. ASR Groups are only allowed to be used in an Active/Active failover configuration. And TCP Bypass is limited to only traffic that utilizes static NAT translations (Servers typically). I wouldn't recommend either of these. And I especially wouldn't recommend going to an active/active failover setup as this was primarily made for data center firewalling and tends to be overly complicated for most people to maintain.

Here's my recommendation:

ASA firewalls are not meant to be WAN routers. You should get two WAN routers that terminate these ISP circuits. These routers would both connect on a single Subnet/VLAN to each other and the ASAs. Now the Act/Stdb ASA pair only have one "outside" interface and traffic that comes to them is never assymetric no matter which WAN router (or ISP) sends to them. The WAN routers will route all traffic to all of the networks they advertise down to the ASA's at the same active firewall IP address. If you need outbound traffic manipulation you can do this by changing local preference on the routes received at the WAN routers and then sending them via BGP to the ASA's. The ASA firewall pair will have two routing protocol neighbors (one for each WAN router) on the same "outside" interface. If you just need default routing redundancy you can send default routes from the WAN routers to the ASA failover pair via BGP with one of them having a better local preference. Alternatively, you can use an IGP between the ASA failover pair and the WAN routers if you want and just redistribute routes from BGP to the IGP on the WAN routers before sending them to the ASA. Lastly, the old style solution from before ASA ran routing protocols was you ran HSRP on the WAN routers and had the ASA use a static default route pointed at the HSRP VIP. That is an option to but it gives you less failover potential then BGP or an IGP between the ASA failover pair and the WAN routers.

With all the traffic going through the ASA's single "outside" interface now all your NAT policy only needs to be configured with a single "outside" interface in mind. Which is how the NAT system in the ASA was intended. With multiple "outside" interfaces for NAT's you run into all kinds of problems and the only thing that really works well in this scenario is outbound PAT configurations. So for NAT you want to stay away from multiple "outside" interfaces on the ASA.

In the end, ASA's make great firewalls but not so great WAN routers. Connecting multiple ISP's to ASA makes for many limitations as ASAs weren't really designed for this. The ASA sees every interface as a separate security zone and this concept does not work well with multiple ISP's.

I hope that helps!

Mark

[cisco2016]

Thank you for this detailed answer

As for TCP Bypass, you say this is limited only statis NAT translation (as I understand NAT one IP to another one IP), but what about PAT? Will the PAT work with the TCP Bypass?

[Mark DeLong]

Artem,

According to the Guidelines and Recommendations section for this technology the answer would be No. Pat will not work:

TCP State Bypass NAT Guidelines

Because the translation session is established separately for each ASA, be sure to configure static NAT on both ASAs for TCP state bypass traffic. If you use dynamic NAT, the address chosen for the session on ASA 1 will differ from the address chosen for the session on ASA 2.

CLI Book 2: Cisco ASA Series Firewall CLI Configuration Guide, 9.4 - Connection Settings [Cisco ASA 5500-X Series Firew…

This solution is not meant for PAT. ASR Groups do work with PAT but you have to configure ASA Active/Active failover and that is typically not recommended for a perimeter firewall solution and is quite complex (requires multiple context mode and a much higher level of maintenance as the contexts don't replicate changes between each other). Not to mention this would change your current design quite a bit.

I know its a bad situation to be in where you need WAN routers and you don't have them. But truly the correct design here is to have WAN routers terminating the BGP circuits. ASA's are not meant to be WAN routers. I run into this a lot with customers. They want their ASA to be a WAN router or a load balancer. They are a good firewall but they are made to firewall rather than do intricate routing or load balancing.

Oh and in case you are wondering the reason some of your traffic is coming back through the ISP link that you have not preferenced with path prepending is most likely because the connected provider is preferring its direct customer routes over peering routes. This is really common. Or some other peering selection policy from their connected peers. You basically can never get all your return traffic over one link because you can't control the upstream ISPs completely with pre-pends. You can ask them to make changes if they are causing an issue but that can be a long journey to resolution if the issue is occuring above your ISP.

I hope that helps!

Thanks!

Mark

[cisco2016]

thank you for your answer

[Mark DeLong]

No problem, Artem! If you could give me the correct answer or "helpful comments" that would be much appreciated! I live for the fake internet points!