AnyConnect Management VPN Tunnel, Split-Include ACL

[cfitzgerald]

Hello all. I am working on getting a Management VPN Tunnel working with AnyConnect and my FTD headend. (Management VPN Tunnel is not officially supported on FTD, but I have it mostly working. I think the only unsupported feature of M-VPN on FTD is Custom Attributes.)

I already have my "user tunnels" configured with the split tunnel setting =  "Tunnel all traffic" in the Group Policy.

The Management VPN instructions from Cisco state: "The group policy for this tunnel group must have split include tunneling configured for all IP protocols with client address assignment configured in the the tunnel group"

I have never used split-include tunnelling before, I'm not sure exactly what I should put in the ACL? All of my internal subnets? Only the subnets I want allowed during M-VPN? Do I need a bi-directional extended ACL?

I don't want the client to really be able to send traffic outside of the VPN, but I don't want the M-VPN to have access to the entire internal network. For example, I want SCCM to be able to update the client over M-VPN, but I don't want the clients Outlook/email to work until they sign in to the user tunnel.

Any suggestions for a best practice here? thanks in advance!

[Rob Ingram · Accepted solution]

Hi,
Good job on getting it mostly working :)

I'd put all of your internal subnets in the split tunnel ACL and then use the Access Control Policy (ACP) to limit traffic via port/protocol. If using RADIUS for authentication/authorisation you could authorise based on the M-VPN tunnel group and apply a unique IP Pool (different to the User's VPN) and therefore apply different access control (e.g. SCCM only) compared to the User VPN. You would then authorise the User's VPN and apply a different set of access controls.

If you do not wish for the client to have traffic outside of the tunnel, tunnel all traffic and then rely on the ACP.

HTH

[cfitzgerald]

Thanks again @Rob Ingram . FYI I can;t use Tunnel-all on the M-VPN because that requires a Custom Attribute, which the FTD does not support.

It's strange though, I have put all my internal subnets in the ACL, and I am not using a different IP range from my user tunnels, but some of my traffic is being blocked by ACP when using M-VPN, but not when using user tunnel. (For example, on the user tunnel, I can RDP from internal computer to VPN computer, but on M-VPN, I cannot.) I don't understand how ACP (or maybe NAT?) could be applying differently for user tunnel vs. M-VPN tunnel, when the VPN client IP (and interface) is the same for both.

[Rob Ingram]

So the different tunnel-groups have the same configuration and address pool?
What do the logs say?
If you run "system firewall-engine-debug" on the FTD and generate traffic, what rules are matched?

I am intrigued though, I'll attempt to lab it myself over the next few days and provide feedback.

[cfitzgerald]

Yes,  he U-VPN (user) and the M-VPN (managment) connection profiles are both pointing to my AD-DHCP server for address assignment. The client IP doesn't change when flipping between u-vpn and m-vpn.

The other differences would be:

• u-vpn split=tunnel-all
• m-vpn split=tunnel-include:all internal subnets
• u-vpn Auth=AAA+Certificate
• m-vpn Auth=Certificate only

Will that debug command affect all traffic on my FTD? This is a production edge firewall, so I suspect that will be way too much debug info to wade through. I will try some packet tracers and event logs research though.

[Rob Ingram]

No, when you run that command you can specify source/destination IP address/Port - so you can target just the client computer.

[cfitzgerald]

Thanks for all your help. I figured this one out...it was some badly designed NAT rules causing my issues.