HTTPS Basic Auth vs IPsec: What Each One Protects

Open the developer tools, load the internal app, and watch one request pass through four checkpoints before the page renders. First the name resolves, then a TCP connection opens, then a TLS handshake establishes who the server is, and only then does the application ask who you are. Treat those as separate events, because each one fails with different evidence and each one is owned by a different team. Most confusion in incidents comes from reading a 401 as a tunnel problem, or a tunnel problem as a bad password.

Checkpoint one: is this the server you meant to talk to

The TLS handshake answers that question before any credential is sent. Your client validates the certificate chain against a trust store and checks that the name in the certificate matches the host you typed. If that fails, the browser shows a certificate error and never sends the Authorization header at all. A password prompt is therefore not evidence that the server is genuine; it is evidence that the application answered.

Here the first boundary appears. TLS protects the connection up to its termination point. If a load balancer terminates TLS and forwards plain HTTP to the application, the encrypted segment ends at the balancer, and the credentials are protected only on that first hop.

Checkpoint two: what actually travels in a 401 exchange

HTTP Basic authentication sends the user identifier and password in a header, encoded with Base64 as described in RFC 7617. Authorization: Basic dXNlcjpwYXNz is the shape; the encoding is reversible by anyone who can read the request, so all of the secrecy comes from the transport underneath. curl -v shows both the WWW-Authenticate: Basic challenge and the header you send back.

That header tells the application who is asking. It does not tell the network who may connect, and it does not encrypt anything by itself. The application still has to check the credential against a store and decide what that account may do, which is authorization and happens after authentication.

Where the IPsec tunnel sits in that path

Now walk outward from the browser. A gateway-to-gateway IPsec tunnel protects selected traffic between two security gateways, not between your laptop and the application process. Tunnel-mode ESP wraps the original packet, the gateways encrypt and authenticate it, and the inner addresses survive so the far side can route the request to the application.

The selection is the part that trips people. Policy-based tunnels use traffic selectors, often expressed as access control lists, to decide which packets enter the tunnel. Route-based tunnels use a virtual interface and the routing table instead. On Linux, ip xfrm policy shows the selectors and ip xfrm state shows the established security associations; on a firewall appliance the equivalent is the tunnel's SA table plus a packet tracer.

The consequence is worth stating plainly. A packet can sit inside a perfectly healthy tunnel and still carry an HTTPS request that the application rejects, and valid credentials can arrive over a path with no tunnel at all if the routing allows it.

Read the failure at the layer that reported it

A 401 means the application did not accept the credential. A 403 means it accepted the identity and refused the operation. A TLS error means the client did not accept the server. No route or a policy mismatch means the packet never reached the far gateway. Four different failures, four different owners, and none of them is diagnosed by staring at the login form.

Use the evidence each layer produces: the browser's network panel for status and headers, openssl s_client -connect host:443 for the certificate chain, the gateway's SA counters and logs for tunnel traffic, and the application log for the account decision. When two layers report errors at once, fix the lower one first, because a dead tunnel can easily mask an authentication failure and the reverse.

Map one service end to end

Write five lines for the service you are troubleshooting: which peers the tunnel connects, which subnets and ports the selectors permit, where TLS terminates and which identity the certificate asserts, which application account and role is used, and where each layer logs. Keep them on one page, because the point of the map is to show where one layer's responsibility ends and the next begins.

Then test one negative case per layer. Use a wrong password and confirm you get a 401, not a timeout. Connect from a subnet outside the selectors and confirm the packet is not tunnelled. Present a certificate for the wrong name and confirm the client refuses before sending credentials. Those three results tell you more about the design than any diagram of boxes.

Finally, decide deliberately which protection each relationship needs. Basic authentication over TLS is a reasonable fit for a small internal tool behind a gateway; it is not a substitute for per-user authorization or for protecting traffic beyond the TLS endpoint. The tunnel protects the path, the certificate protects the hop, and the 401 protects the account, and only the last of those knows who you are.