Access Server Group CIDR: Member Addresses or Resource Network

Two fields in an Access Server group accept a CIDR, and at a glance they look like the same kind of input: one describes the addresses handed to VPN members, the other describes networks those members may reach. Filling the wrong one is accepted without an error, which is what makes the mistake expensive. The first changes your tunnel addressing plan, the second decides which destinations are permitted, and neither implies the other. There is also a third object that people fold into these two, the subnet sitting behind a branch gateway, and it belongs to neither field.

Same syntax, different questions

Ask what the value is naming. A member-address CIDR answers "which inner addresses do connecting clients receive", and the assignment machinery consumes it before any traffic flows. A resource CIDR answers "which destinations may this group use", and the access rules consume it when a packet is evaluated. One is a pool definition, the other is a permission.

The consequences of confusing them are opposite. A destination LAN pasted into the pool field can hand out addresses that already exist on that LAN, which produces duplicate-address behaviour, or it can shift the pool in a way that silently breaks every firewall rule written against the old range. A pool pasted into an access rule grants nothing useful, because no destination lives there. Both mistakes present as "the tunnel is up but something is wrong".

Allocation: the member address space

The pool has to be non-overlapping with every LAN a member may reach and with every other VPN pool in the deployment. That is a planning constraint rather than a product setting: with two sites both using 10.90.40.0/24 for members, a member of one site cannot route to the other without translation, and no access rule fixes it.

Assignment mode matters here too. A dynamic pool hands each member the next free address, while a per-user static assignment pins it. Static assignments are what you want when firewall rules or monitoring refer to individual members, and they also make an address-plan change visible: the pinned address either still falls inside the new pool or it does not. Read one connected member's tunnel address before and after any change to this field.

Permission: destination networks belong in access rules

Reachability is expressed in the access rules, which name the group or users, a destination network or service, and the access method. That last part is where most half-finished setups die: a rule can route traffic to the destination or NAT it, and the two need different things from the network. A routed path requires the destination side to know how to return traffic to the VPN pool, while a NAT path hides members behind an address the destination already trusts. The Access Server group documentation keeps group networking separate from group access rules, and the labels have moved between releases.

An allowed destination still needs a usable path. The rule permits, the route delivers, the return path answers and the service on the host accepts. Four things, four places to look, and only the first one lives in the access rule. A green permission with a dead traceroute usually means the return route is missing on the destination's gateway, not that the rule is wrong.

The third object: a branch subnet behind a gateway

Declaring that a particular client owns a subnet is a routing statement about a site, not an address assignment and not a permission. In Access Server terms this is the supported gateway configuration for a connecting network, and it exists because a branch router can advertise the LAN behind it. Members still receive addresses from the pool, and they still need an access rule to use that branch LAN.

Keeping the three separate pays off during review. A branch subnet recorded as a group's member-address space looks correct in a screenshot and breaks allocation for everyone in the group. The same subnet recorded only in an access rule grants access without the ownership statement, so return traffic has nowhere to go. Put each object in its own column of the design and the mistake stops being possible.

How to tell which one you are looking at

Read the label together with its neighbours. A field next to an assignment mode, a pool size or a per-user override is about allocation. A field next to a group selector, a service or port, and a routing method is about permission. Releases rename things, but the neighbours stay roughly where they were, which is why an old screenshot's wording is a poor navigation guide.

Then verify with one member rather than the whole group: its effective group, its assigned tunnel address, and the rule that authorises its intended destination. Confirm the route, the NAT or routed path, the return traffic and the service permission in that order, and change only the field that matches the demonstrated mismatch. Keep allocation and permission records separate afterwards, so a later pool change is not read as a change in what the group may reach.