What's happening here is that the VPN client is setting your default gateway to the VPN server. This means that all your LAN-destined network traffic is routed through the VPN, and the VPN server will dump the traffic since it is for a private, non-routable subnet (likely 192.168.x.x).
All you need to do is update your routing tables to send LAN traffic to your typical local gateway (i.e. your router). You would probably need to do this every time you disconnected & reconnected the VPN.
You would use the 'route print' command to view routing tables after connecting to the VPN. You would expect to see the default gw (0.0.0.0) destination as your VPN endpoint.
Making this change could indeed bypass some security 'policy' the IT department is attempting to enforce. I would also advise contacting your IT dept. to see if there is any issue with manually modifying the configuration on the system. No point in getting in trouble for something so minor.
[EDIT - additional info as requested]
[DISCLAIMER: modifying routing tables can mess up your access to the Internet or other networks. Changing settings related to a corporate VPN may violate company policy and result in disciplinary action. You've been warned, etc.]
After connecting to the VPN, confirm routing to your printer by running tracert MY_PRINTER_IP. If the routing hops go through the VPN endpoint, you've confirmed traffic for the printer is being routed there, and this is the issue.
route print would display existing routing tables, where you would expect to see the 0.0.0.0 (default gw) entry being directed to the VPN endpoint.
You would use the route ADD command to add an appropriate routing command for your printer. For example, to add an entry for just a single IP that you want to keep on the LAN, you could use:
route ADD MY_PRINTER_IP MASK 255.255.255.255 MY_LAN_ROUTER_IP
You may need to adjust metric on the route to ensure it is chosen first, although a more specific route generally always takes precedence. Repeating the tracert after the change should verify if routing has been updated and is working as expected. If all is good, you could add the routing rule as a static one with a '-p' flag on the ADD command, otherwise the rule is temporary and will be discarded on reboot. The VPN client may also nuke & rewrite all routing rules every time it is connected.
Best Answer
I've seen the exact same issue when connecting to a private network i used to support. Check the configuration of the VPN connection. The default configuration is "Use default gateway on remote network". Since the remote network does not know how to get to your local resources or resolve the names, you PC fails to connect.
This is an old article but describes the same behavior: https://support.microsoft.com/en-us/kb/317025
If you are using the Windows 7 VPN client - Open the properties of the VPN connection, select the Networking tab and Properties if the "internet Protocol Version 4 (TCP/IPv4)" connection - Click the Advanced button and on the "IP Settings" tab uncheck the "Use Default gateway on remote network" box.