Client cant connect VIA PPTP (Poptop). HELP! - PPP

This is a discussion on Client cant connect VIA PPTP (Poptop). HELP! - PPP ; I have a client who can't connect to our PPTP server (Poptop). All other clients are having no problem. This one site however, is behind a CISCO firewall (no IPSEC). I've read about some of the issues with PPTP and ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Client cant connect VIA PPTP (Poptop). HELP!

  1. Client cant connect VIA PPTP (Poptop). HELP!

    I have a client who can't connect to our PPTP server (Poptop). All
    other clients are having no problem. This one site however, is behind
    a CISCO firewall (no IPSEC). I've read about some of the issues with
    PPTP and CISCO, but I have not foud a solution. Following is the log
    from poptop when the user trys to connect.

    CTRL: Client xxx.xxx.xxx.xxx control connection started
    CTRL: Starting call (launching pppd, opening GRE)
    pppd 2.4.2 started by root, uid 0
    using channel 229
    Using interface ppp2
    Connect: ppp2 <--> /dev/ttyp4
    sent [LCP ConfReq id=0x1
    ]
    GRE: read error: No route to host
    CTRL: PTY read or GRE write failed (pty,gre)=(5,6)
    Modem hangup
    Connection terminated.
    CTRL: Client xxx.xxx.xxx.xxx control connection finished
    Exit.

    Any ideas or thoughts as to whats going on would be apriciated.

  2. Re: Client cant connect VIA PPTP (Poptop). HELP!

    jfizer writes:
    > I have a client who can't connect to our PPTP server (Poptop). All
    > other clients are having no problem. This one site however, is behind
    > a CISCO firewall (no IPSEC).


    Is that firewall also a NAT (Network Address Translation) device?

    PPTP runs GRE over raw IP and, as such, isn't particularly friendly
    with NATs. You'd have to have a NAT that understands a lot of the
    details of PPTP in order to make that work.

    (See RFC 2637 for details on PPTP.)

    > sent [LCP ConfReq id=0x1
    > ]
    > GRE: read error: No route to host


    It sounds like the system is getting back ICMP errors from the router,
    though it's very hard to tell.

    You might want to use 'tcpdump' or 'ethereal' to look at the packets
    on the wire.

    --
    James Carlson, IP Systems Group
    Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677

+ Reply to Thread