topic Re: PBR with AnyConnect in Network Security

PBR with AnyConnect

weylin.piegorsch — Tue, 18 Mar 2025 15:26:39 GMT

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.

Re: PBR with AnyConnect

balaji.bandi — Tue, 18 Mar 2025 16:49:50 GMT

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 ?

Re: PBR with AnyConnect

weylin.piegorsch — Tue, 18 Mar 2025 18:17:35 GMT

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

Re: PBR with AnyConnect

Aref Alsouqi — Tue, 18 Mar 2025 23:54:06 GMT

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

Re: PBR with AnyConnect

balaji.bandi — Wed, 19 Mar 2025 07:18:13 GMT

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)

Re: PBR with AnyConnect

weylin.piegorsch — Wed, 19 Mar 2025 10:14:20 GMT

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.

Re: PBR with AnyConnect

weylin.piegorsch — Wed, 19 Mar 2025 10:08:28 GMT

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

Re: PBR with AnyConnect

weylin.piegorsch — Thu, 27 Mar 2025 15:39:31 GMT

I proposed 4 options to management:

Attempt to prototype PBR on the outside interface of the ASA, with several inside subinterfaces (1 per VPN group)
Continue with prototyping PBR on the Catalyst that attaches to the ASA
Investigate DHCP as discussed in this thread
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.

Re: PBR with AnyConnect

weylin.piegorsch — Wed, 25 Jun 2025 01:27:41 GMT

What we ended up doing was.... well, first we realized the failover-enabled ASAs are attached to a VSS-connected pair of Catalyst 9500s, with routing enabled - one ASA on each Cat9500. Scenario 2 here: ASA Failover Configuration, with failover via our OOB network.

Even though they're several miles apart, they're on the same logical switch, so if we do "failover standby" on the ASA interface then only the active ASA will be up - and on the Catalyst side, we can do it with a "mode on" port-channel to only have one virtual interface to apply PBR. We've successfully done this trick with PA firewalls for years.

Then, the ASA inside interface has one subnet on it, which is large enough to contain all the VPN pool IPs. We put a PBR policy on the Catalyst port-channel of the inside interface, which directs traffic based on the various VPN pool address ranges in the "source address" of the IP header. Since it's an attached subnet and the ASA GARPs the IP when a user connects, the ARP and MAC tables direct return traffic back to the ASA.

And, Bob's your uncle it worked!