Your Magento redirect loop is probably not the VPN

You see 302 in the access log, the storefront will not load through the VPN, and the conclusion writes itself. That conclusion is usually wrong in an interesting way. A redirect response records a destination the browser was told to visit, and it says nothing about whether the tunnel, the certificate or the application produced the problem. The log line is the start of the investigation, not its finding.

A 302 says where, not why

An access log entry records the request, the status and the size, and it usually omits the Location header that matters. One redirect can be entirely normal: a canonical hostname, a trailing-slash normalisation, a switch to HTTPS. What you need is the sequence, because a single hop and a loop are different faults with different owners. Repeated hops between schemes point at URL and scheme handling. A hop to a name the browser cannot resolve points somewhere else entirely.

Neither of those is evidence about the VPN. The tunnel is a path; the redirect is an instruction the application wrote.

Capture the chain, not the log line

Use the browser's network view and record four fields per hop: requested URL, status, the Location header, and the time. Finish with either the final response or the connection error, since the interesting case is the hop that never completes. Do this once on a working path and once on the failing one, with the same account and the same navigation. Comparing two chains is worth more than any single line in a log.

Keep that record private. URLs carry session identifiers, and a saved browser archive carries more than you expect. Strip query strings before pasting anything into a ticket.

The application's idea of its own URL

Magento generates absolute URLs from configuration, scoped per website or store view. bin/magento config:show web/secure/base_url prints the value the application believes, which is often a hostname left over from a build or a migration rather than the one the browser used. If it names an internal host, the browser is being sent somewhere it cannot go, and no tunnel change fixes that.

Compare the secure and unsecure base URLs against the public names in front of you. A mismatch in either produces exactly the redirect you are staring at.

Trusted proxy headers are a contract

When TLS ends at a load balancer, the application sees plain HTTP and has to be told otherwise. The offloader header setting names the header the proxy sets, such as the forwarded protocol, and the application trusts it for scheme decisions.

That trust is a contract with one proxy, not a general permission. Accepting the header from arbitrary clients lets anyone claim a scheme, which is why it belongs only where a designated proxy sets it. If the header name and the proxy's behaviour disagree, the application generates redirects to a scheme the browser never used, and the loop closes. Check the proxy configuration and the application setting together, then flush the configuration cache so the change takes effect.

When the loop is a session, not a route

A chain that always returns to sign-in is usually a cookie problem. Inspect whether the session cookie was issued for the hostname the browser actually used, and whether it was marked secure on a connection the browser considers secure. A cookie scoped to the wrong domain produces a login loop that looks exactly like a routing failure.

Fix the demonstrated mismatch at its owner, whether that is the base URL, the cookie domain or the proxy contract, then retest the entire navigation rather than watching one 302 disappear. Disabling HTTPS requirements to break the loop trades a redirect for a worse problem. When the change is done, check the tunnel separately: request a known private resource and confirm it arrives, so the next redirect has a clean baseline to compare against.