Cisco 1721 as PPTP Client

Discussion in 'Cisco' started by E. S., Nov 20, 2006.

  1. E. S.

    Dan Lanciani Guest

    | Same as before

    Possibly the route map isn't doing what I expected. You could try enabling
    debugging for it ("debug ip policy" I think). You could also try replacing the
    "set interface ATM0.35" in the route map with "set ip next-hop 89.186.68.5".
    I assumed that the interface version would work with a point-to-point pvc,
    but I've never tried this with ATM before...

    | have i to enable keepalives?

    I would turn them back on. In general, don't change more than one thing
    at a time.

    | and what about nat?

    I would disable NAT until you have the vpn working. At least get rid
    of the "ip nat outside" on the ATM.35 interface; I would worry that it
    is translating the encapsulted PPTP packets.

    Dan Lanciani
    [email protected]*com
     
    Dan Lanciani, Nov 29, 2006
    #21
    1. Advertisements

  2. E. S.

    Elia Spadoni Guest

    I tried putting next hop, but with no changes.

    Enabled. But I did not find any entries in the syslog regarding
    keepalives ::)

    okok :)
    Now this evening I experienced very fast disconnections.
    Nothing better happened.
    Do you have a msn contact so we could make some test online?
    Do you think that the problems seems related to policy routing?

    Please now copy from the last msg, the config of the router.

    We are almost there to the solution... :p The problems as you noticed
    could be related
    to policy routing but I tried to see on the cisco website about policy
    routing
    but I never experienced that on my works and I am not very "trained" on
    that.

    What could we do now?
     
    Elia Spadoni, Nov 29, 2006
    #22
    1. Advertisements

  3. E. S.

    Elia Spadoni Guest

    As you see, keepalives again

    here is the detail


    30-11-2006 00:52:24 Syslog.Debug 192.168.1.254 322325: 322266: Nov 30
    01:51:48.941 CET: Vi1 PPP: Queue CCP code[1] id[1]
    30-11-2006 00:52:24 Syslog.Debug 192.168.1.254 322326: 322267: Nov 30
    01:51:48.945 CET: Vi1 PPP SSS: Receive SSS-Mgr Connect-Local
    30-11-2006 00:52:24 Syslog.Debug 192.168.1.254 322327: 322268: Nov 30
    01:51:48.945 CET: Vi1 PPP: Phase is ESTABLISHING, Finish LCP
    30-11-2006 00:52:24 Syslog.Debug 192.168.1.254 322328: 322269: Nov 30
    01:51:48.949 CET: Vi1 PPP: Phase is UP
    30-11-2006 00:52:24 Syslog.Debug 192.168.1.254 322329: 322270: Nov 30
    01:51:48.949 CET: Vi1 IPCP: O CONFREQ [Closed] id 1 len 10
    30-11-2006 00:52:24 Syslog.Debug 192.168.1.254 322330: 322271: Nov 30
    01:51:48.949 CET: Vi1 IPCP: Address 0.0.0.0 (0x030600000000)
    30-11-2006 00:52:24 Syslog.Debug 192.168.1.254 322331: 322272: Nov 30
    01:51:48.949 CET: Vi1 CCP: O CONFREQ [Closed] id 1 len 10
    30-11-2006 00:52:24 Syslog.Debug 192.168.1.254 322332: 322273: Nov 30
    01:51:48.949 CET: Vi1 CCP: MS-PPC supported bits 0x01000060
    (0x120601000060)
    30-11-2006 00:52:24 Syslog.Debug 192.168.1.254 322333: 322274: Nov 30
    01:51:48.949 CET: Vi1 PPP: Process pending ncp packets
    30-11-2006 00:52:24 Syslog.Debug 192.168.1.254 322334: 322275: Nov 30
    01:51:48.953 CET: Vi1 CCP: Redirect packet to Vi1
    30-11-2006 00:52:24 Syslog.Debug 192.168.1.254 322335: 322276: Nov 30
    01:51:48.953 CET: Vi1 CCP: I CONFREQ [REQsent] id 1 len 10
    30-11-2006 00:52:24 Syslog.Debug 192.168.1.254 322336: 322277: Nov 30
    01:51:48.953 CET: Vi1 CCP: MS-PPC supported bits 0x01000040
    (0x120601000040)
    30-11-2006 00:52:24 Syslog.Debug 192.168.1.254 322337: 322278: Nov 30
    01:51:48.953 CET: Vi1 CCP: O CONFACK [REQsent] id 1 len 10
    30-11-2006 00:52:24 Syslog.Debug 192.168.1.254 322338: 322279: Nov 30
    01:51:48.953 CET: Vi1 CCP: MS-PPC supported bits 0x01000040
    (0x120601000040)
    30-11-2006 00:52:24 Syslog.Debug 192.168.1.254 322339: 322280: Nov 30
    01:51:49.009 CET: Vi1 IPCP: I TERMACK [REQsent] id 1 len 4
    30-11-2006 00:52:24 Syslog.Debug 192.168.1.254 322340: 322281: Nov 30
    01:51:49.013 CET: Vi1 CCP: I CONFNAK [ACKsent] id 1 len 10
    30-11-2006 00:52:24 Syslog.Debug 192.168.1.254 322341: 322282: Nov 30
    01:51:49.013 CET: Vi1 CCP: MS-PPC supported bits 0x01000040
    (0x120601000040)
    30-11-2006 00:52:24 Syslog.Debug 192.168.1.254 322342: 322283: Nov 30
    01:51:49.013 CET: Vi1 CCP: O CONFREQ [ACKsent] id 2 len 10
    30-11-2006 00:52:24 Syslog.Debug 192.168.1.254 322343: 322284: Nov 30
    01:51:49.013 CET: Vi1 CCP: MS-PPC supported bits 0x01000040
    (0x120601000040)
    30-11-2006 00:52:24 Syslog.Debug 192.168.1.254 322344: 322285: Nov 30
    01:51:49.073 CET: Vi1 CCP: I CONFACK [ACKsent] id 2 len 10
    30-11-2006 00:52:25 Syslog.Debug 192.168.1.254 322345: 322286: Nov 30
    01:51:49.073 CET: Vi1 CCP: MS-PPC supported bits 0x01000040
    (0x120601000040)
    30-11-2006 00:52:25 Syslog.Debug 192.168.1.254 322346: 322287: Nov 30
    01:51:49.073 CET: Vi1 CCP: State is Open
    30-11-2006 00:52:25 Syslog.Debug 192.168.1.254 322347: 322288: Nov 30
    01:51:49.081 CET: Vi1 IPCP: I CONFREQ [REQsent] id 1 len 10
    30-11-2006 00:52:25 Syslog.Debug 192.168.1.254 322348: 322289: Nov 30
    01:51:49.081 CET: Vi1 IPCP: Address 83.233.168.2 (0x030653E9A802)
    30-11-2006 00:52:25 Syslog.Debug 192.168.1.254 322349: 322290: Nov 30
    01:51:49.081 CET: Vi1 IPCP: O CONFACK [REQsent] id 1 len 10
    30-11-2006 00:52:25 Syslog.Debug 192.168.1.254 322350: 322291: Nov 30
    01:51:49.081 CET: Vi1 IPCP: Address 83.233.168.2 (0x030653E9A802)
    30-11-2006 00:52:26 Syslog.Notice 192.168.1.254 322351: 322292: Nov 30
    01:51:49.945 CET: %LINEPROTO-5-UPDOWN: Line protocol on Interface
    Virtual-Access1, changed state to up
    30-11-2006 00:52:26 Syslog.Debug 192.168.1.254 322352: 322293: Nov 30
    01:51:50.961 CET: Vi1 IPCP: Timeout: State ACKsent
    30-11-2006 00:52:26 Syslog.Debug 192.168.1.254 322353: 322294: Nov 30
    01:51:50.961 CET: Vi1 IPCP: O CONFREQ [ACKsent] id 2 len 10
    30-11-2006 00:52:26 Syslog.Debug 192.168.1.254 322354: 322295: Nov 30
    01:51:50.961 CET: Vi1 IPCP: Address 0.0.0.0 (0x030600000000)
    30-11-2006 00:52:26 Syslog.Debug 192.168.1.254 322355: 322296: Nov 30
    01:51:51.017 CET: Vi1 IPCP: I CONFNAK [ACKsent] id 2 len 10
    30-11-2006 00:52:26 Syslog.Debug 192.168.1.254 322356: 322297: Nov 30
    01:51:51.017 CET: Vi1 IPCP: Address 83.233.168.96 (0x030653E9A860)
    30-11-2006 00:52:26 Syslog.Debug 192.168.1.254 322357: 322298: Nov 30
    01:51:51.021 CET: Vi1 IPCP: O CONFREQ [ACKsent] id 3 len 10
    30-11-2006 00:52:26 Syslog.Debug 192.168.1.254 322358: 322299: Nov 30
    01:51:51.021 CET: Vi1 IPCP: Address 83.233.168.96 (0x030653E9A860)
    30-11-2006 00:52:26 Syslog.Debug 192.168.1.254 322359: 322300: Nov 30
    01:51:51.077 CET: Vi1 IPCP: I CONFACK [ACKsent] id 3 len 10
    30-11-2006 00:52:27 Syslog.Debug 192.168.1.254 322360: 322301: Nov 30
    01:51:51.077 CET: Vi1 IPCP: Address 83.233.168.96 (0x030653E9A860)
    30-11-2006 00:52:27 Syslog.Debug 192.168.1.254 322361: 322302: Nov 30
    01:51:51.077 CET: Vi1 IPCP: State is Open
    30-11-2006 00:52:27 Syslog.Debug 192.168.1.254 322362: 322303: Nov 30
    01:51:51.081 CET: Di0 IPCP: Install negotiated IP interface address
    83.233.168.96
    30-11-2006 00:52:27 Syslog.Debug 192.168.1.254 322363: 322304: Nov 30
    01:51:51.085 CET: Di0 IPCP: Install route to 83.233.168.2
    30-11-2006 00:52:27 Syslog.Debug 192.168.1.254 322364: 322305: Nov 30
    01:51:51.089 CET: Vi1 IPCP: Add link info for cef entry 83.233.168.2
    30-11-2006 00:53:26 Syslog.Debug 192.168.1.254 322365: 322306: Nov 30
    01:52:51.410 CET: Vi1 PPP: Missed 5 keepalives, taking LCP down
    30-11-2006 00:53:26 Syslog.Debug 192.168.1.254 322366: 322307: Nov 30
    01:52:51.410 CET: Vi1 PPP: Sending Acct Event[Down] id[88]
    30-11-2006 00:53:26 Syslog.Debug 192.168.1.254 322367: 322308: Nov 30
    01:52:51.410 CET: Vi1 LCP: State is Closed
    30-11-2006 00:53:26 Syslog.Debug 192.168.1.254 322368: 322309: Nov 30
    01:52:51.410 CET: Vi1 PPP: Phase is DOWN
    30-11-2006 00:53:26 Syslog.Debug 192.168.1.254 322369: 322310: Nov 30
    01:52:51.410 CET: Vi1 CCP: State is Closed
    30-11-2006 00:53:26 Syslog.Debug 192.168.1.254 322370: 322311: Nov 30
    01:52:51.414 CET: Vi1 IPCP: State is Closed
    30-11-2006 00:53:26 Syslog.Debug 192.168.1.254 322371: 322312: Nov 30
    01:52:51.414 CET: Vi1 IPCP: Remove link info for cef entry 83.233.168.2
    30-11-2006 00:53:26 Syslog.Debug 192.168.1.254 322372: 322313: Nov 30
    01:52:51.414 CET: Vi1 PPP SSS: Send DISCONNECT to mgr_hdl[DF00004B]
     
    Elia Spadoni, Nov 29, 2006
    #23
  4. E. S.

    Dan Lanciani Guest

    | Now this evening I experienced very fast disconnections.
    | Nothing better happened.
    | Do you have a msn contact so we could make some test online?

    No.

    | Do you think that the problems seems related to policy routing?

    The problem is the use of the contact address for the PPTP server's PPP
    address. I have been able to work around this with policy based routing
    in 12.2 and 12.3 as I described, but it's always possible that something
    has changed and this is no longer possible. As PPTP client operation is
    unsupported the only way you can find out is to turn on debugging for PBR
    and follow the packets. Unfortunately, I don't know any other solution,
    so if PBR no longer works in this case you may be out of luck (unless you
    can get the server to use different addresses for contact point and PPP link).

    Dan Lanciani
    [email protected]*com
     
    Dan Lanciani, Nov 30, 2006
    #24
  5. E. S.

    Elia Spadoni Guest

    88.233.168.2 is not an address you use for
    What do you mean with you dont have be routing through the vpn?
    I think I have to put dial0 ipnat outside
    and a nat entry that is like this:
    ip nat inside source list 102 interface Dialer0 overload



    Hello Dan, can you please explain me, or at least pointing me in a cisco
    doc or similar,
    to understand every command you gave me, to make further test?

    If the policy routing works, what have I to see on the logs?

    for example: what is the access list for?
    what means set int atm0.35 , in policy routing?

    ty
     
    Elia Spadoni, Dec 3, 2006
    #25
  6. E. S.

    Dan Lanciani Guest

    | > 88.233.168.2 is not an address you use for
    | > | > "initiate-to ip" in the vpdn definition, right?
    | > |
    | > |
    | > | initiate-to ip 83.233.168.2
    | >
    | . You must not be routing
    | > through the vpn at all.
    |
    | What do you mean with you dont have be routing through the vpn?

    Any packets sent into the vpn will disappear into a black hole because
    of the routing loop created by using the same address for the server's
    end of the PPP link and the initiate-to. That's what is killing the vpn
    by blocking the keepalives. Since your access to the internet was
    apparently working you must not have been sending packets out through the
    vpn.

    | I think I have to put dial0 ipnat outside
    | and a nat entry that is like this:
    | ip nat inside source list 102 interface Dialer0 overload

    But you aren't actually routing any packets to that interface as far
    as I can see.

    | Hello Dan, can you please explain me, or at least pointing me in a cisco
    | doc or similar,
    | to understand every command you gave me, to make further test?

    Cisco doesn't support client PPTP operation so there is no documentation
    that I am aware of; however, most of the commands are exactly the same as
    for any other PPP link. Policy routing commands are reasonably well
    documented. All you need them to do is force the encapsulated vpn traffic
    through the real ATM link rather than through the vpn itself, avoiding the
    loop.

    | If the policy routing works, what have I to see on the logs?

    PBR debugging is verbose; it can show you how each packet is matched
    against the route map. You should check that packets for the vpn
    server are matching and being forced through the ATM link.

    | for example: what is the access list for?

    It tells the PBR which packets to match.

    | what means set int atm0.35 , in policy routing?

    It tells the PBR where to send the packets matched by the above access list.

    Unfortunately, it seems that it is easier to debug these configurations
    than to describe how to debug them. :(

    Dan Lanciani
    [email protected]*com
     
    Dan Lanciani, Dec 3, 2006
    #26
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.