ASA VPN Clients Pull Addresses From the Wrong DHCP Pool

Read the ASA's dhcp-server and dhcp-network-scope as two different fields, set the scope to a routable address outside the pool, then verify the route.

AnyConnect clients come up on the wrong subnet, or the DHCP server refuses to hand out anything at all, and the group policy looks correct at a glance. On an ASA there are two fields in two places that both sound like "where addresses come from", and setting the wrong one produces exactly this. The connection profile names the DHCP server; the group policy names a subnet for that server to select from. Neither one creates a pool.

Three objects, three questions

Separate the allocation model from the pool first, because the two models do not share configuration. If the ASA hands out addresses itself, you define a local pool and point the group policy at it. If an external DHCP server hands them out, the connection profile names that server and the group policy supplies a scope hint. Mixing the two is the usual reason an address never appears.

IntentObjects involved
ASA allocates from its own poolip local pool plus the group policy's address-pool
External DHCP allocatesdhcp-server on the tunnel group, dhcp-network-scope on the group policy

Read the effective values before changing one

An omitted line is not the same as an explicit none. The running config shows what you typed; show run all group-policy shows what the policy actually resolves to, including inherited defaults. Check both before you decide the scope is wrong, because a group policy inheriting from a default policy can supply a value that never appears in the short listing.

show running-config group-policy RemoteStaff
show run all group-policy RemoteStaff
show running-config tunnel-group RemoteStaff
group-policy RemoteStaff attributes
 dhcp-network-scope ?

The ? output is worth reading on your installed release, since accepted values and their help text differ between versions. The Cisco ASA 9.24 group-policy reference documents the attribute as a routable address on the desired subnet, outside the allocation pool, with an interface address preferred. It is not the pool range, and it is not the network number.

Set the scope to an address, not a range

Suppose the pool you want the server to use is 10.50.30.50 through 10.50.30.200 on a /24, and the ASA interface on that segment is 10.50.30.1. The scope value is 10.50.30.1. Writing 10.50.30.0 fails because it is the network number, and writing the range fails because the attribute takes one address. If the address you choose is not an interface address, it needs a static route so the DHCP server's reply can reach it.

group-policy RemoteStaff attributes
 dhcp-network-scope 10.50.30.1

This fragment does only one thing. It does not configure the DHCP server, create a pool there, or turn a partial remote-access profile into a working one. The documented behaviour here is IPv4 only; do not expect it to steer DHCPv6 or prefix delegation.

Change it with a rollback point

Snapshot first, so the rollback is a command rather than a reconstruction. Save the relevant config to a file before you edit, and know what no restores on your release: it returns the attribute to its default or inherited value, which may be none rather than the policy above it.

copy running-config flash:pre-dhcp-scope.cfg
conf t
 group-policy RemoteStaff attributes
  no dhcp-network-scope
  dhcp-network-scope 10.50.30.1
 end
write memory

Removing the attribute is also a diagnostic step. With no scope defined, the DHCP server searches its own pools for an unassigned address, so the client may land somewhere unexpected but at least connects. That result tells you the request path works and the pool selection is what fails.

Verify the address, the route and the permissions

Read the assignment from the session table rather than from the client's dialog, then confirm that the address is routable back to the tunnel and that the group policy's filters allow the traffic you expect. An allocation decision is not a routing decision, and a client that receives an address from the right pool can still fail every request.

show vpn-sessiondb detail anyconnect filter name testuser
show ip local pool
show route | include 10.50.30
ping 10.50.30.61 source inside

If the session shows the address you intended but traffic dies, the scope is finished as a suspect. Look at the return route, at split-tunnel or filter settings on the group policy, and at whether the DHCP scope sits on a segment the ASA actually routes to.

Allakkat attuumassuteqartut