Thursday, September 11, 2008

Configuring a Cisco Adsl router acting as PPTP CLIENT

At work we have a PPTP Access Server for remote dial-in users.
Why PPTP? Because it's very easy to configure for users, and don't require any software installation on win Pcs....

Well at home for me it's a bit annoying to bring up the pptp connection every time I need and set-up static routes on my pc... so I realized that my poor outdated Cisco 827 maybe can act as PPTP client.

First I tryed to find how configure it, but CLIENT configuration for PPTP is unusual, I only have found this document: http://groups.google.com/group/comp.dcom.sys.cisco/msg/81d58c31469d558b
and a page with mppe on Cisco site (it was a "new feature" on IOS 12.0):
http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120limit/120xe/120xe5c/pptp.htm

well, tryed and it works, so I adapted to my requirements:
  • use the normal ADSL as default route
  • use PPTP only to reach specified private/public networks of my workplace


The final and explained config is HERE [+/-]



!
service internal !---> necessary to enable VPDN to allow a request-dialin group to be part of a rotary group or dialer pool.

!
no ip gratuitous-arps !---> recommended
!
vpdn enable
!
vpdn-group 2
request-dialin
protocol pptp !--> recent Ioses doesn't have pptp support... try "protocol ? " too see..
rotary-group 2 !---> Lol! we're now members of Rotay Club? ;-)) no! is the dialer-group specification for vpdn..
initiate-to ip A.B.C.D !---> A.B.C.D is the ip of my pptp Access Server
!
!
interface ATM0
no ip address
no ip mroute-cache
atm ilmi-keepalive
bundle-enable
dsl operating-mode auto
hold-queue 224 in
pvc 8/35
encapsulation aal5mux ppp dialer
dialer pool-member 1
!
!
interface Dialer0
description ADSL-side Dialer
ip address negotiated
ip access-group 101 in
ip mtu 1492
ip nat outside
ip inspect autosec_inspect out
encapsulation ppp
ip tcp adjust-mss 542
dialer pool 1
no cdp enable
ppp chap hostname yourhostname
ppp chap password yourpassword
!
interface Dialer2 !---> why dialer2 and not 1 ... don't know this time I like #2 ;-)
description PPTP-side Dialer
ip address negotiated
ip access-group 102 in
ip nat outside
encapsulation ppp
dialer in-band
dialer idle-timeout 0 !---> PPTP is slow to negotiate and start, so better an infinite timeout... (this doesn't affect negotiation time, but forces the dialer interface after connection to stay "always up" regardless of interesting traffic)
dialer string 123 !---> seems to be ignored so.. senseless string
dialer vpdn
dialer-group 2 !---> Remember Rotary? see dialer-list 2 below
no cdp enable
ppp pfc local forbid !---> do not perform compression locally
ppp pfc remote reject !---> reject remote compression proposals
ppp encrypt mppe auto !---> mppe = Micro$oft Point-to-Point Encryption (128bit max) You MUST have a "k9" IOS image to perform encryption, as usual
ppp chap hostname your-pptp-username !---> use username@domain if your pptp server is a Micro$oft Isa server, Alex Pronin has experienced that domain\username isn't understood
ppp chap password your-pptp-password
!
ip nat inside source list 111 interface Dialer0 overload !---> NAT for ADSL-exit
ip nat inside source list 110 interface Dialer2 overload !---> NAT for PPTP-exit, you will share your pptp-assigned ip inside your private lan
!
ip classless !---> recommended if you will apply static routes correctly
ip route 0.0.0.0 0.0.0.0 Dialer0 !---> Default route to ADSL
ip route 172.16.0.0 255.255.0.0 Dialer2 !---> some private routes to PPTP
ip route 172.17.0.0 255.255.0.0 Dialer2
ip route 172.18.0.0 255.255.0.0 Dialer2
ip route 192.168.206.0 255.255.255.0 Dialer2
ip route 192.168.236.0 255.255.255.0 Dialer2
ip route A.B.C.0 255.255.255.0 Dialer2 !---> if you want to route the public class of pptp access server though the pptp (un)secure connection,
ip route A.B.C.D 255.255.255.255 Dialer0 !---> you must route the access server out to ADSL, and the full public class through pptp (LONGEST BIT MATCH will do the rest ;-)
!
!
access-list 101 permit !---> Place your ADSL-side permit Here
access-list 101 deny ip any any
!
access-list 102 permit !---> Place your PPTP-side permit Here
access-list 102 deny ip any any
!
!---> Acl101: used for PPTP NAT
access-list 110 deny ip any host A.B.C.D !----> no nat for your Access Server (maybe unnecessary)
access-list 110 permit ip any A.B.C.0 0.0.0.255 !----> NAT for the rest of Access Server C Class
access-list 110 permit ip any 192.168.206.0 0.0.0.255 !----> NAT for the statically routed classes thorugh pptp tunnel
access-list 110 permit ip any 192.168.236.0 0.0.0.255
access-list 110 permit ip any 172.16.0.0 0.0.255.255
access-list 110 permit ip any 172.17.0.0 0.0.255.255
access-list 110 permit ip any 172.18.0.0 0.0.255.255
access-list 110 deny ip any any
!
!---> Acl111: used for ADSL NAT
access-list 111 permit ip any host A.B.C.D !----> NAT for your Access Server
access-list 111 deny ip any A.B.C.0 0.0.0.255 !----> no NAT for the rest of Access Server C Class
access-list 111 deny ip any 192.168.206.0 0.0.0.255 !----> NAT for the statically routed private classes
access-list 111 deny ip any 192.168.236.0 0.0.0.255
access-list 111 deny ip any 172.16.0.0 0.0.255.255
access-list 111 deny ip any 172.17.0.0 0.0.255.255
access-list 111 deny ip any 172.18.0.0 0.0.255.255
access-list 111 permit ip any

dialer-list 2 protocol ip permit !<---- used to initiate the pptp tunnel, permit all traffic, the acl110 will permit/block in more depth


Note that the interface dialer2, when up, is in "spoofing" state:

Majico#sh int dialer 2
Dialer2 is up (spoofing), line protocol is up (spoofing)
Hardware is Unknown
Internet address is 10.31.206.10/32
MTU 1500 bytes, BW 56 Kbit, DLY 20000 usec,
reliability 255/255, txload 4/255, rxload 40/255
Encapsulation PPP, loopback not set
Keepalive set (10 sec)
....
here "spoofing" means "listening" for interesting traffic, defined with the dialer-list 2 .
Some useful commands to monitor vpdn status are:
Majico#sh vpdn

%No active L2TP tunnels

%No active L2F tunnels

PPTP Tunnel and Session Information Total tunnels 1 sessions 1

LocID Remote Name State Remote Address Port Sessions VPDN Group
4 A.B.C.D estabd A.B.C.D 1723 1 2

LocID RemID TunID Intf Username State Last Chg Uniq ID
4 22144 4 Vi3 estabd 05:52:17 n/a

here we see the Virtual-Access interface assigned to pptp dialer, and
Majico#sh ppp mppe virtual-Access 3
Interface Virtual-Access3 (current connection)
Software encryption, 128 bit encryption, Stateless mode
packets encrypted = 17155 packets decrypted = 22828
sent CCP resets = 0 receive CCP resets = 0
next tx coherency = 771 next rx coherency = 2348
tx key changes = 17155 rx key changes = 22828
rx pkt dropped = 0 rx out of order pkt= 0
rx missed packets = 0

to see encryption statistics and type of encryption performed by mppe (we have configured "auto" negotiation, remember?)

Thanks to Dan Lanciani for configuration review!

10 comments:

alex-pronin said...

Hello, thanks you for this useful article.
I new in cisco ios world, so I need some help if it possible.
I have cisco 1721 router, running C1700-ADVENTERPRISEK9-M), Version 12.4(23) & Miscrosoft Isa Server in other end. Isa acting as pptp server with ms-chap-v2 authentication. Cisco 1721 should be pptp client.

Config is very closer for you.
But in your expamle you use chap authenticatiaon, but I need ms-chap-v2.
Can you help me?

Alex Pronin
ap@shandesign.ru

Marco Rizzi said...

hi Alex,
I'm not so expert with the various aaa methods, but in fact I've noticed that if your server requests an ms-chap-v2 authentication, the dialer will use username and password configured for chap:

home#debug ppp authentication
PPP authentication debugging is on
home#conf t
Enter configuration commands, one per line. End with CNTL/Z.
home(config)#int dial 2
home(config-if)#shutdown
home(config-if)#no shutdown
home(config-if)#end
home#
03:25:59: %LINK-3-UPDOWN: Interface Dialer2, changed state to up
03:26:19: %LINK-3-UPDOWN: Interface Virtual-Access3, changed state to up
03:26:19: Vi3 PPP: Using dialer call direction
03:26:19: Vi3 PPP: Treating connection as a callout
03:26:19: Vi3 PPP: Session handle[84000060] Session id[48]
03:26:19: Vi3 PPP: Authorization NOT required
03:26:19: Vi3 PPP: No remote authentication for call-out
03:26:22: Vi3 MS-CHAP-V2: I CHALLENGE id 183 len 27 from "server"
03:26:22: Vi3 MS CHAP V2: Using hostname from interface CHAP
03:26:22: Vi3 MS CHAP V2: Using password from interface CHAP
03:26:22: Vi3 MS-CHAP-V2: O RESPONSE id 183 len 66 from "myusername"
03:26:23: Vi3 MS-CHAP-V2: I SUCCESS id 183 len 46 msg is "S=12345678901234567890098765432109876543217"
03:26:23: Vi3 MS CHAP V2 No Password found for : server
03:26:23: Vi3 MS CHAP V2 No Password found for : server
03:26:23: Vi3 MS CHAP V2 Check AuthenticatorResponse Success for : myusername
03:26:24: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access3, changed state to up
casa#

So seems to be the right config for your requirements.
Marco

netnewswire said...

Hi Marco,

I have finally got the tunnel up and working, but when I ping from my laptop to an ip address that gets redirected to the vpn dialer, i get 100% packet lose. when I ping the same address from the cisco it is working flawlessly. Do I have a problem with the acl then?

Marco Rizzi said...

Hi, thanks for trying it ;-)
if you ping it from the router and it works, routing seems ok (check with sh ip route and/or traceroute).
So check the acls, you must have the correct entry in the NAT acl and in the eventually firewalling acl if present.
show ip nat translations is also an useful command to view if nat is working correctly.

Marco

netnewswire said...

Hi Marco,

I have checked the output of show ip nat translations | include 212.19.62.76 after I tried a ping from my laptop. Here is the output:
icmp 216.168.1.230:49925 192.168.1.26:49925 212.19.62.76:49925 212.19.62.76:49925
I get this output when I ping directly from the cisco router:
icmp 216.168.1.230:11 216.168.1.230:11 212.19.62.76:11 212.19.62.76:11

This is my VPN Dialer:
interface Dialer2
description PPTP-side Dialer
ip address negotiated
ip access-group 105 in
ip nat outside
ip virtual-reassembly
encapsulation ppp
dialer in-band
dialer idle-timeout 0
dialer string 123
dialer vpdn
dialer-group 2
no cdp enable
ppp pfc local forbid
ppp pfc remote reject
ppp encrypt mppe auto
ppp chap hostname removed
ppp chap password removed

This is the static routing tabel:
ip route 0.0.0.0 0.0.0.0 Dialer1 permanent
ip route 212.19.62.0 255.255.255.0 Dialer2
ip route 216.168.2.0 255.255.255.0 Dialer2
ip route 216.168.2.17 255.255.255.255 Dialer1

Dialer1 is for the ADSL connection. Here is the source list:
ip nat inside source list 109 interface Dialer2 overload
ip nat inside source list 110 interface Dialer1 overload

And the ACL´s:
access-list 105 permit ip any any
access-list 109 deny ip any host 216.168.2.17
access-list 109 permit ip any 216.168.2.0 0.0.0.255
access-list 109 permit ip any 212.19.62.0 0.0.0.255
access-list 109 deny ip any any
access-list 110 permit ip any host 216.168.2.17
access-list 110 deny ip any 216.168.2.0 0.0.0.255
access-list 110 deny ip any 212.19.62.0 0.0.0.255
access-list 110 permit ip any any
dialer-list 1 protocol ip permit
dialer-list 2 protocol ip permit

Here is the output of the sh ip route command:
Gateway of last resort is 0.0.0.0 to network 0.0.0.0

S 212.19.62.0/24 is directly connected, Dialer2
216.168.2.0/24 is variably subnetted, 2 subnets, 2 masks
S 216.168.2.17/32 is directly connected, Dialer1
S 216.168.2.0/24 is directly connected, Dialer2
77.0.0.0/32 is subnetted, 1 subnets
C 77.220.110.79 is directly connected, Dialer1
C 192.168.5.0/24 is directly connected, Vlan5
C 192.168.1.0/24 is directly connected, Vlan1
195.16.255.0/32 is subnetted, 1 subnets
C (my_public_IP) is directly connected, Dialer1
S* 0.0.0.0/0 is directly connected, Dialer1

Is there a possibility to check if an ACL is blocking the request?

Thanks and best regards
Edi

Marco Rizzi said...

Hi Edi,

I haven't found anything strange nor wrong with your config and the sh ip nat translations output seems to show a correct nat.

the routing table seems correct too...

If you ping from the router, and not from the laptop mmm strange one!
It can be a nat/acl problem, but they looks fine ;-(

To answer your question: "Is there a possibility to check if an ACL is blocking the request?"
Yes, just add the "log" word at the end of the acl statement and you will show every single match logged. (be shure to have terminal monitor actived if you are connected on vty or logging console if you are connected con con 0 )


hope this helps, let us know when you solve
Marco

Camilo Issufo Amarcy said...

Hi there,

First of all: thanks for the article.

But I'm still facing some issues.

Could you provide the show run of this router (can hide your private information).

Just would like to know all the steps for PPTP

Marco Rizzi said...

Hi Camilo,
thanks for looking at this post, unfortunately I don't have the original config anymore, I did this post long time ago...

Marco

Carles said...

It does not work with UC520. Feature capped from the IOS code.

Marco Rizzi said...

Charles, indeed, don't think Cisco or anyone else would support PPTP nowadays :-)