Solved: PPTP dial-in vpn broke when updating to 15.1(4)M [from 15.1(3)T]

sylvain.munaut · ‎06-19-2011

Hi,

I have a Cisco 1812 router that's currently running 15.1(3)T and is configured to accept PPTP dial-in.

The config works fine, but I wanted to update to the latest M release (actually trying to solve another completely unrelated bug).

But when I switched to 15.1(4)M, then suddently the PPTP dialin stopped working.

I can connect just fine and I get an IP and everything looks fine. Except there is no packet flowing. I can't ping the other side of the PPP link at all. Downgrading makes it work again just fine.

Any ideas ?

Cheers,

Sylvain

Herbert Baerten · ‎06-22-2011

If using Radius and MPPE, you might be hitting:

CSCtq59239 MPPE data packets not flowing in RADIUS authen case again

which is not resolved yet. As a workaround you could consider disabling MPPE if confidentiality is not a concern, or try to find a working combination of auth protocol (MSCHAP versus MSCHAPv2) and MPPE key length.

E.g. MSCHAP with MPPE-40 may work while other combinations do not.

Or if possible, use local auth instead of radius.

What is the unrelated issue you were hoping to solve with the upgrade? Do you have a bug id for it? Could 15.1(3)T1 be a possible solution (I'm not 100% sure but it looks like the MPPE bug was introduced later than that)?

hth

Herbert

BTW if you see the same problem on the new 1921 and have proof of purchase of a service contract,

I don't guarantee it will work but you can try opening a TAC case by calling TAC and providing a reference (PO/SO) of the purchase.

View solution in original post

andrew.prince · ‎06-21-2011

Raise a TAC case or see if there is a work around for your original issue.

HTH>

sylvain.munaut · ‎06-22-2011

Unfortunately don't have a support contract for this router.

I ordered one for a new 1921 I just got but I still haven't received the paperwork

Herbert Baerten · ‎06-22-2011

If using Radius and MPPE, you might be hitting:

CSCtq59239 MPPE data packets not flowing in RADIUS authen case again

which is not resolved yet. As a workaround you could consider disabling MPPE if confidentiality is not a concern, or try to find a working combination of auth protocol (MSCHAP versus MSCHAPv2) and MPPE key length.

E.g. MSCHAP with MPPE-40 may work while other combinations do not.

Or if possible, use local auth instead of radius.

What is the unrelated issue you were hoping to solve with the upgrade? Do you have a bug id for it? Could 15.1(3)T1 be a possible solution (I'm not 100% sure but it looks like the MPPE bug was introduced later than that)?

hth

Herbert

BTW if you see the same problem on the new 1921 and have proof of purchase of a service contract,

I don't guarantee it will work but you can try opening a TAC case by calling TAC and providing a reference (PO/SO) of the purchase.

sylvain.munaut · ‎06-22-2011

Ah yes indeed I'm using radius.

I think sticking to the previous release is what I'll do.

The problem I was tried to solve (and not even sure updating solves it, I just tough I'd give a shot to the latest version):

When a client connect to that PPTP VPN I wanted to give them an IPv6 as well.

I managed to configure it so that it allocates one to the client from a local pool and the client can ping the ipv6 of the router without issue, it can also ping "outside" ipv6 (like ipv6.google.com). But for some reason, it couldn't ping ipv6 from my LAN .... the 'echo-request' packet is forwarded from the client to the local PC via the router and I see the local PC sending a reply, but the client never gets it.

Herbert Baerten · ‎06-22-2011

Well the obvious first question is, is the routing ok, i.e. does this router advertise the client ipv6 pool into the LAN or is the correct static routing in place for the LAN to reach the client pool.

If that's not it I suggest you create a new post for this. Not sure if it belongs in VPN or rather in or .

Or still open that TAC case

hth

Herbert