ASA/FTD VPN Routing Issue

[Chad Thelen]

I have two outside interfaces on my firewall - Lets call them outside1 and outside2. Outside1 is the default route for internet-bound traffic, outside2 has a couple static routes to the internet configured for various reasons. They are both part of the outside-zone. The outside-zone is enabled for SSL RA VPN. This enables both interfaces for SSL RA VPN access.
Here is my issue: If I try to establish a VPN session to outside2, I would expect the SYN to come in on outside2, and the SYNACK to leave on outside1; but I never see it leave. I'm assuming the FTD might not like trying to reply on a different interface than the SYN? Is there anything we can do to allow the return traffic to leave out of outside1, or even to force the entire SSL handshake to take place over the one outside2 interface?

We can't do a static route to outside2, due to the random IPs of RA VPN users. And we can't change the default route to outside2 due to needing the PAT IP configured for outside1. 

[Francesco Molino]

Hi

This is normal because the traffic returns to an interface on which ftd didn't see the syn coming in.
You can't force the ssl handshake to stay only on outside 2 because it's going to use its routing table to reply the client.
When you have asymmetric routing you can apply a flexconfig for the feature tcp bypass supported from version 6.3.
Here is the link explaining it and showing how to implement:
https://www.cisco.com/c/en/us/support/docs/security/firepower-ngfw/211628-FTD-How-to-enable-TCP-State-Bypass-Conf.html

Never tested for ssl vpn specifically but it should work.

[Cristian Matei]

Hi,

   @Francesco Molino Technically speaking, TCP state bypass is for data-plane/transit traffic, not for to/from the box traffic, as in the end is the AnyConnect TLS session. Never tested it for AnyConnect sessions, but i would assume it's not gonna work.

Regards,

Cristian Matei.

[Francesco Molino]

@christian I know, you're right but never tested and I proposed for testing purposes as never done it.

Anyways, I tested this morning and it doesn't work. Then solutions would be to have extra L3 layer or multi instances.
PBR won't be work as it seems he wants to keep anyconnect from both links.

When FTD6.6 will be released, you'll be able to do it using VRFs.

[Cristian Matei]

Hi,

  @Francesco Molino Even if he wanted to have active VPN sessions over both outside interfaces, PBR would have still been valid solution:

     - you have a different VPN pool for VPN clients connecting to different outside interfaces, like 10.10.10.0/24 for those attached to outside1 and 10.10.20.0/24 for those attached to outside2

   - you configure PBR and based on the destination (which VPN clients are accesed), you set the proper net-hop and interface, because you know on which interface the client is actually attached based on the assigned address

Hope it makes sense. Heard about 6.6 VRF, but not sure on the overall implementation and limitations it brings alongside with some fixes.

PS: Funny, we're discussing options, in the end the customer opted out for the simplest solution; use another **bleep** firewall :) Easy and functional.

Regards,

Cristian Matei.

[Francesco Molino]

Sure pbr with a different pool will be ok and then also he has to make sure to configure redundancy in case 1 link goes down using pbr availability check and backup servers.

[Cristian Matei]

Hi,

I see couple of options, depends which one fits you better:

           1. You could run FTD multi-instance, but you need a 4100/9300 hardware

           2. If you have another layer 3 device in between FTD and ISP, you could do PBR on that intermediate layer3 device

           3. You could configure the default route towards your new ISP (where VPN is terminated) and use PBR to route internal user's traffic to the Internet via the existing primary ISP; you can do this via FlexConfig, not sure if it's supported via SmartCLI

           4. You could keep the default route as it is via the primary ISP, and configure PBR to route all traffic from your internal resources towards the VPN protected subnets towards your secondary/new ISP, where VPN is terminated; if you run full-tunnelling for VPN users, and you allow Internet access through the VPN headend, another PBR would be needed to route traffic sourced from VPN client pool to the Internet via the secondary/new ISP (this is not required, only if you want Internet traffic for VPN users to use the same second provider)

Regards,

Cristian Matei.

[Chad Thelen]

I appreciate everyone's time and responses. 

We ended up bringing the second circuit into a 'new' firewall, adding an interface in the primary firewalls outside subnet, and then NAT-ing that traffic over to the primary firewall. This way the traffic could still follow the default route back to the outside interface, but follow the path back to the 'new' firewall. 

I think we will figure out a more permanent solution in the future, but temporarily this does the job we need it to. 

[MILTON MENEGHINI]

Hi Chad

You said: They are both part of the outside-zone. The outside-zone is enabled for SSL RA VPN. This enables both interfaces for SSL RA VPN access.

I'm trying to enable 2 internet interfaces in a SSL RA VPN configuration and I got only one field where is possible to choose or outside-1 or outside-2.

How do you do that?