We had a similar issue a while ago. Our office uses a different band of firewall, but the problem is the same.
You’re right about the 192.168.1.x addresses conflict. That address is reserved for internal network and is used by a lot of network products by default.
There are 3 solutions:
1) Change the office’s internal IP subnet to a different one. (this is recommended if your network is small)
2) Change the client’s internal IP subnet to a different one. (this is sometime impossible, say , in a hotel)
3) On the firewall, assign a “Virtual IP” for the PPTP. And setup a trusted link between the virtual IP & the office’s internal IP. (this is possible only if your firewall supports it)
Right now, we’re using solution #3 as a quick fix. But we’ll change to solution #1 when there’s time.
4) There is a fourth super-duper easy solution:
Add a line to the windows routing table that has the subnet in question assigned to whatever your VPN interface address is [192.168.2.x] with the lowest metric  so all traffic to that subnet is routed over the VPN ,and not the LAN.
route add 192.168.1.0 mask 255.255.255.0 192.168.2.x metric 1
To automate it for the less savvy users create a batch file with the first [insert maximum number of concurrent VPN connections allowed] lines corresponding to the addresses the vpn will assign.
route add 192.168.1.0 mask 255.255.255.0 192.168.2.1 metric 1
route add 192.168.1.0 mask 255.255.255.0 192.168.2.2 metric 1
Obviously their local network resources will become available again after they disconnect the VPN interface.
I would strongly suggest researching the case when someone attempts to connect from a 192.168.2.x subnet.