Where I work, we use the Junos line of products for VPN connections. I'm a little light on the details as far as the hardware requirements and the setup costs etc. but we've had very little issues with them. Some advantages:
Platform independent
The vpn runs in Java (I believe, I never took the time to look really) and can be run on pretty much any platform. I've tried on Mac and PC, though if you might need Linux you should check into that first.
Works on iPad
This might be a bit more enterprise-y (read: Expensive) than your company is willing to fork over. In that case, you might look into the built-in Mac OS X VPN. Mac OS X Server has advertised VPN hosting capabilities which you can apparently use something like iVPN (though if you're technical with the CLI, you can probably get by without it.) I don't have any on-the-job experience with this as we're a strictly SOHO environment, but it's for sure worth looking into.
There are enterprise options out there if your company is looking for a managed solution. If not, there are options for enterprising individuals willing to put forth the necessary time and effort to make sure it all works. I've experimented in the past with VPN and, though it was years ago and I'm sure the software has matured, I'd definitely prefer a managed solution.
You're referencing the SSH server with the name "prismweb5" - that name will likely only work if you have "search domains" setup for the network interface that you're using. The search domain would be appended to the hostname that you're referencing above, so if your search domain is "example.com", the FQDN would be prismweb5.example.com.
It's also possible that the DNS name "prismweb5" cannot be resolved from outside of the network. This setup may be referred to as "split-DNS", and the private name "prismweb5" may not be something that can be looked up on your 'normal' DNS servers (those provided by your home ISP).
A workaround for this would potentially be to set the DNS server that is at the remote office as the primary DNS server for the network interface (Ethernet, Wi-Fi) that you're using to connect. This will allow your machine to perform lookups of 'internal' names. I'm not sure about Shrewsoft, but many VPN clients allow DNS server settings to be changed to specific servers when the VPN connects.
Alternately, you can avoid using DNS names to connect to the server, and simply use the IP address to connect. However, this would require that you know what the IP address of the server "prismweb5" is (or be able to perform a lookup to retrieve that address).
If you are still not able to connect to the server using the IP address, see if your machine can ping that IP address (assuming prismweb5's IP is 192.168.1.5):
ping 192.168.1.5
If the machine is responding to pings, you should be able to connect to it...However, if you're not seeing IMCP (ping) responses, it's possible that your machine doesn't know the route to that computer (i.e., the VPN interface.) See what 'route' reports for that IP:
route get 192.168.1.5
The route should report an interface that is being used to connect to that device. Often, you'll see something like "ppp0" or "gif0" (or some other interface, other than en0/en1)
If the route for that device is not showing the correct interface, it may help to show all routes on the machine using netstat:
netstat -nr
The output of netstat may include an IP range/Destination for your remote network (e.g., 192.168/16), and may show the interface that should be used (Netif) on the right.
Best Answer
If this works when the VPN software is disconnected, then you now have a case to make a configuration change on the VPN server to allow split tunneling.
By default, many VPN servers demand and check that all traffic to the Mac (or PC or Android or iOS or unix client) connect only through the VPN. This causes intentional breakage of ssh since its can no longer listen for an incoming connection from your local subnetwork.
Signing in to a single tunnel VPN intentionally breaks the interface since it exists on the other end of the network tunnel which is a different network range. This is a security issue as most companies consider VPN a firewall to prevent any communications as you have described. This is working as intended for many VPN setups and what you ask may break or be contrary to security setup decision.
Options to change this include:
It’s a good idea to review your security policy if someone else imposes VPN since this could be outside their design parameters or violate security policy if split tunneling is intentionally disabled.