Good day,

I have a pretty much standard home/office setup with "default" route
via local gateway machine (192.168.0.10) and I want to establish a PPTP
tunnel to a remote network.


pppd setup is pretty trivial.
peer:

  pty "pptp <pptp server hostname> --nolaunchpppd"
  user <user>
  password <password>
  file /etc/ppp/options.pptp
  ipparam network_x

options.pptp:

  noauth
  lock
  
  refuse-pap
  refuse-chap
  refuse-mschap
  require-mppe
  
  asyncmap 0x0
  
  mru 1400
  mtu 1400
  
  nodefaultroute
  noipdefault


Authentication works fine:

  using channel 33
  Using interface ppp0
  Connect: ppp0 <--> /dev/pts/16
  sh: /bin/ip: No such file or directory
  sh: /bin/ip: No such file or directory
  sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x296aa977> <pcomp> <accomp>]
  rcvd [LCP ConfReq id=0x1 <asyncmap 0x0> <auth chap MS-v2> <magic 0x6cb4d92f> 
<pcomp> <accomp>]
  sent [LCP ConfAck id=0x1 <asyncmap 0x0> <auth chap MS-v2> <magic 0x6cb4d92f> 
<pcomp> <accomp>]
  rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0x296aa977> <pcomp> <accomp>]
  rcvd [LCP EchoReq id=0x0 magic=0x6cb4d92f]
  sent [LCP EchoRep id=0x0 magic=0x296aa977]
  rcvd [CHAP Challenge id=0x6 <...>, name = "pptpd"]
  sent [CHAP Response id=0x6 <...>, name = "<user>"]
  rcvd [CHAP Success id=0x6 "S=..."]
  CHAP authentication succeeded
  sent [CCP ConfReq id=0x1 <mppe +H -M +S +L -D -C>]
  rcvd [CCP ConfReq id=0x1 <mppe +H -M +S -L -D -C>]
  sent [CCP ConfAck id=0x1 <mppe +H -M +S -L -D -C>]
  rcvd [CCP ConfNak id=0x1 <mppe +H -M +S -L -D -C>]
  sent [CCP ConfReq id=0x2 <mppe +H -M +S -L -D -C>]
  rcvd [CCP ConfAck id=0x2 <mppe +H -M +S -L -D -C>]
  MPPE 128-bit stateless compression enabled
  sent [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 0.0.0.0>]
  rcvd [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr __pptp_server_ip__>]
  sent [IPCP ConfAck id=0x1 <compress VJ 0f 01> <addr __pptp_server_ip__>]
  rcvd [IPCP ConfNak id=0x1 <addr __given_ip__>]
  sent [IPCP ConfReq id=0x2 <compress VJ 0f 01> <addr __given_ip__>]
  rcvd [IPCP ConfAck id=0x2 <compress VJ 0f 01> <addr __given_ip__>]
  local  IP address __given_ip__
  remote IP address __pptp_server_ip__
  Script /etc/ppp/ip-up started (pid 3138)
  Script /etc/ppp/ip-up finished (pid 3138), status = 0x0


But then, as usual, pppd messes up the routing table, adding the following 
route:

  __pptp_server_ip__ dev ppp0  proto kernel  scope link  src __given_ip__

resulting in routing table like this:

  __pptp_server_ip__ dev ppp0  proto kernel  scope link  src __given_ip__
  192.168.0.0/28 dev ath0  proto kernel  scope link  src 192.168.0.11
  127.0.0.0/8 via 127.0.0.1 dev lo
  default via 192.168.0.10 dev ath0

...and ppp0 falls off in two minutes, because of inability to access
__pptp_server_ip__.


Naturally, all packets to __pptp_server_ip__ should go through
192.168.0.10 gateway, so I've always managed to work around this
problem (with ISPs) by adding a route like this:

  __pptp_server_ip__ via 192.168.0.10 dev ath0

And it was used instead of the one, added by pppd.


Now, the situation got a bit more complicated, because
__pptp_server_ip__ is actually dynamic - there are several dozens of
them, given by DNS on round-robin basis, so it seems quite irrational
and hacky to add all of them to routing table. Always using just one of
them doesn't seem to be a clean solution, as well.

Likewise, if-up script to clean up the messy route looks like a hack,
especially because connection will be messed up it won't be fast enough
- 1 second delay in removing this route results in tons of 'Protocol
Rejected' errors (my guess is that ppp connection gets desynchronised),
which can only be fixed by reconnection.

So, the question: can I tell pppd/kernel not to add this route somehow?
I bet there should be some option, but I'm unable to find it in man
page or google.
Prehaps I can ban pppd from adding _any_ routes somehow?


Sorry for such a long post, just wanted to make the problem as clear as
possible. Thanks.

-- 
Mike Kazantsev // fraggod.net

Attachment: signature.asc
Description: PGP signature

Reply via email to