Your problem is a classic one, but has many ramification, so your solution depends on your configuration.
The key problem is this:
the listener answers to the client WITH a REDIRECT message that points the server endpoint - a socket-, that has a form of an (IP:PORT) couple or a (host:PORT) or sometimes a (-:PORT) in which the host specification is left unspecified.
That is the location where a dispatcher or server is waiting for the requests to income.
The redirect message is sent only when the client needs to establish a session, and not at the tnsping level (which is testing only the transport level, not the session one).
Where the problems arise?
All the problems arise in the specification of the HOST part of the socket,
because older releases sent back the IP, failing when client and server are on local nets connected by a NAT that mask the address; in fact the listener send back the address of his local (usually 10 or 192.168 networks) - "the remote for you" - lan not the "natted" ip of your local lan with which you are adressing the server.
Next oracle's listener release changed the IP with the hostname, but sometimes the domain name is missing and so the dns search (gethostbyname) can fail or return a wrong result -a server with the same hostname in your dns server/hostname file-.
Your situation is this: if you are in VPN you are "logically" in the same net as the server or a "glued net", so all is working fine.
If you are not in the VPN, you are out of the FW/NAT address translation and so: which address do you have locally/in which net are you?
This is the key question!
Trace the tns session and look at the redirect message the listener is sending to you, so you can see where you are redirected (probably the ports used by oracle are not opened by NAT/FW unless you are in VPN).
I apologize myself for the explanation,
the idea is quite simple but usually is mixed in a complicated framework and it's difficult to answer without knowing the details of your environment.
9i OCP DBA, Performance Engineer