Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 9 replies
  • Subscribers 3 subscribers
  • Views 20420 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

pptp interface, mppe negotiation.

irrelevant

 Hi!

I'm running UTM 9, up to date, home licence, and am trying to set up the PPOA/PPTP interface option to connect to a VPN provider.  This /almost/ works... but I'm seeing an mppe error causing the connection to abort :

 

2017:05:26-11:28:30 utm pppd-pppoa[29551]: pppd 2.4.6 started by (unknown), uid 0
2017:05:26-11:28:30 utm pppd-pppoa[29551]: Couldn't open pty slave /dev/pts/0: No such file or directory
2017:05:26-11:28:30 utm pppd-pppoa[29551]: using channel 70
2017:05:26-11:28:30 utm pppd-pppoa[29551]: Using interface ppp0
2017:05:26-11:28:30 utm pppd-pppoa[29551]: Connect: ppp0 <--> /dev/ttyp0
2017:05:26-11:28:31 utm pppd-pppoa[29551]: sent [LCP ConfReq id=0x1 <mru 1492> <asyncmap 0x0> <magic 0xb3d3942d> <pcomp> <accomp>]
2017:05:26-11:28:32 utm pppd-pppoa[29551]: rcvd [LCP ConfReq id=0x1 <mru 1396> <asyncmap 0x0> <auth chap MS-v2> <magic 0x77597a69> <pcomp> <accomp>]
2017:05:26-11:28:32 utm pppd-pppoa[29551]: sent [LCP ConfAck id=0x1 <mru 1396> <asyncmap 0x0> <auth chap MS-v2> <magic 0x77597a69> <pcomp> <accomp>]
2017:05:26-11:28:32 utm pppd-pppoa[29551]: rcvd [LCP ConfAck id=0x1 <mru 1492> <asyncmap 0x0> <magic 0xb3d3942d> <pcomp> <accomp>]
2017:05:26-11:28:32 utm pppd-pppoa[29551]: sent [LCP EchoReq id=0x0 magic=0xb3d3942d]
2017:05:26-11:28:32 utm pppd-pppoa[29551]: rcvd [CHAP Challenge id=0x64 <8bf41547fa296a2649198aa065f1837a>, name = "pptpd"]
2017:05:26-11:28:32 utm pppd-pppoa[29551]: sent [CHAP Response id=0x64 <xxxx...xxxx>, name = "xxx@xxx"]
2017:05:26-11:28:32 utm pppd-pppoa[29551]: rcvd [LCP EchoRep id=0x0 magic=0x77597a69]
2017:05:26-11:28:32 utm pppd-pppoa[29551]: rcvd [CHAP Success id=0x64 "S=5D42E0934C167A69FAA0B02B6E0EDC09421A2062"]
2017:05:26-11:28:32 utm pppd-pppoa[29551]: CHAP authentication succeeded
2017:05:26-11:28:32 utm pppd-pppoa[29551]: sent [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>]
2017:05:26-11:28:32 utm pppd-pppoa[29551]: sent [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
2017:05:26-11:28:32 utm pppd-pppoa[29551]: sent [IPV6CP ConfReq id=0x1 <addr fe80::1106:4a53:b69f:4fbd>]
2017:05:26-11:28:32 utm pppd-pppoa[29551]: rcvd [CCP ConfReq id=0x1 <mppe +H -M +S -L -D -C>]
2017:05:26-11:28:32 utm pppd-pppoa[29551]: sent [CCP ConfRej id=0x1 <mppe +H -M +S -L -D -C>]
2017:05:26-11:28:32 utm pppd-pppoa[29551]: rcvd [LCP TermReq id=0x2 "MPPE required but peer negotiation failed"]
2017:05:26-11:28:32 utm pppd-pppoa[29551]: LCP terminated by peer (MPPE required but peer negotiation failed)
2017:05:26-11:28:32 utm pppd-pppoa[29551]: sent [LCP TermAck id=0x2]
2017:05:26-11:28:32 utm pppd-pppoa[29551]: rcvd [CCP ConfRej id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>]
2017:05:26-11:28:32 utm pppd-pppoa[29551]: Discarded non-LCP packet when LCP not open
2017:05:26-11:28:32 utm pppd-pppoa[29551]: Script /usr/sbin/pptp-current 216.151.180.39 --nolaunchpppd finished (pid 29552), status = 0x0
2017:05:26-11:28:32 utm pppd-pppoa[29551]: Modem hangup
2017:05:26-11:28:32 utm pppd-pppoa[29551]: Connection terminated.
2017:05:26-11:28:32 utm pppd-pppoa[29551]: Exit.

 

Some digging would imply that it's related to this issue: http://pptpclient.sourceforge.net/howto-diagnosis.phtml#mppe_rbpnf 

Has the patch mentioned in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=294232  been applied to the version of pptpclient on the UTM? 

Has anybody got any suggestions?

 

Thanks.!



This thread was automatically locked due to age.
Parents
  • 0

    "... UTM 9, up to date ..."

    9.411, 9.413 or 9.500?

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson

    Ah. 9.413.  But I've now updated to 9.500, and it still fails with the same error.

    Thanks ....

  • 0 in reply to irrelevant

    I didn't read your OP closely enough.  "... trying to set up the PPOA/PPTP interface option to connect to a VPN provider" has never worked for anyone that's tried it in the time that I've been active here in these forums, 10+ years.  It's not possible to make the UTM a client of a Remote Access server.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
Reply
  • 0 in reply to irrelevant

    I didn't read your OP closely enough.  "... trying to set up the PPOA/PPTP interface option to connect to a VPN provider" has never worked for anyone that's tried it in the time that I've been active here in these forums, 10+ years.  It's not possible to make the UTM a client of a Remote Access server.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
Children
  • 0 in reply to BAlfson

    Hi

    and i can confirm what balfson said. Many of us tried including me.

    Simply doesn't work utm as vpn client of a vpn service. 

  • 0 in reply to BAlfson

    I know it's been a tricky one for everybody...

    BUT...

    I've been doing some playing.  If I ssh into the utm whilst it is trying to connect, and add the line

    require-mppe-128

    to /var/sec/chroot-pptpc/etc/ppp/peers/REF_IntPppVpn

    then it connects, and the link shows "up" in the Interfaces section!

    This file is removed when the link is disabled... so I assume there is a template somewhere else...

    However, it doesn't work yet ... and I get

    ....
    2017:05:29-00:25:43 utm pppoa-sh: pptpc[25107] process checking successful <eth4#REF_IntPppVpn>
    2017:05:29-00:25:43 utm pppoa-sh: pptpc[25107] verifying peer IP connectivity (0/8) <eth4#REF_IntPppVpn> 8.8.8.8
    2017:05:29-00:25:49 utm pppoa-sh: pptpc[25107] good peer IP connectivity 4/4 <eth4#REF_IntPppVpn> 8.8.8.8
    2017:05:29-00:26:08 utm pppd-pppoa[30515]: No response to 5 echo-requests
    2017:05:29-00:26:08 utm pppd-pppoa[30515]: Serial link appears to be disconnected.
    2017:05:29-00:26:08 utm pppd-pppoa[30515]: Connect time 1.0 minutes.
    2017:05:29-00:26:08 utm pppd-pppoa[30515]: Sent 1202245245 bytes, received 0 bytes.
    2017:05:29-00:26:08 utm pppd-pppoa[30515]: Script /etc/ppp/ip-down started (pid 30781)
    2017:05:29-00:26:08 utm pppd-pppoa[30515]: MPPE disabled
     
    So sending (lots?? of) packets but receiving none... maybe I have some routing to debug ...  but it's one step closer..

     

  • 0 in reply to irrelevant

    A little closer... If I delete the route-to-vpn-server-via-tunnel, which causes an IP Loop, I start seeing data on the tunnel!  

    But getting lots of Protocol-Reject for (random number) messages in the log whenever I do try and send traffic over it (and thus no connectivity.)

    Oh this is fun ... maybe ...

  • 0 in reply to irrelevant

    yay!

    C:\Users\user>tracert 213.168.250.191

    Tracing route to staeu82.wsynth.net [213.168.250.191]
    over a maximum of 30 hops:

    1 <1 ms <1 ms <1 ms 192.168.0.21
    2 92 ms 92 ms 93 ms 216-151-180-39.wlvpn.com [216.151.180.39]
    3 93 ms 93 ms 93 ms unknown.puregig.net [64.145.79.1]
    4 95 ms 94 ms 99 ms be4377.210.ccr21.jfk04.atlas.cogentco.com [38.104.72.69]
    5 94 ms 93 ms 94 ms be2324.ccr41.jfk02.atlas.cogentco.com [154.54.47.17]
    6 162 ms 161 ms 161 ms be2317.ccr41.lon13.atlas.cogentco.com [154.54.30.186]
    7 164 ms 162 ms 161 ms be2868.ccr21.lon01.atlas.cogentco.com [154.54.57.154]
    8 168 ms 171 ms 167 ms 204.68.252.86
    9 172 ms 168 ms 171 ms 109.74.207.11
    10 168 ms 168 ms 170 ms staeu82.wsynth.net [213.168.250.191]

    Trace complete.

    192.168.0.21 is the UTM.

     

    I manually added 

    require-mppe-40
    passive
    persist
    noaccomp

    to /var/sec/chroot-pptpc/etc/ppp/peers/REF_IntPppVpn

    Not sure which are the essentials, but that's what I ended up with...

    Then delete the self-referencing route it created on connection.

    (the "Protocol-Reject for unsupported protocol"s I was getting in the log seem to be related to a difference of opinion of 40 or 128 bits... 
    ref; http://pptpclient.sourceforge.net/howto-diagnosis.phtml#mppc - this might be specific to my VPN provider!)

     

    Now to work out how to "fix" these, as I don't want to have to enable ssh and do it manually every time the connection resets!

    And then I can set up some routing...

  • 0 in reply to irrelevant

    You're getting much closer than anyone else has gotten.  At some point, this should be added to the feature suggestion that I believe already exists in Ideas.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson

    Well I found if I add the parameters to ..etc/ppp/peers-default they get copied to the new options file on enabling the link.

    But after that initial success, I've not got it working again since... grr... But at least I now know it CAN work ...!  

    There must be something else I changed, but not quite got to grips on it yet.  Previously I was just kill -HUP the connection, which obviously didn't reset things as thoroughly as disabling and re-enabling it does... 

Unfiltered HTML