03-18-2018 08:22 AM - edited 02-21-2020 07:31 AM
Hello folks,
I've got an issue with an ASA set to transparent mode connecting to 2 WAN routers. The ASA is bridging between an "inside" and an "outside" vlan and currently only has an allow IP any/any on it for testing. All traffic is being punted to a FirePOWER module for IPS.
The two routers run EIGRP with a core switch behind the ASA who is the "inside" and the routers are the "outside".
The issue I have is that the WAN routers are active/active and some traffic can leave on R1 and come back via R2. To work around the ASA not being happy and dropping that sort of traffic because it's not in the TCP state table, I put TCP_Bypass on. HOWEVER, I've subsequently found out that TCP_Bypass stops any TCP traffic from being passed through to the FirePOWER module, so I only see UPD and ICMP being punted.
How can I build the firewall so it will let asynchronous traffic through, but still IPS all of the traffic that it gets? Putting on TCP_Bypass stops ALL TCP traffic from being punted, even synchronous traffic. Is this expected or is it a bug?
Best, Leigh
PS - "Fix the routing" can't be done as there are virtual servers that slide between several DC's and the Primary and Secondary WAN's are different in the various DC's.
Solved! Go to Solution.
03-19-2018 02:52 AM
Hi Leigh,
The behaviour is expected:
TCP State Bypass Unsupported Features
The following features are not supported when you use TCP state bypass:
• Application inspection—Application inspection requires both inbound and outbound traffic to go through
the same ASA, so application inspection is not applied to TCP state bypass traffic.
• AAA authenticated sessions—When a user authenticates with one ASA, traffic returning via the other
ASA will be denied because the user did not authenticate with that ASA.
• TCP Intercept, maximum embryonic connection limit, TCP sequence number randomization—The ASA
does not keep track of the state of the connection, so these features are not applied.
• TCP normalization—The TCP normalizer is disabled.
• Service module functionality—You cannot use TCP state bypass and any application running on any type of service module, such as ASA FirePOWER.
What I think you could do (may be the only option) is to install FTD to both appliances, add them to FMC in the same device group and configure on each an inline pair on which you would disable strict TCP enforcement.
That would provide you both traffic inspection, firewall rules and configuration redundancy considering that any rule you configure on FMC would be replicated/applied to both sensors.
Regards,
Octavian
03-19-2018 02:52 AM
Hi Leigh,
The behaviour is expected:
TCP State Bypass Unsupported Features
The following features are not supported when you use TCP state bypass:
• Application inspection—Application inspection requires both inbound and outbound traffic to go through
the same ASA, so application inspection is not applied to TCP state bypass traffic.
• AAA authenticated sessions—When a user authenticates with one ASA, traffic returning via the other
ASA will be denied because the user did not authenticate with that ASA.
• TCP Intercept, maximum embryonic connection limit, TCP sequence number randomization—The ASA
does not keep track of the state of the connection, so these features are not applied.
• TCP normalization—The TCP normalizer is disabled.
• Service module functionality—You cannot use TCP state bypass and any application running on any type of service module, such as ASA FirePOWER.
What I think you could do (may be the only option) is to install FTD to both appliances, add them to FMC in the same device group and configure on each an inline pair on which you would disable strict TCP enforcement.
That would provide you both traffic inspection, firewall rules and configuration redundancy considering that any rule you configure on FMC would be replicated/applied to both sensors.
Regards,
Octavian
03-19-2018 03:00 AM
Hi Octavian,
Thanks for the reply and the clarification. I can't move to FTD as I've got several contexts on the ASA's performing other functions.
What I'm planning to do is VRF the Core switch and run the ASA in-between the global VRF and the new WAN VRF, making it seem to the ASA that there is only two single devices albeit a stack of switches, thus removing the asymmetric routing that the ASA sees. The WAN VRF can then talk off to the WAN routers as asymmetrically as it likes with no issues.
Best, Leigh
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide