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 1.2.3.4 then the VPN server would assign 1.2.3.4 to it's end of the ppp connection, and for example 2.3.4.5 to your end. This results in a routing table in the kernel something like:
Code:
1.2.3.4/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 1.2.3.4/32 dev pppX route with:
Code:
1.2.3.4/32 via ?.?.?.?
Sorts out the problem. We used to do this from ip-pre-up or ip-up (can't recall which one).