[gentoo-user] Problem with pppd-added routes

[gentoo-user] Problem with pppd-added routes

[Mike Kazantsev]

[-- Attachment #1: Type: text/plain, Size: 4152 bytes --]

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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Problem with pppd-added routes

[Keith Dart]

=== On Mon, 08/17, Mike Kazantsev wrote: ===
> 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__

That's not messed up, that's what it's supposed to do.

> 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

The __pptp_server_ip__ (you don't say what it is) should be the inner,
or tunneled IP address to the server's tunneled interface.

> ...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:

No they shouldn't, because it probably isn't routable. It may be
that your local IP network and the remote tunneled IP network are the
same. That would cause you problems.  If your connection is dropping
then it may be that your destination is behind a firewall. It's hard to
tell exactly what is going on with the limited information here. 

> 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?

That's not the problem to solve. The most common problem is setting up
routes to the tunneled destination. You probably need to add some
static routes to the remote networks. You can do this by adding a shell
script to /etc/ppp/ip-up.d directory:

# cat 70-routes.sh 
#!/bin/sh

# Used parameters and environment variables:
# $1 - interface name
# $6 - ipparam name

case $6 in
        ipparamvalue)
                ip route add 10.0.0.0/8 dev $1;;
esac



-- Keith Dart

-- 

-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   Keith Dart <keith@dartworks.biz>
   public key: ID: 19017044
   <http://www.dartworks.biz/>
   =====================================================================

Re: [gentoo-user] Problem with pppd-added routes

[Mike Kazantsev]

[-- Attachment #1: Type: text/plain, Size: 5449 bytes --]

On Mon, 17 Aug 2009 02:37:42 -0700
Keith Dart <keith@dartworks.biz> wrote:

> === On Mon, 08/17, Mike Kazantsev wrote: ===
> > 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__
> 
> That's not messed up, that's what it's supposed to do.

Guess it's just because all the gateways I've connected to lead to the
outside world, not the inner network with local IPs, so "inner" and
"outer" IPs there are the same (yes, both networks are actually the same
"outside world", see below).


> > 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
> 
> The __pptp_server_ip__ (you don't say what it is) should be the inner,
> or tunneled IP address to the server's tunneled interface.
> 
> > ...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:
> 
> No they shouldn't, because it probably isn't routable. It may be
> that your local IP network and the remote tunneled IP network are the
> same. That would cause you problems.  If your connection is dropping
> then it may be that your destination is behind a firewall. It's hard
> to tell exactly what is going on with the limited information here. 

Hm, the "inner" word clears it up, thanks for the tip.

Indeed, the networks, routed by local and pptp gateway do overlap,
because they both lead to the outside internet (although both are a bit
restricted subset of it).
So the should-be-inner IP (__pptp_server_ip__) is just identical to
the outer one.

I wonder if it does matter whether the remote gateway is closed to a
__given_ip__ - connection was established from first gw's outer IP
anyway, so the route to it is indeed severed: to send a packet to ppp0
gw, I need to use ppp0 and to use ppp0 I need to send that packet to
ppp0 gw ;)

Okay, I'll try to be more specific, although your guess about networks'
layout seem to be correct anyway.
Note that the host 87.224.197.1 should be accessible via both gateways.


tests (1):

  # ping -c 1 87.224.197.1
  PING 87.224.197.1 (87.224.197.1) 56(84) bytes of data. 64 bytes from
  87.224.197.1: icmp_seq=1 ttl=57 time=4.67 ms

  # ping -c 1 93.182.147.2
  PING 93.182.147.2 (93.182.147.2) 56(84) bytes of data. 64 bytes from
  93.182.147.2: icmp_seq=1 ttl=51 time=107 ms

"ip ro" before "pon":

  192.168.0.0/28 dev ath0  proto kernel  scope link  src 192.168.0.13
  127.0.0.0/8 via 127.0.0.1 dev lo
  default via 192.168.0.10 dev ath0

"pon":

  ...
  rcvd [IPCP ConfAck id=0x2 <compress VJ 0f 01> <addr 93.182.147.27>]
  local  IP address 93.182.147.27
  remote IP address 93.182.147.2
  Script /etc/ppp/ip-up started (pid 5048)
  Script /etc/ppp/ip-up finished (pid 5048), status = 0x0

"ip ro" now:

  93.182.147.2 dev ppp0  proto kernel  scope link  src 93.182.147.27
  192.168.0.0/28 dev ath0  proto kernel  scope link  src 192.168.0.13
  127.0.0.0/8 via 127.0.0.1 dev lo
  default via 192.168.0.10 dev ath0

tests (2):

  # ip ro add 87.224.197.1 dev ppp0

  # ping 87.224.197.1
  PING 87.224.197.1 (87.224.197.1) 56(84) bytes of data. ^C
  --- 87.224.197.1 ping statistics ---
  7 packets transmitted, 0 received, 100% packet loss, time 7000ms

  # ping 93.182.147.2
  PING 93.182.147.2 (93.182.147.2) 56(84) bytes of data. ^C
  --- 93.182.147.2 ping statistics ---
  3 packets transmitted, 0 received, 100% packet loss, time 3000ms

2 minutes later ("pon" output):

  Modem hangup
  Connect time 2.0 minutes.
  Sent 1847283226 bytes, received 0 bytes.
  Script /etc/ppp/ip-down started (pid 5169)
  MPPE disabled
  sent [LCP TermReq id=0x2 "MPPE disabled"]
  Connection terminated.
  Script pptp 93.182.147.2 --nolaunchpppd finished (pid 5042), status = 0x0
  Script /etc/ppp/ip-down finished (pid 5169), status = 0x0

ppp0 is destroyed along with it's routes and both pings work again via
192.168.0.10 gw, while I wanted to access 87.224.197.1 via the tunnel.

If I'll add "ip ro del 93.182.147.2 dev ppp0" quickly enough to "test
(2)" block, both pings will work - packets to 93.182.147.2 will be
routed via 192.168.0.10 and to 87.224.197.1 via 93.182.147.2.


And so the question stays the same:

> > 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?

Not a chance? :(


> That's not the problem to solve. The most common problem is setting up
> routes to the tunneled destination. You probably need to add some
> static routes to the remote networks. You can do this by adding a
> shell script to /etc/ppp/ip-up.d directory:

Yes, there's that, but it seem to be the easiest part, since I know
exactly which hosts should be accessed via tunnel - just a bunch of "ip
route" commands to ifup. No problem here.


-- 
Mike Kazantsev // fraggod.net

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Problem with pppd-added routes

[Walter Dnes]

  I have things set up to allow me to connect to dialup, and still keep
connections going to my other machine ("LAN" = 2 machines).  I think this
is similar to your situation.  The key is in my /etc/conf.d/net file as
per the following excerpt...


routes_eth0=(
"default via 192.168.123.254 metric 2 mss 1454"
"192.168.123.248/29 via 192.168.123.254 metric 0"
)

  My home machine is 192.168.123.250 on my "LAN", my hot-backup is
192.168.123.251, and the ADSL-modem-cum-router is 192.168.123.254.  Note
the 2 statements.  The default connection to the world is "metric 2",
while the connection to the LAN is given "metric 0".  The ppp0
connection, when active, has priority over the default connection, but
not over the LAN connection.  So I don't have to tear down the eth0
connection when dialing up, and re-start it after disconnecting from
dialup.

  If I wanted to get really fancy, I could assign separate "metric 0"
routes for streaming video or audio sites, where dialup won't hack it.
This would allow me to listen to internet radio on ADSL, while
simultaneously downloading updates/email/usenet over dialup, or even
surfing the web on dialup.

  Why bother, you ask?  Bell Canada will soon be be ramming
billing-by-the-byte on all its users and its resellers' users.  The only
"alternative" in Toronto is Rogers Cable, and they're not attractive
either.  I intend to divert update/email/usenet downloads to dialup.
This will apply to any files where I don't care if it's an overnight
download.

  This would also be a great idea for usability testing for some web
developers, to see how piggy their Schlockwave-Trash websites are on
dialup.

-- 
Walter Dnes <waltdnes@waltdnes.org>

Re: [gentoo-user] Problem with pppd-added routes

[Mike Kazantsev]

[-- Attachment #1: Type: text/plain, Size: 1406 bytes --]

On Tue, 18 Aug 2009 07:55:13 -0400
"Walter Dnes" <waltdnes@waltdnes.org> wrote:

>   I have things set up to allow me to connect to dialup, and still keep
> connections going to my other machine ("LAN" = 2 machines).  I think this
> is similar to your situation.  The key is in my /etc/conf.d/net file as
> per the following excerpt...
> 
> 
> routes_eth0=(
> "default via 192.168.123.254 metric 2 mss 1454"
> "192.168.123.248/29 via 192.168.123.254 metric 0"
> )
> 
>   My home machine is 192.168.123.250 on my "LAN", my hot-backup is
> 192.168.123.251, and the ADSL-modem-cum-router is 192.168.123.254.  Note
> the 2 statements.  The default connection to the world is "metric 2",
> while the connection to the LAN is given "metric 0".  The ppp0
> connection, when active, has priority over the default connection, but
> not over the LAN connection.  So I don't have to tear down the eth0
> connection when dialing up, and re-start it after disconnecting from
> dialup.

Thanks for the solution.

Guess I'll settle for similar scheme for now, adding all the gateway IPs
to the routing table via preup() function, parsing output of dig with
awk.

Still, overriding garbage route like that is a hack and it should be
easy to write a patch for that behavior, when I'll have some spare time,
provided I won't forget about the issue... ;)

-- 
Mike Kazantsev // fraggod.net

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]