Not sure if this is still relevant, but we had a similar issue with a pptp client doing some wacky VPN on a university network.
The fix was to do an explicit /32 route for the VPN access concentrator. So for example let's say you connect to 184.108.40.206 then the VPN server would assign 220.127.116.11 to it's end of the ppp connection, and for example 18.104.22.168 to your end. This results in a routing table in the kernel something like:
22.214.171.124/32 dev pppX
default via ?.?.?.?
Now when the kernel tries to send a GRE (or l2tp or pptp frame) to the VPN server it ends up in the loop as it's trying to get to the VPN server via the VPN connection. Replacing the 126.96.36.199/32 dev pppX route with:
188.8.131.52/32 via ?.?.?.?
Sorts out the problem. We used to do this from ip-pre-up or ip-up (can't recall which one).