ppp tunnel fails under load - PPP

This is a discussion on ppp tunnel fails under load - PPP ; I have 2 linux boxes acting as firewalls (one at each office). I have now added pptp VPN tunnel capability using pppd and poptop. I can succesfully establish tunnels between the firewalls, and successfully route traffic over the tunnel. This ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: ppp tunnel fails under load

  1. ppp tunnel fails under load

    I have 2 linux boxes acting as firewalls (one at each office). I have
    now added pptp VPN tunnel capability using pppd and poptop. I can
    succesfully establish tunnels between the firewalls, and successfully
    route traffic over the tunnel.

    This works great for low volume data transfer (mail/ssh) but as soon as
    the volume of data increases the tunnel crashes. Although both sites
    show the tunnel as running (ps ax | grep ppp), neither side can ping
    the other. After crashing, one side of the tunnel always shows this
    error in syslog (repeated many times):

    pptp[6813]: OCGtunnel warn[decaps_greptp_gre.c:351]: Discarding GRE:
    7D 9274 0 40 20 E

    and the pptp.log file then fills with errors like this:

    Protocol-Reject for unsupported protocol 0x3f
    Protocol-Reject for unsupported protocol 0x73
    Protocol-Reject for unsupported protocol 0xc0c5
    Protocol-Reject for unsupported protocol 0x8277
    Protocol-Reject for unsupported protocol 0xf1
    Protocol-Reject for unsupported protocol 0xc007
    Protocol-Reject for unsupported protocol 0x69
    Protocol-Reject for unsupported protocol 0x50cc
    Protocol-Reject for unsupported protocol 0xcd
    Protocol-Reject for unsupported protocol 0x640c
    Protocol-Reject for unsupported protocol 0xb3
    Protocol-Reject for unsupported protocol 0xbe6e
    Protocol-Reject for unsupported protocol 0x31
    Protocol-Reject for unsupported protocol 0x46c2
    Protocol-Reject for unsupported protocol 0xb9
    Protocol-Reject for unsupported protocol 0x18c7
    Protocol-Reject for unsupported protocol 0xa61a
    Protocol-Reject for unsupported protocol 0x94e9
    Protocol-Reject for unsupported protocol 0xaad
    Protocol-Reject for unsupported protocol 0xceaa
    Protocol-Reject for unsupported protocol 0xc5
    Protocol-Reject for unsupported protocol 0x45
    Protocol-Reject for unsupported protocol 0x9b
    Protocol-Reject for unsupported protocol 0x91
    Protocol-Reject for unsupported protocol 0xab
    Protocol-Reject for unsupported protocol 0xf
    Protocol-Reject for unsupported protocol 0x64b
    Protocol-Reject for unsupported protocol 0x75
    Protocol-Reject for unsupported protocol 0x444f
    Protocol-Reject for unsupported protocol 0xe08c
    Protocol-Reject for unsupported protocol 0xdf
    Protocol-Reject for unsupported protocol 0x71
    Protocol-Reject for unsupported protocol 0x3a6d
    Protocol-Reject for unsupported protocol 0xd2ba
    Protocol-Reject for unsupported protocol 0xf486
    Protocol-Reject for unsupported protocol 0x662c
    Protocol-Reject for unsupported protocol 0x8a48
    Protocol-Reject for unsupported protocol 0x5c05
    Protocol-Reject for unsupported protocol 0x5
    Protocol-Reject for unsupported protocol 0x77
    Protocol-Reject for unsupported protocol 0x6ae1
    Protocol-Reject for unsupported protocol 0x55
    Protocol-Reject for unsupported protocol 0x87

    I start the tunnel with "pppd call OCGTunnel". (See the file below)

    Strangely, if I use a windows client to create the PPTP connection (to
    either firewall), I can move high volume traffic without problem. The
    problem only exists when creating a tunnel between the two Linux
    firewalls. This seems to suggest a pppd problem...

    The only way to restore the tunnel is to kill the process and restart.
    Can anyone offer insight as to what cause causing the tunnel to hangup?
    Even better, how to fix it??

    Thanks,
    Michelle

    -----------------

    Contents of my call file (in /etc/ppp/peers/OCGTunnel):

    pty "pptp server1.domain.com --nolaunchpppd --logstring OCGtunnel
    --loglevel 0"
    name domain\\username
    require-mschap-v2
    file /etc/ppp/options.pptp
    ipparam OCGTunnelName
    logfile /var/log/pptp.log
    persist
    maxfail 0

    -----------------

    Conents of my options.pptp

    lock
    noauth
    refuse-eap
    refuse-chap
    refuse-mschap
    nobsdcomp
    nodeflate
    require-mppe-128
    lcp-echo-interval 5
    lcp-echo-failure 5
    maxfail 0
    mtu 1396

    -----------------

    Contents of my options.pptpd

    name pptpd
    refuse-pap
    refuse-chap
    refuse-mschap
    require-mschap-v2
    require-mppe-128
    ms-dns 172.31.254.32
    lock
    nobsdcomp
    novj
    novjccomp
    nologfd
    lcp-echo-interval 5
    lcp-echo-failure 5
    maxfail 0
    mtu 1396

    --------------------

    Contents of /etc/pptpd.conf

    option /etc/ppp/options.pptpd
    logwtmp
    localip 172.31.215.1-100
    remoteip 172.31.215.1-100


  2. Re: ppp tunnel fails under load

    support@ocg.ca writes:

    >I have 2 linux boxes acting as firewalls (one at each office). I have
    >now added pptp VPN tunnel capability using pppd and poptop. I can
    >succesfully establish tunnels between the firewalls, and successfully
    >route traffic over the tunnel.


    >This works great for low volume data transfer (mail/ssh) but as soon as
    >the volume of data increases the tunnel crashes. Although both sites
    >show the tunnel as running (ps ax | grep ppp), neither side can ping
    >the other. After crashing, one side of the tunnel always shows this
    >error in syslog (repeated many times):


    >pptp[6813]: OCGtunnel warn[decaps_greptp_gre.c:351]: Discarding GRE:
    >7D 9274 0 40 20 E


    >and the pptp.log file then fills with errors like this:


    Ssomehow your system is dropping back into ppp negotiation.



    >Protocol-Reject for unsupported protocol 0x3f

    .....


    >I start the tunnel with "pppd call OCGTunnel". (See the file below)


    I have never used it so my comments will be far from authoritative.


    >Strangely, if I use a windows client to create the PPTP connection (to
    >either firewall), I can move high volume traffic without problem. The
    >problem only exists when creating a tunnel between the two Linux
    >firewalls. This seems to suggest a pppd problem...


    >The only way to restore the tunnel is to kill the process and restart.
    >Can anyone offer insight as to what cause causing the tunnel to hangup?
    > Even better, how to fix it??


    >Thanks,
    >Michelle


    >-----------------


    >Contents of my call file (in /etc/ppp/peers/OCGTunnel):


    >pty "pptp server1.domain.com --nolaunchpppd --logstring OCGtunnel
    >--loglevel 0"
    >name domain\\username
    >require-mschap-v2


    Why in the world are you using mschap for authentication between two Linux
    systems. It is a horrible authentication.

    >file /etc/ppp/options.pptp
    >ipparam OCGTunnelName
    >logfile /var/log/pptp.log


    Have you looked in the logfile?

    >persist
    >maxfail 0


    >-----------------


    >Conents of my options.pptp


    >lock
    >noauth


    This makes no sense whatsoever. YOu say in the main that you want them to
    use mschap and then you say noauth.

    >refuse-eap
    >refuse-chap
    >refuse-mschap
    >nobsdcomp
    >nodeflate
    >require-mppe-128


    Why?

    >lcp-echo-interval 5
    >lcp-echo-failure 5
    >maxfail 0
    >mtu 1396


    >-----------------


    >Contents of my options.pptpd


    >name pptpd
    >refuse-pap
    >refuse-chap
    >refuse-mschap
    >require-mschap-v2
    >require-mppe-128
    >ms-dns 172.31.254.32
    >lock
    >nobsdcomp
    >novj
    >novjccomp
    >nologfd
    >lcp-echo-interval 5
    >lcp-echo-failure 5
    >maxfail 0
    >mtu 1396


    >--------------------


    >Contents of /etc/pptpd.conf


    >option /etc/ppp/options.pptpd
    >logwtmp
    >localip 172.31.215.1-100
    >remoteip 172.31.215.1-100





  3. Re: ppp tunnel fails under load

    Here are the answers:

    1. I use mschap authentication to keep a single authentication
    mechanism for all clients (Windows clients or Linux peers).

    2. I posted the log file contents in my original messages. It includes
    primarily the "Protocol-Reject for unsupported protocol"

    3. The NOAUTH settings (as I understand it) indicates that the
    receiving peer does not need to authenticate back to the calling peer.
    The caller still uses MSCHAP to authenticate.

    4. I don't understand the "why" question.

    Any ideas/suggestions about the original problem?

    MD


    Unruh wrote:
    > support@ocg.ca writes:
    >
    > >I have 2 linux boxes acting as firewalls (one at each office). I have
    > >now added pptp VPN tunnel capability using pppd and poptop. I can
    > >succesfully establish tunnels between the firewalls, and successfully
    > >route traffic over the tunnel.

    >
    > >This works great for low volume data transfer (mail/ssh) but as soon as
    > >the volume of data increases the tunnel crashes. Although both sites
    > >show the tunnel as running (ps ax | grep ppp), neither side can ping
    > >the other. After crashing, one side of the tunnel always shows this
    > >error in syslog (repeated many times):

    >
    > >pptp[6813]: OCGtunnel warn[decaps_greptp_gre.c:351]: Discarding GRE:
    > >7D 9274 0 40 20 E

    >
    > >and the pptp.log file then fills with errors like this:

    >
    > Ssomehow your system is dropping back into ppp negotiation.
    >
    >
    >
    > >Protocol-Reject for unsupported protocol 0x3f

    > ....
    >
    >
    > >I start the tunnel with "pppd call OCGTunnel". (See the file below)

    >
    > I have never used it so my comments will be far from authoritative.
    >
    >
    > >Strangely, if I use a windows client to create the PPTP connection (to
    > >either firewall), I can move high volume traffic without problem. The
    > >problem only exists when creating a tunnel between the two Linux
    > >firewalls. This seems to suggest a pppd problem...

    >
    > >The only way to restore the tunnel is to kill the process and restart.
    > >Can anyone offer insight as to what cause causing the tunnel to hangup?
    > > Even better, how to fix it??

    >
    > >Thanks,
    > >Michelle

    >
    > >-----------------

    >
    > >Contents of my call file (in /etc/ppp/peers/OCGTunnel):

    >
    > >pty "pptp server1.domain.com --nolaunchpppd --logstring OCGtunnel
    > >--loglevel 0"
    > >name domain\\username
    > >require-mschap-v2

    >
    > Why in the world are you using mschap for authentication between two Linux
    > systems. It is a horrible authentication.
    >
    > >file /etc/ppp/options.pptp
    > >ipparam OCGTunnelName
    > >logfile /var/log/pptp.log

    >
    > Have you looked in the logfile?
    >
    > >persist
    > >maxfail 0

    >
    > >-----------------

    >
    > >Conents of my options.pptp

    >
    > >lock
    > >noauth

    >
    > This makes no sense whatsoever. YOu say in the main that you want them to
    > use mschap and then you say noauth.
    >
    > >refuse-eap
    > >refuse-chap
    > >refuse-mschap
    > >nobsdcomp
    > >nodeflate
    > >require-mppe-128

    >
    > Why?
    >
    > >lcp-echo-interval 5
    > >lcp-echo-failure 5
    > >maxfail 0
    > >mtu 1396

    >
    > >-----------------

    >
    > >Contents of my options.pptpd

    >
    > >name pptpd
    > >refuse-pap
    > >refuse-chap
    > >refuse-mschap
    > >require-mschap-v2
    > >require-mppe-128
    > >ms-dns 172.31.254.32
    > >lock
    > >nobsdcomp
    > >novj
    > >novjccomp
    > >nologfd
    > >lcp-echo-interval 5
    > >lcp-echo-failure 5
    > >maxfail 0
    > >mtu 1396

    >
    > >--------------------

    >
    > >Contents of /etc/pptpd.conf

    >
    > >option /etc/ppp/options.pptpd
    > >logwtmp
    > >localip 172.31.215.1-100
    > >remoteip 172.31.215.1-100



  4. Re: ppp tunnel fails under load

    Based on posts from some of the more technical folks, it appeared to be
    a compression algorythm error. Using noccp (disabling compression) the
    crashing has stopped.

    Does anyone have experience on how to force other compression
    algorythms from default?

    As for authentication, is there a way to make the tunnel use a
    different authentication mechanism (perhaps Linux's built in accounts)
    - while leaving mschapv2 for other callers?

    Michelle wrote:
    > Here are the answers:
    >
    > 1. I use mschap authentication to keep a single authentication
    > mechanism for all clients (Windows clients or Linux peers).
    >
    > 2. I posted the log file contents in my original messages. It includes
    > primarily the "Protocol-Reject for unsupported protocol"
    >
    > 3. The NOAUTH settings (as I understand it) indicates that the
    > receiving peer does not need to authenticate back to the calling peer.
    > The caller still uses MSCHAP to authenticate.
    >
    > 4. I don't understand the "why" question.
    >
    > Any ideas/suggestions about the original problem?
    >
    > MD
    >
    >
    > Unruh wrote:
    > > support@ocg.ca writes:
    > >
    > > >I have 2 linux boxes acting as firewalls (one at each office). I have
    > > >now added pptp VPN tunnel capability using pppd and poptop. I can
    > > >succesfully establish tunnels between the firewalls, and successfully
    > > >route traffic over the tunnel.

    > >
    > > >This works great for low volume data transfer (mail/ssh) but as soon as
    > > >the volume of data increases the tunnel crashes. Although both sites
    > > >show the tunnel as running (ps ax | grep ppp), neither side can ping
    > > >the other. After crashing, one side of the tunnel always shows this
    > > >error in syslog (repeated many times):

    > >
    > > >pptp[6813]: OCGtunnel warn[decaps_greptp_gre.c:351]: Discarding GRE:
    > > >7D 9274 0 40 20 E

    > >
    > > >and the pptp.log file then fills with errors like this:

    > >
    > > Ssomehow your system is dropping back into ppp negotiation.
    > >
    > >
    > >
    > > >Protocol-Reject for unsupported protocol 0x3f

    > > ....
    > >
    > >
    > > >I start the tunnel with "pppd call OCGTunnel". (See the file below)

    > >
    > > I have never used it so my comments will be far from authoritative.
    > >
    > >
    > > >Strangely, if I use a windows client to create the PPTP connection (to
    > > >either firewall), I can move high volume traffic without problem. The
    > > >problem only exists when creating a tunnel between the two Linux
    > > >firewalls. This seems to suggest a pppd problem...

    > >
    > > >The only way to restore the tunnel is to kill the process and restart.
    > > >Can anyone offer insight as to what cause causing the tunnel to hangup?
    > > > Even better, how to fix it??

    > >
    > > >Thanks,
    > > >Michelle

    > >
    > > >-----------------

    > >
    > > >Contents of my call file (in /etc/ppp/peers/OCGTunnel):

    > >
    > > >pty "pptp server1.domain.com --nolaunchpppd --logstring OCGtunnel
    > > >--loglevel 0"
    > > >name domain\\username
    > > >require-mschap-v2

    > >
    > > Why in the world are you using mschap for authentication between two Linux
    > > systems. It is a horrible authentication.
    > >
    > > >file /etc/ppp/options.pptp
    > > >ipparam OCGTunnelName
    > > >logfile /var/log/pptp.log

    > >
    > > Have you looked in the logfile?
    > >
    > > >persist
    > > >maxfail 0

    > >
    > > >-----------------

    > >
    > > >Conents of my options.pptp

    > >
    > > >lock
    > > >noauth

    > >
    > > This makes no sense whatsoever. YOu say in the main that you want them to
    > > use mschap and then you say noauth.
    > >
    > > >refuse-eap
    > > >refuse-chap
    > > >refuse-mschap
    > > >nobsdcomp
    > > >nodeflate
    > > >require-mppe-128

    > >
    > > Why?
    > >
    > > >lcp-echo-interval 5
    > > >lcp-echo-failure 5
    > > >maxfail 0
    > > >mtu 1396

    > >
    > > >-----------------

    > >
    > > >Contents of my options.pptpd

    > >
    > > >name pptpd
    > > >refuse-pap
    > > >refuse-chap
    > > >refuse-mschap
    > > >require-mschap-v2
    > > >require-mppe-128
    > > >ms-dns 172.31.254.32
    > > >lock
    > > >nobsdcomp
    > > >novj
    > > >novjccomp
    > > >nologfd
    > > >lcp-echo-interval 5
    > > >lcp-echo-failure 5
    > > >maxfail 0
    > > >mtu 1396

    > >
    > > >--------------------

    > >
    > > >Contents of /etc/pptpd.conf

    > >
    > > >option /etc/ppp/options.pptpd
    > > >logwtmp
    > > >localip 172.31.215.1-100
    > > >remoteip 172.31.215.1-100



  5. Re: ppp tunnel fails under load

    Michelle wrote:
    > Based on posts from some of the more technical folks, it appeared to be
    > a compression algorythm error. Using noccp (disabling compression) the
    > crashing has stopped.


    > Does anyone have experience on how to force other compression
    > algorythms from default?


    No experience, but from posts by "more technical folks" here it would be
    best to avoid any CCP algorithm. Microsoft Point-to-Point Compression
    (MPPC) is patented and can't legally (in the U.S. anyway) be part of an
    open source PPP implementation such as pppd. The CCP algorithms that
    are in pppd won't be found in any MS implementation, and I wouldn't be
    surprised if it turned out that the PPTP version of Generic Routing
    Encapsulation (GRE) chokes on non-MPPC compressed data even for a
    Linux-to-Linux PPTP tunnel. Oh, and you can't force a CCP algorithm,
    only request it.

    > As for authentication, is there a way to make the tunnel use a
    > different authentication mechanism (perhaps Linux's built in accounts)
    > - while leaving mschapv2 for other callers?


    If it works now, why change? Changing won't stop MS from being egregious.

    --
    Clifford Kite
    /* I hear and I forget. I see and I remember. I do and I understand.
    --Confucius, 551-479 BC */

  6. Re: ppp tunnel fails under load

    "Michelle" writes:

    >Here are the answers:


    >1. I use mschap authentication to keep a single authentication
    >mechanism for all clients (Windows clients or Linux peers).


    >2. I posted the log file contents in my original messages. It includes
    >primarily the "Protocol-Reject for unsupported protocol"


    No, the log file from before the problem started. Not the log file during
    the problem which shows that your ppp is trying to interpret the data
    stream as ppp negotiations.

    >3. The NOAUTH settings (as I understand it) indicates that the
    >receiving peer does not need to authenticate back to the calling peer.


    No, it indicates that the receiving peer does not require the remote end to
    authenticate. authentication is up to the peer. You cannot tell the other
    end not to demand authentication. That is solely its prerogative-- at best
    you can refuse, in which case he will hang up.

    >The caller still uses MSCHAP to authenticate.


    Then you do not want noauth.


    >4. I don't understand the "why" question.


    Why do you require-mppe-128


    >Any ideas/suggestions about the original problem?


    Yes, make sure that you have the debug option set, and post the full logs
    from when you start the connection to the point at which the trouble
    starts.



    >MD



    >Unruh wrote:
    >> support@ocg.ca writes:
    >>
    >> >I have 2 linux boxes acting as firewalls (one at each office). I have
    >> >now added pptp VPN tunnel capability using pppd and poptop. I can
    >> >succesfully establish tunnels between the firewalls, and successfully
    >> >route traffic over the tunnel.

    >>
    >> >This works great for low volume data transfer (mail/ssh) but as soon as
    >> >the volume of data increases the tunnel crashes. Although both sites
    >> >show the tunnel as running (ps ax | grep ppp), neither side can ping
    >> >the other. After crashing, one side of the tunnel always shows this
    >> >error in syslog (repeated many times):

    >>
    >> >pptp[6813]: OCGtunnel warn[decaps_greptp_gre.c:351]: Discarding GRE:
    >> >7D 9274 0 40 20 E

    >>
    >> >and the pptp.log file then fills with errors like this:

    >>
    >> Ssomehow your system is dropping back into ppp negotiation.
    >>
    >>
    >>
    >> >Protocol-Reject for unsupported protocol 0x3f

    >> ....
    >>
    >>
    >> >I start the tunnel with "pppd call OCGTunnel". (See the file below)

    >>
    >> I have never used it so my comments will be far from authoritative.
    >>
    >>
    >> >Strangely, if I use a windows client to create the PPTP connection (to
    >> >either firewall), I can move high volume traffic without problem. The
    >> >problem only exists when creating a tunnel between the two Linux
    >> >firewalls. This seems to suggest a pppd problem...

    >>
    >> >The only way to restore the tunnel is to kill the process and restart.
    >> >Can anyone offer insight as to what cause causing the tunnel to hangup?
    >> > Even better, how to fix it??

    >>
    >> >Thanks,
    >> >Michelle

    >>
    >> >-----------------

    >>
    >> >Contents of my call file (in /etc/ppp/peers/OCGTunnel):

    >>
    >> >pty "pptp server1.domain.com --nolaunchpppd --logstring OCGtunnel
    >> >--loglevel 0"
    >> >name domain\\username
    >> >require-mschap-v2

    >>
    >> Why in the world are you using mschap for authentication between two Linux
    >> systems. It is a horrible authentication.
    >>
    >> >file /etc/ppp/options.pptp
    >> >ipparam OCGTunnelName
    >> >logfile /var/log/pptp.log

    >>
    >> Have you looked in the logfile?
    >>
    >> >persist
    >> >maxfail 0

    >>
    >> >-----------------

    >>
    >> >Conents of my options.pptp

    >>
    >> >lock
    >> >noauth

    >>
    >> This makes no sense whatsoever. YOu say in the main that you want them to
    >> use mschap and then you say noauth.
    >>
    >> >refuse-eap
    >> >refuse-chap
    >> >refuse-mschap
    >> >nobsdcomp
    >> >nodeflate
    >> >require-mppe-128

    >>
    >> Why?
    >>
    >> >lcp-echo-interval 5
    >> >lcp-echo-failure 5
    >> >maxfail 0
    >> >mtu 1396

    >>
    >> >-----------------

    >>
    >> >Contents of my options.pptpd

    >>
    >> >name pptpd
    >> >refuse-pap
    >> >refuse-chap
    >> >refuse-mschap
    >> >require-mschap-v2
    >> >require-mppe-128
    >> >ms-dns 172.31.254.32
    >> >lock
    >> >nobsdcomp
    >> >novj
    >> >novjccomp
    >> >nologfd
    >> >lcp-echo-interval 5
    >> >lcp-echo-failure 5
    >> >maxfail 0
    >> >mtu 1396

    >>
    >> >--------------------

    >>
    >> >Contents of /etc/pptpd.conf

    >>
    >> >option /etc/ppp/options.pptpd
    >> >logwtmp
    >> >localip 172.31.215.1-100
    >> >remoteip 172.31.215.1-100



  7. Re: ppp tunnel fails under load

    "Michelle" writes:

    >Based on posts from some of the more technical folks, it appeared to be
    >a compression algorythm error. Using noccp (disabling compression) the
    >crashing has stopped.


    >Does anyone have experience on how to force other compression
    >algorythms from default?


    Why do you want compression? Linux and windows do not happily share
    compression anyway.


    >As for authentication, is there a way to make the tunnel use a
    >different authentication mechanism (perhaps Linux's built in accounts)
    >- while leaving mschapv2 for other callers?


    It will use whatever the other has if you let it. They will offer their own
    authentication and you can accept or decline it. It all depends on your
    chat/pap-secrets files.



    >Michelle wrote:
    >> Here are the answers:
    >>
    >> 1. I use mschap authentication to keep a single authentication
    >> mechanism for all clients (Windows clients or Linux peers).
    >>
    >> 2. I posted the log file contents in my original messages. It includes
    >> primarily the "Protocol-Reject for unsupported protocol"
    >>
    >> 3. The NOAUTH settings (as I understand it) indicates that the
    >> receiving peer does not need to authenticate back to the calling peer.
    >> The caller still uses MSCHAP to authenticate.
    >>
    >> 4. I don't understand the "why" question.
    >>
    >> Any ideas/suggestions about the original problem?
    >>
    >> MD
    >>
    >>
    >> Unruh wrote:
    >> > support@ocg.ca writes:
    >> >
    >> > >I have 2 linux boxes acting as firewalls (one at each office). I have
    >> > >now added pptp VPN tunnel capability using pppd and poptop. I can
    >> > >succesfully establish tunnels between the firewalls, and successfully
    >> > >route traffic over the tunnel.
    >> >
    >> > >This works great for low volume data transfer (mail/ssh) but as soon as
    >> > >the volume of data increases the tunnel crashes. Although both sites
    >> > >show the tunnel as running (ps ax | grep ppp), neither side can ping
    >> > >the other. After crashing, one side of the tunnel always shows this
    >> > >error in syslog (repeated many times):
    >> >
    >> > >pptp[6813]: OCGtunnel warn[decaps_greptp_gre.c:351]: Discarding GRE:
    >> > >7D 9274 0 40 20 E
    >> >
    >> > >and the pptp.log file then fills with errors like this:
    >> >
    >> > Ssomehow your system is dropping back into ppp negotiation.
    >> >
    >> >
    >> >
    >> > >Protocol-Reject for unsupported protocol 0x3f
    >> > ....
    >> >
    >> >
    >> > >I start the tunnel with "pppd call OCGTunnel". (See the file below)
    >> >
    >> > I have never used it so my comments will be far from authoritative.
    >> >
    >> >
    >> > >Strangely, if I use a windows client to create the PPTP connection (to
    >> > >either firewall), I can move high volume traffic without problem. The
    >> > >problem only exists when creating a tunnel between the two Linux
    >> > >firewalls. This seems to suggest a pppd problem...
    >> >
    >> > >The only way to restore the tunnel is to kill the process and restart.
    >> > >Can anyone offer insight as to what cause causing the tunnel to hangup?
    >> > > Even better, how to fix it??
    >> >
    >> > >Thanks,
    >> > >Michelle
    >> >
    >> > >-----------------
    >> >
    >> > >Contents of my call file (in /etc/ppp/peers/OCGTunnel):
    >> >
    >> > >pty "pptp server1.domain.com --nolaunchpppd --logstring OCGtunnel
    >> > >--loglevel 0"
    >> > >name domain\\username
    >> > >require-mschap-v2
    >> >
    >> > Why in the world are you using mschap for authentication between two Linux
    >> > systems. It is a horrible authentication.
    >> >
    >> > >file /etc/ppp/options.pptp
    >> > >ipparam OCGTunnelName
    >> > >logfile /var/log/pptp.log
    >> >
    >> > Have you looked in the logfile?
    >> >
    >> > >persist
    >> > >maxfail 0
    >> >
    >> > >-----------------
    >> >
    >> > >Conents of my options.pptp
    >> >
    >> > >lock
    >> > >noauth
    >> >
    >> > This makes no sense whatsoever. YOu say in the main that you want them to
    >> > use mschap and then you say noauth.
    >> >
    >> > >refuse-eap
    >> > >refuse-chap
    >> > >refuse-mschap
    >> > >nobsdcomp
    >> > >nodeflate
    >> > >require-mppe-128
    >> >
    >> > Why?
    >> >
    >> > >lcp-echo-interval 5
    >> > >lcp-echo-failure 5
    >> > >maxfail 0
    >> > >mtu 1396
    >> >
    >> > >-----------------
    >> >
    >> > >Contents of my options.pptpd
    >> >
    >> > >name pptpd
    >> > >refuse-pap
    >> > >refuse-chap
    >> > >refuse-mschap
    >> > >require-mschap-v2
    >> > >require-mppe-128
    >> > >ms-dns 172.31.254.32
    >> > >lock
    >> > >nobsdcomp
    >> > >novj
    >> > >novjccomp
    >> > >nologfd
    >> > >lcp-echo-interval 5
    >> > >lcp-echo-failure 5
    >> > >maxfail 0
    >> > >mtu 1396
    >> >
    >> > >--------------------
    >> >
    >> > >Contents of /etc/pptpd.conf
    >> >
    >> > >option /etc/ppp/options.pptpd
    >> > >logwtmp
    >> > >localip 172.31.215.1-100
    >> > >remoteip 172.31.215.1-100



+ Reply to Thread