ifconfig-push: net30 peer address or subnet netmask?

Dynamic clients connect and route fine, but the one client with a fixed address cannot reach the server at all. Nothing in the firewall changed, and the CCD line looks plausible. The usual cause is a second argument written for a different TUN topology than the server is running. The failure is quiet: the client comes up with an address and the server accepts the connection, yet no traffic crosses.

Under net30 that field is a peer address; under subnet it is a netmask. The two forms are alternatives, never a sequence.

The two forms, side by side

In a traditional net30 deployment each client owns a /30 block: a network address, two usable addresses and a broadcast address. ifconfig-push takes the client address and the peer address, and the peer is the other usable address in the same block, used by the server side of the point-to-point link.

# net30: client address and its peer
ifconfig-push 10.99.0.6 10.99.0.5
# topology subnet: client address and the pool netmask
ifconfig-push 10.99.0.20 255.255.255.0

Under topology subnet the client shares one subnet with the server, and the same directive takes an address and a netmask. The server's own address comes from the server directive, not from the second field. Mixing the forms produces a client that believes it is on a point-to-point link while the server routes it as a subnet host, or the reverse. That is why a netmask must never be paired with net30.

Both lines in the block are single lines for a CCD file. One client gets exactly one of them.

Read the topology the server is actually running

Read the running configuration rather than a package default, because the topology may have been set years ago and copied forward. Look for topology subnet or its absence, then check how the server line allocates addresses. A configuration that never mentions topology is not the same as one that sets subnet.

Then read the client's received settings. The address, mask and peer it reports tell you which interpretation the server applied.

Keep the fixed address out of the dynamic pool

A fixed address must sit outside the dynamic pool, or two clients can be handed the same address. With subnet topology, nopool on the server line suppresses the automatic pool, and an explicit ifconfig-pool range defines what dynamic clients receive.

dev tun
topology subnet
server 10.99.0.0 255.255.255.0 nopool
ifconfig-pool 10.99.0.100 10.99.0.210 255.255.255.0
client-config-dir /etc/openvpn/ccd

The server takes 10.99.0.1 for itself, and the fixed client address sits outside the pool range. The CCD file is named after the effective client identity, not the profile file name, and it takes no extra extension. If username-as-common-name is active, the authenticated user name is the identity to match. Two devices that share one identity will also share the fixed address, which is a policy problem rather than a routing one.

Verify the assignment the client actually received

Reconnect the intended client and confirm which CCD file was selected before checking anything else. Then verify the address, mask or peer, and the route back to the server. A client showing a peer address in a subnet deployment is still using the wrong form.

Changing topology affects every client and every override, so treat it as a migration rather than a one-client repair. Correcting the static line to match the topology already in use is usually the smaller change. The server-options reference documents the helper and the client-specific overrides.