# MSVPN Help [Solved]

## jschweg

I'm going insane at this point. I haven't been able to get pptpclient to connect to my vpn at work for months. No matter how I switch the options around, the farthest I can get is this:

```

debug: [pppd] MPPE required, but MS-CHAP[v2] auth not performed.

debug: [pppd] sent [LCP TermReq id=0x2 "MPPE required but not available"]

```

mppe is properly built into my kernel and everything should be configured correctly on that end. I can provide more information obviously on request.Last edited by jschweg on Sat May 26, 2007 3:32 pm; edited 1 time in total

----------

## jschweg

Bump.

----------

## Napalm Llama

Could you post the contents of your /etc/ppp/options.pptp file?  That should be where most of the configuration is.  (I set up PPTP a few months ago, so some of the finer details have escaped my mind)

----------

## jschweg

Sure.

```

lock

noauth

nobsdcomp

nodeflate

```

----------

## Napalm Llama

Try adding this to it:

```
mppe required,stateless
```

Don't guarantee it'll work without additional tweaks, but at least it's a step in the right direction.

----------

## jschweg

No Dice. Sadly the same error:

```

MPPE required, but MS-CHAP[v2] auth not performed.

sent [LCP TermReq id=0x2 "MPPE required but not available"]

rcvd [LCP TermReq id=0x5 "peer refused to authenticate"]

```

----------

## mrness

As the error says, you are not using the right authentication, probably because the authentication info is not found in /etc/ppp/chap-secrets.

Post all the relevant information (entire LCP log, pppd command line, ...) if you want more help.

----------

## jschweg

Here is the complete log with command:

```

pppd call Test logfd 2 nodetach debug dump

pppd options in effect:

debug           # (from command line)

nodetach                # (from command line)

logfd 2         # (from command line)

dump            # (from command line)

noauth          # (from /etc/ppp/options.pptp)

name <domain\\user>               # (from /etc/ppp/peers/Test)

remotename PPTP         # (from /etc/ppp/peers/Test)

                # (from /etc/ppp/options.pptp)

pty pptp <vpn gateway> --nolaunchpppd          # (from /etc/ppp/peers/Test)

ipparam Test            # (from /etc/ppp/peers/Test)

nobsdcomp               # (from /etc/ppp/options.pptp)

nodeflate               # (from /etc/ppp/options.pptp)

mppe xxx # [don't know how to print value]              # (from /etc/ppp/options.pptp)

using channel 1

Using interface ppp0

Connect: ppp0 <--> /dev/pts/2

sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x62799119> <pcomp> <accomp>]

rcvd [LCP ConfReq id=0x1 <asyncmap 0x0> <auth chap MS-v2> <magic 0x1717238> <pcomp> <accomp>]

No auth is possible

sent [LCP ConfRej id=0x1 <auth chap MS-v2>]

rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0x62799119> <pcomp> <accomp>]

rcvd [LCP ConfReq id=0x2 <asyncmap 0x0> <auth chap MS> <magic 0x1717238> <pcomp> <accomp>]

No auth is possible

sent [LCP ConfRej id=0x2 <auth chap MS>]

rcvd [LCP ConfReq id=0x3 <asyncmap 0x0> <auth chap MD5> <magic 0x1717238> <pcomp> <accomp>]

No auth is possible

sent [LCP ConfRej id=0x3 <auth chap MD5>]

rcvd [LCP ConfReq id=0x4 <asyncmap 0x0> <magic 0x1717238> <pcomp> <accomp>]

sent [LCP ConfAck id=0x4 <asyncmap 0x0> <magic 0x1717238> <pcomp> <accomp>]

MPPE required, but MS-CHAP[v2] auth not performed.

sent [LCP TermReq id=0x2 "MPPE required but not available"]

rcvd [LCP TermReq id=0x5 "peer refused to authenticate"]

sent [LCP TermAck id=0x5]

rcvd [LCP TermAck id=0x2]

Connection terminated.

Script pptp <vpn gateway> --nolaunchpppd finished (pid 16335), status = 0x0

```

----------

## mrness

Do you have such line in your /etc/ppp/chap-secrets?

```
<domain\\user>        PPTP       "password"
```

----------

## jschweg

Indeed I do

domain\\me  peer  password  *

----------

## mrness

peer != PPTP

----------

## jschweg

That did the trick, I knew it was just something that I was doing wrong. Always is. I'm so happy now. I just need to add my route and I'm ready to rock.

Just a quick clean-up question. According to the wiki, if I did NOT use the mppe kernel patch, which I didn't since I'm on a 2.6 kernel with the support built in, I should NOT be building ppp with the mppe-mppc use flag correct?

----------

## mrness

yes, that is correct.

----------

## jschweg

Ok, I'm getting there.

VPN now connects successfully and ppp0 is getting an IP from the vpn server. I added my route to the remote network via ppp0, but nothing. I can't ping anything on the remote network.

----------

## mrness

Some fiirewall (yours or the peer's) is probably to blame.

----------

## Napalm Llama

Can you ping the PPP peer itself? (its IP is next to yours in ifconfig ppp0 )

I can ping that, but nothing else - apparently my University's network blocks ICMP traffic.

Also check your routes once everything is up and running - check that the default route is still there, and going through the PPP tunnel, and also check that the route to the VPN server is still through your hardware NIC.  pppd plays with the routes, it seems, so I have various scripts that get run at different stages of the login process to revert the damage it causes.

----------

## mrness

pppd plays only with a host route to the PPP peer and optionally with default route through ppp interface (controlled by "defaultroute" option).

Other routes you might want should be set through /etc/ppp/{ip-up,ip-down} scripts.

----------

## Napalm Llama

But it behaves annoyingly - it won't set a default route if one already exists (ie. it won't replace it).  So you need to destroy the default route through your NIC, then if your VPN servers are referred to be domain name rather than IP, as mine are, add a route to your DNS servers, use that to lookup the IPs of the VPN servers, destroy the DNS route (because those servers work funnily unless you talk to them through the tunnel), set routes to the VPN servers, start pppd...

And then do the whole thing in reverse when you stop the tunnel.  My point was that routing isn't simple with PPTP.

By the way, jschweg - if you want to borrow my collection of scripts then I'll be more than happy to share  :Smile: 

----------

## mrness

You can't have 2 default routes with the same metric, but you can have 2 default routes with _different_ metrics.

You should set your primary default route with a metric > 1 (say 5), then pppd will be able to create the default route you want.

----------

## Napalm Llama

Now that is worth knowing.  I should jump in and help with threads more often - never know what I might learn!  :Very Happy: 

----------

## jschweg

I only semi-understood what you guys were saying  :Smile:  Below is my routing table AFTER connecting to the VPN and adding the route to the remote internal network:

```

/etc/ppp/peers>route

Kernel IP routing table

Destination     Gateway   Genmask         Flags Metric Ref    Use Iface

<vpnhost>   *         255.255.255.255      UH    0      0        0 ppp0

192.168.1.0     *           255.255.255.0     U     0      0        0 eth0

<remotenet>   *          255.255.255.0      U     0      0        0 ppp0

loopback        *            255.0.0.0             U     0      0        0 lo

default         192.168.1.254   0.0.0.0         UG    0      0        0 eth0

```

Sorry about the formatting, it's the best I could make it look.

<vpnhost> Hostname of VPN router

192.268.1.0 Internal network

<remotenet> remote vpn network

default internal gateway

----------

## Napalm Llama

Paste directly from the console into the code tags - don't try and correct fixed-width spacing in the variable-width font of phpBB's reply box  :Smile:  

```
/etc/ppp/peers>route

Kernel IP routing table

Destination   Gateway   Genmask           Flags Metric Ref  Use Iface

<vpnhost>     *         255.255.255.255   UH    0      0      0 ppp0

192.168.1.0   *         255.255.255.0     U     0      0      0 eth0

<remotenet>   *         255.255.255.0     U     0      0      0 ppp0

loopback      *         255.0.0.0         U     0      0      0 lo

default  192.168.1.254  0.0.0.0           UG    0      0      0 eth0
```

Looks to me like you don't have a route going through your VPN server (just one going to it) - what exactly are you trying to do?  Are you trying to connect to the internet via the VPN, or just access some remote network resources?  In the former case, you want your default route to have the gateway given by the following command:

ifconfig ppp0 | grep P-t-P | sed 's/.*P-t-P:\([0-9.]*\).*/\1/'

(run that while the tunnel's up)

...and you won't need that <remotenet> entry.  In the latter case, you just want <remotenet> to have that gateway, and your default route can stay the same - probably either your ISP or your router, depending on your setup.

----------

## mrness

 *Napalm Llama wrote:*   

> In the latter case, you want <remotenet> to have that gateway.

 

PPP routes are not required to have a gateway (point-to-point links have only 2 ends; whatever you send is received by peer and whatever the peer sends is received by you).

In fact, the unmodified ppp-2.4.4 creates the default route without gateway, but I patched net-dialup/ppp to restore the behaviour of ppp-2.4.3, which used the peer address as gateway. I did that because openswan refused to work over ppp interfaces when the default route were gate less.

I can't see anything wrong in jschweg's routing table. What you should check is that local IP address (the one that has been configured on ppp0 interface) is within remotenet (packages sent by your host have the source IP address the other end expects).

A tcpdump at the other end might prove useful.Last edited by mrness on Thu May 24, 2007 2:32 pm; edited 1 time in total

----------

## jschweg

I don't want the internet to go through the VPN, I just need access to the machines on that network. I added the <remotenet> entry myself with this:

route add -net x.x.x.0 netmask 255.255.255.0 dev ppp0

I added that with the intention of telling it to route anything destined for that remote network through ppp0. Am I doing that wrong?

----------

## jschweg

Of course the other detail is that even though it connects, it only seems to STAY connected for about a minute, then ppp0 drops. I looked that up on pptpclient's support site and it says that the remote server isn't adhering to some RFC. boo. It could be that the routes are fine, but the link is just spoo.

I never thought that this was going to be a problem considering the vpn router at work has a linux backend and is actually running the same old ppp.

----------

## Napalm Llama

 *jschweg wrote:*   

> Of course the other detail is that even though it connects, it only seems to STAY connected for about a minute, then ppp0 drops.

 

Does the debug output say loads of stuff about LCP ConfReq (I think that's what it was) just before the connection drops?  I had a similar-sounding problem at first - I solved it by telling PPTP to be "stateless" (whatever that means) - see my second reply in this thread.

----------

## jschweg

I don't think it's the route, I obviously have issues with this link. Here is the ppp log of one session. The below occurs everytime with this closing control connection due to missing echo reply. Tons of traffic on TX, this is occuring whether I add the route or not.

```

May 24 10:58:33 trashcat pppd[26360]: pppd 2.4.4 started by root, uid 0

May 24 10:58:33 trashcat pptp[26361]: anon log[main:pptp.c:272]: The synchronous pptp option is NOT activated

May 24 10:58:33 trashcat pppd[26360]: Using interface ppp0

May 24 10:58:33 trashcat pppd[26360]: Connect: ppp0 <--> /dev/pts/2

May 24 10:58:33 trashcat pptp[26366]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 1 'Start-Control-Connection-Request'

May 24 10:58:33 trashcat pptp[26366]: anon log[ctrlp_disp:pptp_ctrl.c:738]: Received Start Control Connection Reply

May 24 10:58:33 trashcat pptp[26366]: anon log[ctrlp_disp:pptp_ctrl.c:772]: Client connection established.

May 24 10:58:34 trashcat pptp[26366]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 7 'Outgoing-Call-Request'

May 24 10:58:34 trashcat pptp[26366]: anon log[ctrlp_disp:pptp_ctrl.c:857]: Received Outgoing Call Reply.

May 24 10:58:34 trashcat pptp[26366]: anon log[ctrlp_disp:pptp_ctrl.c:896]: Outgoing call established (call ID 0, peer's call ID 33501).

May 24 10:58:37 trashcat pppd[26360]: CHAP authentication succeeded

May 24 10:58:37 trashcat pppd[26360]: MPPE 128-bit stateless compression enabled

May 24 10:58:40 trashcat pppd[26360]: local  IP address <ip address>

May 24 10:58:40 trashcat pppd[26360]: remote IP address <ipaddress>

May 24 11:00:34 trashcat pptp[26366]: anon log[pptp_handle_timer:pptp_ctrl.c:1049]: closing control connection due to missing echo reply

May 24 11:00:34 trashcat pptp[26366]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 12 'Call-Clear-Request'

May 24 11:00:34 trashcat pptp[26366]: anon log[pptp_conn_close:pptp_ctrl.c:430]: Closing PPTP connection

May 24 11:00:34 trashcat pptp[26366]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 3 'Stop-Control-Connection-Request'

May 24 11:00:34 trashcat pptp[26366]: anon log[call_callback:pptp_callmgr.c:78]: Closing connection (call state)

May 24 11:00:34 trashcat pppd[26360]: Modem hangup

May 24 11:00:34 trashcat pppd[26360]: Connect time 1.9 minutes.

May 24 11:00:34 trashcat pppd[26360]: Sent 1280934520 bytes, received 0 bytes.

May 24 11:00:34 trashcat pppd[26360]: MPPE disabled

May 24 11:00:34 trashcat pppd[26360]: Connection terminated.

May 24 11:00:34 trashcat pppd[26360]: Exit.

```

Kerplow.

```

May 24 11:00:34 trashcat pptp[26366]: anon log[pptp_handle_timer:pptp_ctrl.c:1049]: closing control connection due to missing echo reply

```

----------

## mrness

A full debug log might help.

----------

## jschweg

how can i enable more logging for ppp?

----------

## mrness

add "debug" to pppd's options.

Now I've just had a revelation. You talked about some big TX counter. I hope when you say <vpnhost> you really mean the private IP address of the server (the one within remotenet). Otherwise you will have the same sad experience as this guy.

----------

## jschweg

 *mrness wrote:*   

> add "debug" to pppd's options.
> 
> Now I've just had a revelation. You talked about some big TX counter. I hope when you say <vpnhost> you really mean the private IP address of the server (the one within remotenet). Otherwise you will have the same sad experience as this guy.

 

I don't have an internal network at work. We have an entire Class C, so we don't use NAT. We have a firewall appliance at the border that transparently filters the traffic. This is the device that I am vpn'ing to. <vpnhost> is a public address, and ppp automatically adds this host entry to the routing table. The network I am adding to the table is the same network that <vpnhost> is on.

I'll go get some more logs.

----------

## jschweg

Here is a log of one session with full debug. Obviously something is going horrible wrong. With the sheer amount of transmit packets present, there must be some type of loop going on. When I go home tonight, I'm going to remove all of my eth0 routes and try connecting again with only the ppp0 routes in the table.

```

May 24 13:36:03 trashcat pppd[14739]: pppd 2.4.4 started by root, uid 0

May 24 13:36:03 trashcat pptp[14740]: anon log[main:pptp.c:272]: The synchronous pptp option is NOT activated

May 24 13:36:03 trashcat pppd[14739]: using channel 8

May 24 13:36:03 trashcat pppd[14739]: Using interface ppp0

May 24 13:36:03 trashcat pppd[14739]: Connect: ppp0 <--> /dev/pts/2

May 24 13:36:03 trashcat pptp[14745]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 1 'Start-Control-Connection-Request'

May 24 13:36:03 trashcat pptp[14745]: anon log[ctrlp_disp:pptp_ctrl.c:738]: Received Start Control Connection Reply

May 24 13:36:03 trashcat pptp[14745]: anon log[ctrlp_disp:pptp_ctrl.c:772]: Client connection established.

May 24 13:36:04 trashcat pppd[14739]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x75ba0c0c> <pcomp> <accomp>]

May 24 13:36:04 trashcat pptp[14745]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 7 'Outgoing-Call-Request'

May 24 13:36:04 trashcat pptp[14745]: anon log[ctrlp_disp:pptp_ctrl.c:857]: Received Outgoing Call Reply.

May 24 13:36:04 trashcat pptp[14745]: anon log[ctrlp_disp:pptp_ctrl.c:896]: Outgoing call established (call ID 0, peer's call ID 49335).

May 24 13:36:04 trashcat pppd[14739]: rcvd [LCP ConfReq id=0x1 <asyncmap 0x0> <auth chap MS-v2> <magic 0x79753188> <pcomp> <accomp>]

May 24 13:36:04 trashcat pppd[14739]: sent [LCP ConfAck id=0x1 <asyncmap 0x0> <auth chap MS-v2> <magic 0x79753188> <pcomp> <accomp>]

May 24 13:36:04 trashcat pppd[14739]: rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0x75ba0c0c> <pcomp> <accomp>]

May 24 13:36:04 trashcat pppd[14739]: rcvd [CHAP Challenge id=0x1 <d37c5ef4f785896f7dce2d1f743ccd54>, name = "PoPToP"]

May 24 13:36:04 trashcat pppd[14739]: sent [CHAP Response id=0x1 <11dec49b6df01478b511023476f15ef800000000000000003f933ce76df7f520bbc8740e73de1b0c37de1e15f2a9b52800>, name = "domain\\me"]

May 24 13:36:04 trashcat pppd[14739]: rcvd [CHAP Success id=0x1 "S=EC8DFBEB742E93F37441463F88EC4949C9EC9303"]

May 24 13:36:04 trashcat pppd[14739]: CHAP authentication succeeded

May 24 13:36:04 trashcat pppd[14739]: sent [CCP ConfReq id=0x1 <mppe +H -M +S -L -D -C>]

May 24 13:36:04 trashcat pppd[14739]: rcvd [IPCP ConfReq id=0x1 <addr 65.206.104.254> <compress VJ 0f 01>]

May 24 13:36:04 trashcat pppd[14739]: sent [IPCP TermAck id=0x1]

May 24 13:36:04 trashcat pppd[14739]: rcvd [CCP ConfReq id=0x1 <mppe +H -M +S +L -D -C>]

May 24 13:36:04 trashcat pppd[14739]: sent [CCP ConfNak id=0x1 <mppe +H -M +S -L -D -C>]

May 24 13:36:04 trashcat pppd[14739]: rcvd [CCP ConfAck id=0x1 <mppe +H -M +S -L -D -C>]

May 24 13:36:04 trashcat pppd[14739]: rcvd [CCP ConfReq id=0x2 <mppe +H -M +S -L -D -C>]

May 24 13:36:04 trashcat pppd[14739]: sent [CCP ConfAck id=0x2 <mppe +H -M +S -L -D -C>]

May 24 13:36:04 trashcat pppd[14739]: MPPE 128-bit stateless compression enabled

May 24 13:36:04 trashcat pppd[14739]: sent [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 0.0.0.0>]

May 24 13:36:04 trashcat pppd[14739]: rcvd [IPCP ConfNak id=0x1 <addr [remoteip]>]

May 24 13:36:04 trashcat pppd[14739]: sent [IPCP ConfReq id=0x2 <compress VJ 0f 01> <addr [remoteip]>]

May 24 13:36:04 trashcat pppd[14739]: rcvd [IPCP ConfAck id=0x2 <compress VJ 0f 01> <addr [remoteip]>]

May 24 13:36:07 trashcat pppd[14739]: rcvd [IPCP ConfReq id=0x1 <addr [vpnserverip]> <compress VJ 0f 01>]

May 24 13:36:07 trashcat pppd[14739]: sent [IPCP ConfAck id=0x1 <addr [vpnserverip> <compress VJ 0f 01>]

May 24 13:36:07 trashcat pppd[14739]: local  IP address [remoteip]

May 24 13:36:07 trashcat pppd[14739]: remote IP address [vpnserverip]

May 24 13:36:07 trashcat pppd[14739]: Script /etc/ppp/ip-up started (pid 14766)

May 24 13:36:07 trashcat pppd[14739]: Script /etc/ppp/ip-up finished (pid 14766), status = 0x1

May 24 13:36:21 trashcat pptp[14740]: anon log[decaps_gre:pptp_gre.c:407]: buffering packet 15 (expecting 11, lost or reordered)

May 24 13:36:21 trashcat pptp[14740]: anon log[decaps_gre:pptp_gre.c:407]: buffering packet 16 (expecting 11, lost or reordered)

May 24 13:36:21 trashcat pptp[14740]: anon log[decaps_gre:pptp_gre.c:407]: buffering packet 17 (expecting 11, lost or reordered)

May 24 13:36:21 trashcat pptp[14740]: anon log[decaps_gre:pptp_gre.c:407]: buffering packet 18 (expecting 11, lost or reordered)

May 24 13:36:21 trashcat pptp[14740]: anon log[decaps_gre:pptp_gre.c:407]: buffering packet 19 (expecting 11, lost or reordered)

May 24 13:36:21 trashcat pptp[14740]: anon log[decaps_gre:pptp_gre.c:407]: buffering packet 20 (expecting 11, lost or reordered)

May 24 13:36:21 trashcat pptp[14740]: anon log[decaps_gre:pptp_gre.c:407]: buffering packet 21 (expecting 11, lost or reordered)

May 24 13:36:21 trashcat pptp[14740]: anon log[decaps_gre:pptp_gre.c:407]: buffering packet 22 (expecting 11, lost or reordered)

May 24 13:36:21 trashcat pptp[14740]: anon log[decaps_gre:pptp_gre.c:407]: buffering packet 23 (expecting 11, lost or reordered)

May 24 13:36:21 trashcat pptp[14740]: anon log[decaps_gre:pptp_gre.c:407]: buffering packet 24 (expecting 11, lost or reordered)

May 24 13:36:21 trashcat pptp[14740]: anon log[decaps_gre:pptp_gre.c:407]: buffering packet 25 (expecting 11, lost or reordered)

May 24 13:36:21 trashcat pptp[14740]: anon log[decaps_gre:pptp_gre.c:407]: buffering packet 26 (expecting 11, lost or reordered)

May 24 13:36:21 trashcat pptp[14740]: anon log[decaps_gre:pptp_gre.c:407]: buffering packet 27 (expecting 11, lost or reordered)

May 24 13:36:21 trashcat pptp[14740]: anon log[decaps_gre:pptp_gre.c:407]: buffering packet 28 (expecting 11, lost or reordered)

May 24 13:36:21 trashcat pptp[14740]: anon log[decaps_gre:pptp_gre.c:407]: buffering packet 29 (expecting 11, lost or reordered)

May 24 13:36:21 trashcat pptp[14740]: anon log[decaps_gre:pptp_gre.c:407]: buffering packet 30 (expecting 11, lost or reordered)

May 24 13:36:21 trashcat pptp[14740]: anon log[decaps_gre:pptp_gre.c:407]: buffering packet 31 (expecting 11, lost or reordered)

May 24 13:36:22 trashcat pppd[14739]: rcvd [LCP ProtRej id=0x2 cc e9 f0 17 75 85 b1 4e 50 c3 38 27 cf 7b 3e 00 62 4b 30 dc dc 98 20 11 90 59 da e4 52 cf bf 69 ...]

May 24 13:36:22 trashcat pppd[14739]: Protocol-Reject for unsupported protocol 0xcce9

May 24 13:36:22 trashcat pppd[14739]: rcvd [LCP ProtRej id=0x3 83 a4 fb 27 2a cb da e3 cd 60 a6 81 57 25 8a e0 ec 4f ea d4 ef c8 aa 7d 9b d7 2d c2 29 0e a1 a9 ...]

May 24 13:36:22 trashcat pppd[14739]: Protocol-Reject for unsupported protocol 0x83a4

May 24 13:36:22 trashcat pppd[14739]: rcvd [LCP ProtRej id=0x4 3d 98 f4 76 5f 27 0a 99 e9 46 68 1d 90 61 53 54 c6 37 23 b4 ca 2a 74 ac 4e b9 e3 28 3e 82 90 08 ...]

May 24 13:36:22 trashcat pppd[14739]: Protocol-Reject for unsupported protocol 0x3d98

May 24 13:36:22 trashcat pppd[14739]: rcvd [LCP ProtRej id=0x5 29 a5 c6 53 65 dc cb 50 78 f7 c2 69 f3 e6 5a 6b a9 ce a1 ad 03 f9 c4 df 4e cd 18 99 d4 d3 db d3 ...]

May 24 13:36:22 trashcat pppd[14739]: Protocol-Reject for unsupported protocol 0x29a5

May 24 13:36:22 trashcat pppd[14739]: rcvd [LCP ProtRej id=0x6 56 28 9c 10 a0 2d b4 ed ea ce 38 be cf 7d e3 6e d3 47 1e 5a 38 e2 7d 5f 20 32 23 68 5d 6c a9 a9 ...]

May 24 13:36:22 trashcat pppd[14739]: Protocol-Reject for unsupported protocol 0x5628

May 24 13:36:22 trashcat pppd[14739]: rcvd [LCP ProtRej id=0x7 82 d5 96 1f bf c2 e4 2a 2f b4 2a 9c bf a8 98 3c 5f 01 69 30 91 01 76 dc 1b a6 8f 47 d3 b5 3e a6 ...]

May 24 13:36:22 trashcat pppd[14739]: Protocol-Reject for unsupported protocol 0x82d5

May 24 13:36:22 trashcat pppd[14739]: rcvd [LCP ProtRej id=0x8 11 c4 6a d2 e5 8b e9 42 0f e0 49 31 94 e3 3c ed 37 ca 3b a4 b9 a4 f1 45 1c 7f e8 ae 44 f6 72 d9 ...]

May 24 13:36:22 trashcat pppd[14739]: Protocol-Reject for unsupported protocol 0x11c4

May 24 13:36:22 trashcat pppd[14739]: rcvd [LCP ProtRej id=0x9 ad e9 8d 75 1d 01 58 af 97 18 f4 e0 a7 a2 26 63 60 cc dc c5 03 c5 fb 1a 90 ee 0a 30 1a 47 09 74 ...]

May 24 13:36:22 trashcat pppd[14739]: rcvd [LCP ProtRej id=0x7 82 d5 96 1f bf c2 e4 2a 2f b4 2a 9c bf a8 98 3c 5f 01 69 30 91 01 76 dc 1b a6 8f 47 d3 b5 3e a6 ...]

May 24 13:36:22 trashcat pppd[14739]: Protocol-Reject for unsupported protocol 0x82d5

May 24 13:36:22 trashcat pppd[14739]: rcvd [LCP ProtRej id=0x8 11 c4 6a d2 e5 8b e9 42 0f e0 49 31 94 e3 3c ed 37 ca 3b a4 b9 a4 f1 45 1c 7f e8 ae 44 f6 72 d9 ...]

May 24 13:36:22 trashcat pppd[14739]: Protocol-Reject for unsupported protocol 0x11c4

May 24 13:36:22 trashcat pppd[14739]: rcvd [LCP ProtRej id=0x9 ad e9 8d 75 1d 01 58 af 97 18 f4 e0 a7 a2 26 63 60 cc dc c5 03 c5 fb 1a 90 ee 0a 30 1a 47 09 74 ...]

May 24 13:36:22 trashcat pppd[14739]: Protocol-Reject for unsupported protocol 0xade9

May 24 13:36:22 trashcat pppd[14739]: rcvd [LCP ProtRej id=0xa d2 a3 ff 39 b5 5b d8 f5 a9 07 a3 ce 2d 29 c6 d8 9c e8 5c 9d 3e ff cc 7f d3 7f 39 85 93 78 80 80 ...]

May 24 13:36:22 trashcat pppd[14739]: Protocol-Reject for unsupported protocol 0xd2a3

May 24 13:36:22 trashcat pppd[14739]: rcvd [LCP ProtRej id=0xb f5 02 4d 0e b5 b5 88 26 0d 34 ba 6c 40 a4 b2 bd af 12 4a 18 f7 14 97 80 d1 02 99 22 ce 03 c0 c3 ...]

May 24 13:36:22 trashcat pppd[14739]: Protocol-Reject for unsupported protocol 0xf502

May 24 13:36:22 trashcat pppd[14739]: rcvd [LCP ProtRej id=0xc a1 d5 f8 80 de 89 6c d8 a4 35 a3 e4 be 56 5b 53 0f de 9f ad 7c b4 01 62 d3 2f 88 f8 0c 71 62 48 ...]

May 24 13:36:22 trashcat pppd[14739]: Protocol-Reject for unsupported protocol 0xa1d5

May 24 13:36:22 trashcat pppd[14739]: rcvd [LCP ProtRej id=0xd 2c f0 00 6e 2d 74 79 58 de bb 5c 9f 5e 74 d5 39 60 f1 3d c5 cd 48 28 7a e9 fc 7f 25 67 7d 71 89 ...]

May 24 13:36:22 trashcat pppd[14739]: Protocol-Reject for unsupported protocol 0x2cf0

May 24 13:36:22 trashcat pppd[14739]: rcvd [LCP ProtRej id=0xe 89 c1 5f 9b 82 db 96 93 07 f1 41 41 35 82 2e a7 d9 66 e2 06 d2 dc f0 ba c9 fb 3e 4d 00 6d 28 7c ...]

May 24 13:36:22 trashcat pppd[14739]: Protocol-Reject for unsupported protocol 0x89c1

May 24 13:36:22 trashcat pppd[14739]: rcvd [LCP ProtRej id=0xf d2 23 d9 e6 9b 2b b7 ce 0f 73 37 a6 e3 c6 cd f7 59 ed 32 da 70 58 4f 5d 78 62 a0 6c 74 da 9b e0 ...]

May 24 13:36:22 trashcat pppd[14739]: Protocol-Reject for unsupported protocol 0xd223

May 24 13:36:22 trashcat pppd[14739]: rcvd [LCP ProtRej id=0x10 99 d2 38 a6 0b fc fa 7f c9 ec 87 be 65 96 67 ae d9 10 43 59 7c 9a e8 30 b8 22 c9 14 eb 00 b6 ac ...]

May 24 13:36:22 trashcat pppd[14739]: Protocol-Reject for unsupported protocol 0x99d2

May 24 13:36:22 trashcat pppd[14739]: rcvd [LCP ProtRej id=0x11 15 d9 fc 80 97 a2 ff 99 16 b1 fb 4e 44 8b 90 0c 43 f4 ee 8e 99 af f4 a6 37 32 fa 19 e2 3d 56 ea ...]

May 24 13:36:22 trashcat pppd[14739]: Protocol-Reject for unsupported protocol 0x15d9

May 24 13:36:22 trashcat pppd[14739]: rcvd [LCP ProtRej id=0x12 82 00 cd 5b b3 b5 19 89 a8 d7 3c 6e 67 38 c5 b4 b2 88 60 06 60 df 36 a2 15 ad 9c e5 bb cc 4e aa ...]

May 24 13:36:22 trashcat pppd[14739]: Protocol-Reject for unsupported protocol 0x8200

May 24 13:36:22 trashcat pppd[14739]: rcvd [IPCP ConfReq id=0x1 <addr [vpnserverip]> <compress VJ 0f 01>]

May 24 13:36:22 trashcat pppd[14739]: Connect time 0.3 minutes.

May 24 13:36:22 trashcat pppd[14739]: Sent 159257354 bytes, received 16 bytes.

May 24 13:36:22 trashcat pppd[14739]: Script /etc/ppp/ip-down started (pid 14857)

May 24 13:36:22 trashcat pppd[14739]: sent [IPCP ConfReq id=0x3 <compress VJ 0f 01> <addr [remoteip]>]

May 24 13:36:22 trashcat pppd[14739]: sent [IPCP ConfAck id=0x1 <addr [vpnserverip]> <compress VJ 0f 01>]

May 24 13:36:22 trashcat pppd[14739]: Script /etc/ppp/ip-down finished (pid 14857), status = 0x1

May 24 13:36:22 trashcat pppd[14739]: rcvd [IPCP ConfAck id=0x3 <compress VJ 0f 01> <addr [remoteip]>]

May 24 13:36:22 trashcat pppd[14739]: local  IP address [remoteip]

May 24 13:36:22 trashcat pppd[14739]: remote IP address [vpnserverip]

May 24 13:36:22 trashcat pppd[14739]: Script /etc/ppp/ip-up started (pid 14858)

May 24 13:36:22 trashcat pppd[14739]: Script /etc/ppp/ip-up finished (pid 14858), status = 0x1

May 24 13:38:04 trashcat pptp[14745]: anon log[pptp_handle_timer:pptp_ctrl.c:1049]: closing control connection due to missing echo reply

May 24 13:38:04 trashcat pptp[14745]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 12 'Call-Clear-Request'

May 24 13:38:04 trashcat pptp[14745]: anon log[pptp_conn_close:pptp_ctrl.c:430]: Closing PPTP connection

May 24 13:38:04 trashcat pptp[14745]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 3 'Stop-Control-Connection-Request'

May 24 13:38:04 trashcat pptp[14745]: anon log[call_callback:pptp_callmgr.c:78]: Closing connection (call state)

May 24 13:38:04 trashcat pppd[14739]: Script pptp [vpnserverip] --nolaunchpppd finished (pid 14740), status = 0x0

May 24 13:38:04 trashcat pppd[14739]: Modem hangup

May 24 13:38:04 trashcat pppd[14739]: Connect time 1.7 minutes.

May 24 13:38:04 trashcat pppd[14739]: Sent 1127366974 bytes, received 0 bytes.

May 24 13:38:04 trashcat pppd[14739]: Script /etc/ppp/ip-down started (pid 15444)

May 24 13:38:04 trashcat pppd[14739]: MPPE disabled

May 24 13:38:04 trashcat pppd[14739]: sent [LCP TermReq id=0x2 "MPPE disabled"]

May 24 13:38:04 trashcat pppd[14739]: Connection terminated.

May 24 13:38:04 trashcat pppd[14739]: Script /etc/ppp/ip-down finished (pid 15444), status = 0x1

May 24 13:38:04 trashcat pppd[14739]: Exit.

```

----------

## jschweg

Failure yet again. I tried removing all the eth0 routes and making everything go through ppp0. Same thing, the TX packets just go nuts until the connection drops.

----------

## mrness

I've just told you to be sure that server public IP address go through eth0. Now why would you delete all eth0 routes?

Lets assume your private network is 192.168.0.0/24, with .1 on server, .2 on your host and 1.2.3.4 as your server public IP. What you should see is this:

```

local  IP address 192.168.0.2

remote IP address 192.168.0.1

Script /etc/ppp/ip-up started (pid ...)

Script /etc/ppp/ip-up finished (pid ...), status = 0x1

```

and have 2 ppp0 routes:

   192.168.0.1 * 255.255.255.255

   192.168.0.0 * 255.255.255.0

Also, you must check that your kernel has all CONFIG_PPP* switches enabled (zgrep CONFIG_PPP /proc/config.gz).

----------

## jschweg

 *mrness wrote:*   

> I've just told you to be sure that server public IP address go through eth0. Now why would you delete all eth0 routes?

 

Sorry, just getting ahead of myself.

The problem was exactly what your revelation was yesterday when you posted that other thread. I connected the VPN, then added a default route for the ip address of the vpn server to use the gateway on eth0. VPN was stable at that point. Then I just added the route for the private network to ppp0 and I can now ping all of my machines.

One last question. As soon as I connect the vpn, it automatically creates a route to send everything destined for the vpn server ip through ppp0. This is obviously the route that causes everything to go haywire. How can I stop that route from automatically being created?

EDIT: In reality it doesn't really matter since my route to eth0 will always override this one anyway...

I figure I'll just add my own permanent route to that host through eth0 in /etc/conf.d/net and then dynamically add the route to the internal network at the end of the ip-up script.

Thanks for sticking with me on this, I'm really happy this is working  :Smile: 

----------

## mrness

[quote="jschweg"] *mrness wrote:*   

> One last question. As soon as I connect the vpn, it automatically creates a route to send everything destined for the vpn server ip through ppp0. This is obviously the route that causes everything to go haywire. How can I stop that route from automatically being created?

 

The peer is to blame for that. Lets say the peer's default route is through eth1 and eth0 is the local area network of your company.

A correctly configured PPTP server will use the IP configured on eth0 as remote IP for the PPTP clients. Ask your admin to change the configuration on server.

The host route installed by pppd at the start of every PPP link cannot be changed... unless you alter/delete it in ip-up script.

EDIT:

You can correct remote IP by removing ipcp-accept-remote option and adding instead ":correct_remote_IP". 

However, this is a hack. You really should make your network admin fix erroneous server configuration.

----------

## mrness

 *mrness wrote:*   

> You can't have 2 default routes with the same metric, but you can have 2 default routes with _different_ metrics.
> 
> You should set your primary default route with a metric > 1 (say 5), then pppd will be able to create the default route you want.

 

I was wrong. I fixed that in ppp-2.4.4-r10, version in which I've also added a new option called defaultmetric.

----------

