>может ли Cisco быть pptp клиентом?
умеет, вот рецепт:
This question comes up from time to time and the usual answer is "no";
however, most versions of IOS >= 12.2 do support it if "service internal"
is enabled. You will notice that with "service internal" request-dialin
vpdn groups allow rotary-group and pool-member commands. Here is a
sample configuration for a PPTP client:
no ip gratuitous-arps ! recommended
initiate-to ip 126.96.36.199 ! target PPTP server address
mtu 1450 ! allows for mppe and one PPPoE layer just in case
ip address 188.8.131.52 255.255.255.252
ip pim dense-mode
dialer idle-timeout 0
dialer string 123 ! required, but value seems to be ignored
no cdp enable
ppp pfc local request
ppp pfc remote apply
ppp encrypt mppe auto
ppp chap hostname vpnuser
ppp chap password 0 vpnpassword
dialer-list 1 protocol ip permit
-Pim is there merely to provide a source of activity to force the dialer
to connect without requiring you to point any routes at the interface.
This is useful since dialer interfaces are always "up" in some sense and
you can achieve better control of fallbacks by routing to the specific
/32 that will be installed when ipcp is up.
-Mppe requires (well, at least if you don't want to involve authentication
servers) that a version of MSCHAP be used to authenticate the ppp connection.
Cisco has supported MSCHAPv1 for a while, but v2 support is somewhat newer.
Either is fine as far as mppe is concerned, but you can get into situations
where no MSCHAP is used even though both ends support a common version. For
example, the if the server proposes the use of MSCHAPv2 and the Cisco does
not support v2 it will NAK to normal CHAP. If the server agrees then the
connection will come up but there will be no encryption. I think you will
be fine with IOS 12.4, but for others this can be a problem that requires
-Many PPTP servers expect to assign the client's IP address. Modify the
dialer's "ip address" statement for negotiated operation if necessary.
-Many PPTP servers use their primary address (i.e., the address that
you might use in the vpdn-group's "initiate-to ip" command) for their end
of the ppp connection. This is a problem because IOS will install a /32
route to that address through the dialer interface thus creating a loop
that chokes the connection (and possibly even crashes the router). If
you can't find an alternate address for the server you will need to use
policy routing to work around the problem as it appears that nothing can
compete with a /32 "directly" connected interface route.