Robust detection of whether connection to vpn succeeded

[RossBoylan]

The immediate issue for me is that if I modify the networking scripts so that only UCSF internal IPs are forwarded through the tunnel, the current test will think I have not connected to the VPN even if I have. The test relies on accessing an internet site that is not inside of UCSF, and so the packets to it do not go through UCSF, and the return info indicates a non-UCSF location.

One possibility would be to ping an internal IP as an indicator of successful connection. Of course, that is subject to the vagaries of the routing rules on the internal network, whether UCSF decides to block pings, possible changes in the target system, etc.

Another issue is whether this alternate mechanism should be the only mechanism, a user selectable option, or something else.

There is a related request to UCSF about supporting some mechanism for determing if connection to the VPN succeeded.

[HenrikBengtsson]

Hi, can you clarify what caused you to post this issue? Is this the same as Issue #24?

[RossBoylan]

It's a separate issue, though sharing some symptoms.
#24 arises even with ucsf-vpn out of the box.
This one arises only after I mess with the routing tables so that only internal UCSF IP's are forwarded over the tunnel. Since the location service is outside of UCSF, packets to it will not go though the UCSF tunnel, and thus will not originate from UCSF even if the VPN is up. So the test will always indicate I'm not on the UCSF network.

[RossBoylan]

BTW, the "related request" was not a ticket on ucsf-vpn but one for the networking group at UCSF, and you were the author. I think--that's from memory.

[RossBoylan]

I have confirmed this is related to my selective tunneling (see #35) by coming up with a hackish solution. When I add the IP for ipinfo.io to my list of routes to forward through the VPN, ucsf-vpn resumes correct detection of active tunnels.

This "fix" is not super-robust, since if the IP of ipinfo.io changes it will stop working until the forwarding IP is updated to match. A couple of years ago DNS for ipinfo.io returned a bunch of IPs; now it returns a single IP in a completely different range.

Clever scripting could get the IP(s) for ipinfo.io dynamically and add them to the forward list, but it doesn't seem worth the trouble.

Again, this whole thing is only an issue with my selective tunneling code. The standard code sends pretty much everything through the tunnel, including traffic to ipinfo.io, and so doesn't have this problem.

Ross