1 |
Good day, |
2 |
|
3 |
I have a pretty much standard home/office setup with "default" route |
4 |
via local gateway machine (192.168.0.10) and I want to establish a PPTP |
5 |
tunnel to a remote network. |
6 |
|
7 |
|
8 |
pppd setup is pretty trivial. |
9 |
peer: |
10 |
|
11 |
pty "pptp <pptp server hostname> --nolaunchpppd" |
12 |
user <user> |
13 |
password <password> |
14 |
file /etc/ppp/options.pptp |
15 |
ipparam network_x |
16 |
|
17 |
options.pptp: |
18 |
|
19 |
noauth |
20 |
lock |
21 |
|
22 |
refuse-pap |
23 |
refuse-chap |
24 |
refuse-mschap |
25 |
require-mppe |
26 |
|
27 |
asyncmap 0x0 |
28 |
|
29 |
mru 1400 |
30 |
mtu 1400 |
31 |
|
32 |
nodefaultroute |
33 |
noipdefault |
34 |
|
35 |
|
36 |
Authentication works fine: |
37 |
|
38 |
using channel 33 |
39 |
Using interface ppp0 |
40 |
Connect: ppp0 <--> /dev/pts/16 |
41 |
sh: /bin/ip: No such file or directory |
42 |
sh: /bin/ip: No such file or directory |
43 |
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x296aa977> <pcomp> <accomp>] |
44 |
rcvd [LCP ConfReq id=0x1 <asyncmap 0x0> <auth chap MS-v2> <magic 0x6cb4d92f> <pcomp> <accomp>] |
45 |
sent [LCP ConfAck id=0x1 <asyncmap 0x0> <auth chap MS-v2> <magic 0x6cb4d92f> <pcomp> <accomp>] |
46 |
rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0x296aa977> <pcomp> <accomp>] |
47 |
rcvd [LCP EchoReq id=0x0 magic=0x6cb4d92f] |
48 |
sent [LCP EchoRep id=0x0 magic=0x296aa977] |
49 |
rcvd [CHAP Challenge id=0x6 <...>, name = "pptpd"] |
50 |
sent [CHAP Response id=0x6 <...>, name = "<user>"] |
51 |
rcvd [CHAP Success id=0x6 "S=..."] |
52 |
CHAP authentication succeeded |
53 |
sent [CCP ConfReq id=0x1 <mppe +H -M +S +L -D -C>] |
54 |
rcvd [CCP ConfReq id=0x1 <mppe +H -M +S -L -D -C>] |
55 |
sent [CCP ConfAck id=0x1 <mppe +H -M +S -L -D -C>] |
56 |
rcvd [CCP ConfNak id=0x1 <mppe +H -M +S -L -D -C>] |
57 |
sent [CCP ConfReq id=0x2 <mppe +H -M +S -L -D -C>] |
58 |
rcvd [CCP ConfAck id=0x2 <mppe +H -M +S -L -D -C>] |
59 |
MPPE 128-bit stateless compression enabled |
60 |
sent [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 0.0.0.0>] |
61 |
rcvd [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr __pptp_server_ip__>] |
62 |
sent [IPCP ConfAck id=0x1 <compress VJ 0f 01> <addr __pptp_server_ip__>] |
63 |
rcvd [IPCP ConfNak id=0x1 <addr __given_ip__>] |
64 |
sent [IPCP ConfReq id=0x2 <compress VJ 0f 01> <addr __given_ip__>] |
65 |
rcvd [IPCP ConfAck id=0x2 <compress VJ 0f 01> <addr __given_ip__>] |
66 |
local IP address __given_ip__ |
67 |
remote IP address __pptp_server_ip__ |
68 |
Script /etc/ppp/ip-up started (pid 3138) |
69 |
Script /etc/ppp/ip-up finished (pid 3138), status = 0x0 |
70 |
|
71 |
|
72 |
But then, as usual, pppd messes up the routing table, adding the following route: |
73 |
|
74 |
__pptp_server_ip__ dev ppp0 proto kernel scope link src __given_ip__ |
75 |
|
76 |
resulting in routing table like this: |
77 |
|
78 |
__pptp_server_ip__ dev ppp0 proto kernel scope link src __given_ip__ |
79 |
192.168.0.0/28 dev ath0 proto kernel scope link src 192.168.0.11 |
80 |
127.0.0.0/8 via 127.0.0.1 dev lo |
81 |
default via 192.168.0.10 dev ath0 |
82 |
|
83 |
...and ppp0 falls off in two minutes, because of inability to access |
84 |
__pptp_server_ip__. |
85 |
|
86 |
|
87 |
Naturally, all packets to __pptp_server_ip__ should go through |
88 |
192.168.0.10 gateway, so I've always managed to work around this |
89 |
problem (with ISPs) by adding a route like this: |
90 |
|
91 |
__pptp_server_ip__ via 192.168.0.10 dev ath0 |
92 |
|
93 |
And it was used instead of the one, added by pppd. |
94 |
|
95 |
|
96 |
Now, the situation got a bit more complicated, because |
97 |
__pptp_server_ip__ is actually dynamic - there are several dozens of |
98 |
them, given by DNS on round-robin basis, so it seems quite irrational |
99 |
and hacky to add all of them to routing table. Always using just one of |
100 |
them doesn't seem to be a clean solution, as well. |
101 |
|
102 |
Likewise, if-up script to clean up the messy route looks like a hack, |
103 |
especially because connection will be messed up it won't be fast enough |
104 |
- 1 second delay in removing this route results in tons of 'Protocol |
105 |
Rejected' errors (my guess is that ppp connection gets desynchronised), |
106 |
which can only be fixed by reconnection. |
107 |
|
108 |
So, the question: can I tell pppd/kernel not to add this route somehow? |
109 |
I bet there should be some option, but I'm unable to find it in man |
110 |
page or google. |
111 |
Prehaps I can ban pppd from adding _any_ routes somehow? |
112 |
|
113 |
|
114 |
Sorry for such a long post, just wanted to make the problem as clear as |
115 |
possible. Thanks. |
116 |
|
117 |
-- |
118 |
Mike Kazantsev // fraggod.net |