Get local IP address of VPN gateway

TMI: I'm told that manually specifying routes is necessary because Linux doesn't support dns-based routes. (I'm in the dark.) I can confirm, at least, that my requests to the target host consistently timeout.

This is partially true, but not exactly in the way you imply.

IP routes are never DNS-based, as the name lookup is a separate step from route lookup – by the time the OS needs to check the routing table, it has no way to associate it with the original domain name that was used.

So there is no difference between Windows and Linux in this regard. Corporate VPNs usually work by providing specific IP-based routes for all hosts that the user may need to access.

Where Windows and Linux do differ is in being able to "route" the DNS lookups themselves to different DNS servers based on their suffix. Linux only supports this if 'systemd-resolved' is being used (and the VPN app cooperates with it), or if manual configuration of additional apps is done (e.g. using dnsmasq), while Windows has it "native".

(Many people do not yet consider systemd-provided functionality to be "built-in".)

Often corporate VPNs use "split DNS", where a domain like 'foo.example.com' may give different results – i.e. resolve to a private IP address when the VPN DNS servers are queried, bt a public IP address otherwise. In this case, you don't need IP routes to be domain-based, instead you need the DNS queries to use the correct DNS server.

My VPN client is Cisco AnyConnect. I've tried to look for the gateway by running ip route | grep default, but that gives me only my wifi router's address.

Yes, your VPN doesn't set up a "default" route; this is usually normal for corporate VPNs. (In fact if there was a default route via the VPN, you wouldn't be having this problem in the first place, as all traffic would go through the VPN anyway!)

However, also note that AnyConnect uses a 'tun' interface, which is a "layer-3 tunnel" or "point-to-point" tunnel. With this tunnel type, the remote gateway is actually irrelevant (as there's no layer-2 header which could be affected by it), and it should be enough for a route to only specify the device.

For example:

ip route add <TargetServerIP>/32 dev cscotun0