Allowing the VPN Port Does Not Let Clients Reach the LAN

The tunnel comes up, the client authenticates, and the LAN behind the gateway stays invisible. The rule that was supposed to fix it permits the VPN port, and it works exactly as written, because that rule governs packets addressed to the gateway itself. Client traffic for a host behind the gateway is a different destination and a different chain. Nothing about a successful login changes which of the two the kernel consults.

Two chains, two different destinations

A packet's fate is decided by where it is going, not by how it arrived. Traffic addressed to an address on the gateway is delivered locally and evaluated against input rules. Traffic the gateway routes onward is evaluated against forward rules. The same tunnel interface can produce both kinds of packet, which is why one rule cannot cover both jobs.

That is the whole myth in one sentence: permitting the listener says nothing about permitting the network behind it. They are separate decisions with separate evidence, and an interface name on both of them does not merge them.

What the listener rule actually admits

Listener packets terminate at the VPN process, which is what allows the tunnel to be established at all. A gateway administration page and a local diagnostic reply also use the host's own input path, which is why a ping to the gateway succeeds while everything behind it fails. Both results are correct and neither one is about the LAN.

Once the process decapsulates client traffic for another destination, the packet enters the forwarding path and needs permission there. Authentication having succeeded settles who the client is; it does not settle where the client may go. The two questions have different owners, different logs and different failure messages.

Test from a client, never from the gateway

A test generated on the gateway follows the host's own output path and can pass while the forwarded path is closed. Run the test from the client, and watch both ends of the flow.

nc -vz 10.40.7.25 445
tcpdump -ni tun0 host 10.40.7.25

If the request appears on tun0 and nothing reaches the destination, the packet is being dropped after arrival, which points at forwarding rules or the destination's own filtering. If nothing appears on tun0 at all, the client is not even sending it to the tunnel, and the problem is routing on the client rather than policy on the gateway. Compare that with a request that leaves correctly and returns nothing, which is the return-path case.

Forwarding needs three things, not one

Kernel forwarding has to be enabled, a filter rule has to accept the flow, and the destination has to be reachable with a way for the reply to return. Any of the three missing produces the same silence from the client's point of view.

sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
sudo iptables -S INPUT

Read the three outputs together. A zero in the first makes the other two irrelevant, and a default-drop policy in the second drops the client's packets while the gateway's own traffic keeps working. The third output shows why the listener rule was never the problem.

Keep the two rule sets separate in the documentation

Write the listener rule and the forwarded-service rule on separate lines with separate owners and reasons. When the VPN port changes or a new service is published, that separation keeps one change from silently widening the other.

Use narrow rules for the client ranges and services that need them rather than treating every authenticated peer as a trusted LAN member. StrongSwan's forwarding notes describe the return-route and translation side of the same boundary, which is a third decision again.

Finally, keep the layers straight when a user is rejected. If the request reaches the host and the application refuses the account, repair the application permission at that layer; broadening forwarding cannot supply a file-share credential, and it will widen access for everyone else who connects successfully.