Field note: VPN users could reach one network but not the other

VPN users at a small agency could reach one internal network perfectly, but a second internal network was completely unreachable. Same VPN, same users, same credentials.

Ruling things out, one layer at a time

I worked from the user outward:

1. The client’s routes. The VPN client did have a route to the unreachable network, so traffic was leaving the laptop correctly.
2. The VPN’s encryption domain. The VPN firewall was configured to carry traffic for that network.
3. The access policy. The firewall rules allowed the traffic.

Everything on the VPN side was correct. So why no replies?

Two firewalls, one missing route

This network had two firewalls: the one the VPN terminated on, and a second firewall that handled routing for the unreachable network.

Traffic from VPN users reached the servers just fine. But when the servers replied to the VPN users’ addresses, the second firewall had no route back to the VPN client address range. It sent the replies somewhere else, so they never arrived.

The fix

On the second firewall:

1. Create a gateway pointing at the VPN firewall’s address on the shared network segment.
2. Add a static route for the VPN client address range through that gateway.
3. Confirm the firewall rules allow the return traffic.

One more thing worth checking: if the VPN firewall translates (NATs) VPN client addresses as they pass through, the servers never see the VPN range, and the route may not be needed at all. That’s why the fix depends on how each network is built.

What I took away from it

• Connectivity is a round trip. “Can’t reach it” often means the replies can’t get back.
• Multiple firewalls mean multiple routing tables. Every device in the path needs a way back to the VPN client range.
• Work layer by layer. Client routes, tunnel config, and access rules each rule out a whole class of causes.