Almost every “I can’t reach the server” ticket starts with one unverified assumption: the client believes they know which address they’re connecting from. They don’t. They know their LAN address, or what the VPN profile says, or what ipconfig reported the last time they ran it. The address that actually arrives at a firewall, an allowlist, or an upstream provider is usually different — and when it is, the troubleshooting goes sideways quickly. The PortJar What’s My IP tool removes the guesswork in five seconds.
What the tool does
It echoes back the public IP address that PortJar’s servers observe on the incoming request, plus the autonomous system that owns the address and an approximate geolocation. It works for IPv4 and IPv6, picks whichever protocol your client preferred for the connection, and does not log or persist the address. If the client is on a residential connection, you’ll see the ISP’s egress IP. If they’re on a VPN, you’ll see the VPN provider’s exit. If they’re behind a corporate proxy with NAT, you’ll see the proxy’s public address. That single fact resolves most allowlist disputes before they start.
How to use it
Open portjar.com/tools/whats-my-ip in the browser or session you want to characterise. The page reports the address as soon as it loads — there’s no form to fill out. Open it from the same machine, same browser profile, same VPN state as the one that’s failing. If you’re troubleshooting a remote user, ask them to load it and screenshot the result; the address they see is the one a downstream allowlist will see too.
When you’d reach for it
- Allowlist debugging. A client swears they added the office IP to a firewall rule, but connections still drop. They added the LAN address, or an old VPN egress that’s since rotated. Comparing the address PortJar reports against the rule almost always finds the gap.
- VPN verification. Confirming that a tunnel is actually established and that traffic is leaving through the expected exit. If What’s My IP shows the home ISP instead of the corporate VPN, the tunnel is down or split-tunnelling is sending the request directly.
- IPv6 fall-through. When a service is supposed to be IPv4-only but PortJar reports an IPv6 address, the client’s OS is picking AAAA over A. That changes which firewall rules apply and is a frequent cause of intermittent reachability problems.
- Carrier-grade NAT diagnosis. Mobile carriers and some residential ISPs share a small pool of public IPs across many subscribers. If two end users on the same carrier produce the same egress IP, allowlisting one allows the other — which is a security finding worth flagging.
- Cross-checking a “connection timed out” report. Read alongside the PortJar guide on connection-timed-out vs. connection-refused, knowing the actual source IP is the first step before any tcpdump on the destination.
What to make of the output
Treat the address as authoritative for “what other internet hosts see when this client connects right now.” The geolocation is reliable to the city level for residential ISPs, less so for VPNs, mobile carriers, and cloud providers (where the registered location is often a company HQ rather than the data centre that actually answered the request). The ASN tells you who’s responsible for routing the address — useful when you need to escalate to an upstream provider, file an abuse report, or recognise that a “weird” address actually belongs to a major cloud or CDN. If the address surprises the client — “that’s not my office IP” — believe the tool, not their memory.
For environments where allowlists, VPN egress IPs, and source-address policies need to stay correct across many tenants, Stack Harbor handles source-IP discipline as part of environment management.