Site-to-Site VPN Works One Way: Two Different Faults
A reply that never returns and a connection that was refused are different faults. Compare policy, routing and the source address the server actually sees.
Site A reaches B, B cannot reach A, and the tunnel looks fine in both directions. Before touching the tunnel, decide which failure you actually have. A new connection initiated at B that is refused and a reply to an A-initiated connection that never arrives produce similar complaints and completely different diagnoses. One is a policy or route problem on the path; the other is a return path or state problem for traffic that was already allowed.
The distinction decides which commands are worth running.
Two Failures That Look Identical
In the first case B's host sends a SYN to A, and nothing comes back. In the second, A's host opens a session successfully and the response disappears on the way back. Both users say the link is one-way, and both are describing a packet that vanished, so the description alone cannot separate them.
Ask which side initiated the attempt that failed. That single fact removes half the possible causes.
Then check that the test used the same hosts and service throughout. A ping from one side and a file-share connection from the other test two different things, and a gateway-sourced diagnostic can pick a tunnel address that no user traffic ever uses.
Case One: The Return Path Is Missing
A remote server that answers on a different default gateway can receive the request and route the reply elsewhere. Stateful firewalls then drop the asymmetric reply because it does not match an established flow, which looks exactly like a direction that never worked. Translation adds another version: the destination sees a translated source and replies to that, so a rule written for the original address never matches.
Check the address the destination actually observes after translation, and check the return route for that address rather than for the original subnet.
Case Two: The Policy Never Allowed It
The opposite case is simpler and more common than it looks: one office is meant to consume a central service and never to initiate connections into the centre. That asymmetry is a deliberate access decision, and the tunnel is working as designed. Read the access policy before changing any tunnel setting. The document, not the packet capture, states which direction was intended. A capture can only show what happened, not what was authorised.
If bidirectional initiation is genuinely required, add the specific service permission through the platform's supported rule set. Making every subnet mutually trusted to fix one application converts a narrow requirement into a broad permission, and that trade is rarely reviewed afterwards.
Compare Before and After on the Same Hosts
Watch both ends of the same attempt, not two separate attempts. Capture on the initiating host's gateway and on the destination, then compare what entered, what left and which address the far side saw.
tcpdump -ni any host 10.20.30.40 and port 445 conntrack -L | grep 10.20.30.40 ip route get 10.20.30.40 swanctl --list-sas
If the capture at the destination shows the request with an unexpected source address, the answer lies in translation or routing rather than in the tunnel's security policy. If the destination shows no request at all, the packet never crossed the protected path.
After a correction, repeat the identical test from the identical host and confirm that unrelated access is still denied. A tunnel status of established supports neither conclusion on its own.