PBR with AnyConnect

[weylin.piegorsch]

I'm having trouble figuring this out from the configuration guide, and ChatGPT is giving me answer that I'm questioning.

I have an ASA (technically a FPR in ASA-only mode) on v9.20.  I'm running AnyConnect, but I want to have two groups that each forward all traffic out different interfaces per-group.  Is there a way to do this?

I'm not opposed to a NAT-based approach, but this sounds more like PBR.  Except I wasn't sure how either of those interact with AnyConnect.

I'd share config, but honestly I'm not even sure what to share.

[balaji.bandi]

  I'm running AnyConnect, but I want to have two groups that each forward all traffic out different interfaces per-group.  Is there a way to do this?

Do you have example of that IP address Looks like ?

if i assume, you have 2 RAVPN group each group get different IP subnet  ?

you want to send out each subnet to different ISP ? like ISP1 and ISP2 ?

[weylin.piegorsch]

I think this is enough to highlight what I'm asking about.  Webvpn is enabled on outside. Anything VPN group "group2" (regardless of destination) should get a source address of group2-pool, and set next-hop address of 10.2.0.1 via inside-group2.  Anything VPN group "group3" (regardless of destination) should get a source address of group3-pool, and set next-hop address of 10.3.0.1 via inside-group3.

int Eth1/1
 nameif outside
 ip add 10.0.0.2 255.255.255.254
!
int Eth1/2
 nameif inside-group2
 ip add 10.2.0.2 255.255.255.0
! 
int Eth1/3
 nameif inside-group3
 ip add 10.3.0.2 255.255.255.0
!
route outside 0.0.0.0 0.0.0.0 10.0.0.1
!
ip pool group2-pool 10.2.0.16-10.2.0.254
ip pool group3-pool 10.3.0.16-10.3.0.254

[balaji.bandi]

As @Aref Alsouqi suggested, it is best to play with the DHCP pool so it will contact the gateway and follow the route.

What is the use case here? Since you have only one outgoing ISP, do you have any other filters for each group? (since I do not see any advantage you are mentioning PBR here - PBR you need only when you like to traffic steering different ISP and Failover use cases)

[weylin.piegorsch]

I'll broach the DHCP question with management, but that's been a disagreeable approach in the past.

PBR isn't for traffic steering for different ISPs, it's just for traffic steering.

In my use case, I need to drop traffic into different VRFs, from the same AnyConnect "outside" IP.  Except the ASA doesn't support VRFs.  I'm using the ASA for AnyConnect, but the security team is a PA shop. I need to get the traffic to different zones on the PAFW, which are attached to different interfaces and ultimately bridge across into the VRFs on the other side of the PAFW.

We played with multi-contexting the ASAs, and that worked, but required a different "outside" address for each Anyconnect group. We tried context chaining so that one outside IP could be used and then drop the Anyconnect to a follow-on context, but that required over-riding the "tunneled default" route.  We then realized that if we want simply a single outside IP, there's no reason for multi-contexting.

We have an F5 load balancer, which would definitely work, but I'm trying to minimize the amount of different technologies I need to bring in.

It's possible I could place a Catalyst 9500 between the ASA and the PAFW, and use the PBR of the Catalyst 9500.  Management has indicated that's the preferred approach, but gave me some time to explore if I can avoid needing it through ASA-native approaches.

[Aref Alsouqi]

I think what you can try to do here is to configure DHCP under each group policy and specify the DHCP scope with the command "dhcp-network-scope < an IP address from the interested scope >", then, on the DHCP server you define the default gateway for each group.

Anyconnect Client to ASA with Use of DHCP for Address Assignment - Cisco

[weylin.piegorsch]

I'll broach the DHCP question with management, but externalizing the address assignment has been a disagreeable approach in the past.

[weylin.piegorsch]

I proposed 4 options to management:

1. Attempt to prototype PBR on the outside interface of the ASA, with several inside subinterfaces (1 per VPN group)
2. Continue with prototyping PBR on the Catalyst that attaches to the ASA
3. Investigate DHCP as discussed in this thread
4. Multi-context the ASA, and put an F5 load balancer in front of the ASAs

It was pointed out that managing use of the VPN pool requires the ASA to natively (without DHCP) assign addresses, so that when someone disconnect then the address gets added right back to the pool.  Using DHCP, it takes too long to add the address back to the available pool (even with short leases).

I was also told that fronting a series of ASAs with an F5 would probably "work," but won't be allocated for this effort.

PBR implemented on failover-enabled ASA.... Note that PBR works on the interface whereby the packet enters the platform.  For AnyConnect, the encrypted packet enters the ASA by the outside interface, but the unencrypted packet enters via... which interface?  Documentation is unclear, it's likely that the Adaptive Security Algorithm treats the unencrypted packet as entering the same interface as the encrypted packet, therefor PBR on the outside interface would would.

But given that PBR on the StackWise-Virtual Catalyst 9500 is MUCH easier and MUCH more straight-forward than PBR on the ASA, therefor the way we're prototyping this is by using VPN pools taken from the subnet of the inside interface, and applying PBR on the VLAN interface of the Catalyst 9500 that attaches that subnet.