Whitelisted the VPN Address and Still Blocked? Trace It

Whitelisting the address a VPN app displays rarely fixes a blocked port, and the packet explains why. The firewall is not ignoring your rule; it evaluates a source address that nothing on the client screen shows. Until the destination reports that value, every rule edit is a guess.

Start from the request that reaches the service. The tunnel address, the exit address and any translation in between stay hypotheses until the destination confirms one of them.

The Address in the App Is Not the One Arriving

A VPN connection carries at least four addresses worth naming separately: the server endpoint, the inner tunnel address assigned to your client, the local Wi-Fi or Ethernet address, and the public address a website sees after traffic leaves the provider. A client window may show only the second one. Name all four before you name a rule. With split tunnelling, requests to a public destination can skip the tunnel entirely, so the failing session is not the one the user believes they started.

Decide which of those four the rule is meant to allow, then verify it from the far side. If the requirement is genuinely an office address, the condition is the route plus that site's egress arrangement, and a connection labelled Office VPN supplies neither by itself.

Walk One Request to Its Filtering Boundary

Confirm the destination address and port the client uses, then check that this destination follows the path you assume. A published container port, a reverse proxy or a port forward can move the decision onto a host you never edited. Each of those hops can carry its own policy. Establishing the path first saves you from correcting a rule that no packet ever reaches.

On an authorized Linux host, read the live rules in order before changing them. Forwarded and container services often jump into their own chain, so inspect the jump target as well as the final verdict.

iptables -vnL INPUT --line-numbers
iptables -S INPUT | head -n 40
ss -ltnp | grep -E ':(443|9443)\b'

Quote the matching rule number in the ticket. Without it the next reader cannot tell which edit changed the outcome. A rule number without a timestamp is still ambiguous.

Verify the Path With One Scoped Capture

One harmless request and one narrow capture settle the question that keeps reopening. Filter on the destination port and the host under investigation, cap the packet count, and stop the capture as soon as the request completes.

tcpdump -ni any 'tcp dst port 9443' -c 20

Compare three values side by side: the source in the capture, the source the matching rule names, and the rejection the application logged. Those can all differ, and only the first one explains a drop decided by an IP rule. A forwarded HTTP header belongs to the proxy layer, so a log quoting that header does not describe the source the firewall evaluated.

Read the Chain Order, Not Just the Rule

The iptables reference documents ordered traversal, which is why an allow sitting below a matching terminal rejection never rescues the packet. A connection accepted earlier can also behave differently from a fresh one, so a stale success says nothing about the new rule. Find the reject or drop above your allow before assuming the allow is wrong. Per-rule counters also tell you which rule saw the packet.

Deleting a rule to watch what happens is a change, not an observation. Read the counters, note the rule number, and keep the original policy in the change record. If a test is unavoidable, run it on a copy of the chain.

Change the Rule Its Owner Controls

Update only the intended source and service policy, through whoever owns it. A shared translated exit can stand for many users at once, so allowing that address authenticates nobody, and the application permissions behind it stay where they are.

When the address keeps moving, the durable answer is a stable egress or an authenticated channel, not a longer exception list. Record the observed source, the destination port and the rule number.