View previous topic :: View next topic |
Author |
Message |
ylachance n00b
Joined: 16 Mar 2005 Posts: 15
|
Posted: Wed Mar 16, 2005 2:47 am Post subject: PPTP connects but ping fails |
|
|
I've been trying to create a successfull VPN connection but for some reason, the communication does not work.
The tunnel connection is successfull, the routing seems to be o.k. but I can't ping anything on the other side of the tunnel. Any idea ?? Here is the debug info, the routing table, ping tests inside and outside the tunnel.
Thanks
bash-2.05b# pon MS debug dump logfd 2 nodetach
pppd options in effect:
debug # (from command line)
nodetach # (from command line)
logfd 2 # (from command line)
linkname MS # (from /etc/ppp/peers/MS)
dump # (from command line)
noauth # (from /etc/ppp/options.pptp)
refuse-eap # (from /etc/ppp/peers/MS)
name company.com\\myusername # (from /etc/ppp/peers/MS)
remotename MS # (from /etc/ppp/peers/MS)
# (from /etc/ppp/options.pptp)
pty pptp 206.162.166.100 --nolaunchpppd # (from /etc/ppp/peers/MS)
ipparam MS # (from /etc/ppp/peers/MS)
usepeerdns # (from /etc/ppp/peers/MS)
nobsdcomp # (from /etc/ppp/options.pptp)
nodeflate # (from /etc/ppp/options.pptp)
using channel 1
Using interface ppp0
Connect: ppp0 <--> /dev/pts/3
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x42e587c9> <pcomp> <accomp>]
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x42e587c9> <pcomp> <accomp>]
rcvd [LCP ConfReq id=0x1 <mru 338> <auth chap MS-v2> <magic 0xa1152ef1> <pcomp> <accomp>]
sent [LCP ConfAck id=0x1 <mru 338> <auth chap MS-v2> <magic 0xa1152ef1> <pcomp> <accomp>]
rcvd [LCP ConfRej id=0x1 <asyncmap 0x0>]
sent [LCP ConfReq id=0x2 <magic 0x42e587c9> <pcomp> <accomp>]
rcvd [LCP ConfAck id=0x2 <magic 0x42e587c9> <pcomp> <accomp>]
rcvd [CHAP Challenge id=0x1 <bd081187441e1a4f1d156663780c28b0>, name = "watchguard"]
sent [CHAP Response id=0x1 <76047d7e54c2a23244c83e3708a154590000000000000000246f2bba4e11d6ef0b3c7691bbdf0b504acb3c324f269ea300>, name = "company.com\\username"]
rcvd [CHAP Success id=0x1 "S=EE881920EEB0EC4A5686854420967A2A64440B5E"]
sent [CCP ConfReq id=0x1 <mppe -H -M -S -L -D +C>]
sent [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
rcvd [IPCP ConfReq id=0x1 <addr 192.168.0.4>]
sent [IPCP ConfAck id=0x1 <addr 192.168.0.4>]
rcvd [CCP ConfReq id=0x1 <mppe +H -M +S -L -D -C>]
sent [CCP ConfNak 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 [IPCP ConfRej id=0x1 <compress VJ 0f 01>]
sent [IPCP ConfReq id=0x2 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
rcvd [CCP ConfReq id=0x2 <mppe -H -M +S -L -D -C>]
sent [CCP ConfAck 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
rcvd [IPCP ConfNak id=0x2 <addr 192.168.0.20> <ms-dns1 192.168.0.12> <ms-dns3 192.168.0.14>]
sent [IPCP ConfReq id=0x3 <addr 192.168.0.20> <ms-dns1 192.168.0.12> <ms-dns3 192.168.0.14>]
rcvd [IPCP ConfAck id=0x3 <addr 192.168.0.20> <ms-dns1 192.168.0.12> <ms-dns3 192.168.0.14>]
local IP address 192.168.0.20
remote IP address 192.168.0.4
primary DNS address 192.168.0.12
secondary DNS address 192.168.0.14
Script /etc/ppp/ip-up started (pid 5792)
Script /etc/ppp/ip-up finished (pid 5792), status = 0x1
eth1 Link encap:Ethernet HWaddr 00:0E:35:5C:42:3F
inet addr:192.168.123.124 Bcast:192.168.123.255 Mask:255.255.255.0
UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1
RX packets:464 errors:0 dropped:0 overruns:0 frame:0
TX packets:443 errors:0 dropped:0 overruns:0 carrier:1
collisions:0 txqueuelen:1000
RX bytes:152934 (149.3 Kb) TX bytes:51683 (50.4 Kb)
Interrupt:11 Base address:0x6000 Memory:c0214000-c0214fff
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:6 errors:0 dropped:0 overruns:0 frame:0
TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:300 (300.0 b) TX bytes:300 (300.0 b)
ppp0 Link encap:Point-to-Point Protocol
inet addr:192.168.0.20 P-t-P:192.168.0.4 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:338 Metric:1
RX packets:9 errors:0 dropped:0 overruns:0 frame:0
TX packets:178 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:187 (187.0 b) TX bytes:14008 (13.6 Kb)
bash-2.05b# netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
206.162.166.100 192.168.123.254 255.255.255.255 UGH 0 0 0 eth1
192.168.0.4 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
192.168.123.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
127.0.0.0 127.0.0.1 255.0.0.0 UG 0 0 0 lo
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 ppp0
bash-2.05b#
bash-2.05b# tcpdump -i ppp0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
21:27:07.664119 IP 192.168.0.20 > 192.168.0.4: icmp 64: echo request seq 1
21:27:07.664447 IP 192.168.0.20.32781 > 192.168.0.12.domain: 44311+ PTR? 4.0.168.192.in-addr.arpa. (42)
21:27:07.664711 IP 192.168.0.20.32782 > 192.168.0.12.domain: 44103+ PTR? 100.166.162.206.in-addr.arpa. (46)
21:27:08.663366 IP 192.168.0.20 > 192.168.0.4: icmp 64: echo request seq 2
21:27:09.663218 IP 192.168.0.20 > 192.168.0.4: icmp 64: echo request seq 3
21:27:10.663065 IP 192.168.0.20 > 192.168.0.4: icmp 64: echo request seq 4
21:27:11.662907 IP 192.168.0.20 > 192.168.0.4: icmp 64: echo request seq 5
21:27:12.662755 IP 192.168.0.20 > 192.168.0.4: icmp 64: echo request seq 6
21:27:12.664677 IP 192.168.0.20.32783 > 192.168.0.14.domain: 44311+ PTR? 4.0.168.192.in-addr.arpa. (42)
21:27:12.664712 IP 192.168.0.20.32784 > 192.168.0.14.domain: 44103+ PTR? 100.166.162.206.in-addr.arpa. (46)
21:27:13.662604 IP 192.168.0.20 > 192.168.0.4: icmp 64: echo request seq 7
21:27:14.662453 IP 192.168.0.20 > 192.168.0.4: icmp 64: echo request seq 8
21:27:15.662297 IP 192.168.0.20 > 192.168.0.4: icmp 64: echo request seq 9
21:27:16.662061 IP 192.168.0.20 > 192.168.0.4: icmp 64: echo request seq 10
21:27:17.661998 IP 192.168.0.20 > 192.168.0.4: icmp 64: echo request seq 11
21:27:17.664904 IP 192.168.0.20.32781 > 192.168.0.12.domain: 44311+ PTR? 4.0.168.192.in-addr.arpa. (42)
21:27:17.664935 IP 192.168.0.20.32782 > 192.168.0.12.domain: 44103+ PTR? 100.166.162.206.in-addr.arpa. (46)
21:27:18.661842 IP 192.168.0.20 > 192.168.0.4: icmp 64: echo request seq 12
21:27:19.661688 IP 192.168.0.20 > 192.168.0.4: icmp 64: echo request seq 13
21:27:20.661538 IP 192.168.0.20 > 192.168.0.4: icmp 64: echo request seq 14
21:27:21.661305 IP 192.168.0.20 > 192.168.0.4: icmp 64: echo request seq 15
21:27:22.661238 IP 192.168.0.20 > 192.168.0.4: icmp 64: echo request seq 16
21:27:22.665143 IP 192.168.0.20.32783 > 192.168.0.14.domain: 44311+ PTR? 4.0.168.192.in-addr.arpa. (42)
21:27:22.665172 IP 192.168.0.20.32784 > 192.168.0.14.domain: 44103+ PTR? 100.166.162.206.in-addr.arpa. (46)
21:27:23.661083 IP 192.168.0.20 > 192.168.0.4: icmp 64: echo request seq 17
21:27:24.660934 IP 192.168.0.20 > 192.168.0.4: icmp 64: echo request seq 18
21:27:25.660780 IP 192.168.0.20 > 192.168.0.4: icmp 64: echo request seq 19
21:27:26.660632 IP 192.168.0.20 > 192.168.0.4: icmp 64: echo request seq 20
21:27:27.660476 IP 192.168.0.20 > 192.168.0.4: icmp 64: echo request seq 21
21:27:27.665491 IP 192.168.0.20.32785 > 192.168.0.12.domain: 44312+ PTR? 20.0.168.192.in-addr.arpa. (43)
21:27:27.665577 IP 192.168.0.20.32786 > 192.168.0.12.domain: 44104+ PTR? 124.123.168.192.in-addr.arpa. (46)
21:27:28.660324 IP 192.168.0.20 > 192.168.0.4: icmp 64: echo request seq 22
21:27:29.660179 IP 192.168.0.20 > 192.168.0.4: icmp 64: echo request seq 23
21:27:30.660022 IP 192.168.0.20 > 192.168.0.4: icmp 64: echo request seq 24
21:27:31.659787 IP 192.168.0.20 > 192.168.0.4: icmp 64: echo request seq 25
21:27:32.659636 IP 192.168.0.20 > 192.168.0.4: icmp 64: echo request seq 26
bash-2.05b# tcpdump -i eth1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
21:27:07.664487 IP 192.168.123.124 > 206.162.166.100: call 4 seq 73 gre-ppp-payload
21:27:07.664501 IP 192.168.123.124 > 206.162.166.100: call 4 seq 74 gre-ppp-payload
21:27:07.664736 IP 192.168.123.124 > 206.162.166.100: call 4 seq 75 gre-ppp-payload
21:27:08.663412 IP 192.168.123.124 > 206.162.166.100: call 4 seq 76 gre-ppp-payload
21:27:09.663269 IP 192.168.123.124 > 206.162.166.100: call 4 seq 77 gre-ppp-payload
21:27:10.663116 IP 192.168.123.124 > 206.162.166.100: call 4 seq 78 gre-ppp-payload
21:27:11.662950 IP 192.168.123.124 > 206.162.166.100: call 4 seq 79 gre-ppp-payload
21:27:12.662795 IP 192.168.123.124 > 206.162.166.100: call 4 seq 80 gre-ppp-payload
21:27:12.663653 arp who-has 192.168.123.254 tell 192.168.123.124
21:27:12.664695 IP 192.168.123.124 > 206.162.166.100: call 4 seq 81 gre-ppp-payload
21:27:12.664729 IP 192.168.123.124 > 206.162.166.100: call 4 seq 82 gre-ppp-payload
21:27:12.666719 arp reply 192.168.123.254 is-at 00:50:18:30:70:ce
21:27:13.662645 IP 192.168.123.124 > 206.162.166.100: call 4 seq 83 gre-ppp-payload
21:27:14.662494 IP 192.168.123.124 > 206.162.166.100: call 4 seq 84 gre-ppp-payload
21:27:15.662337 IP 192.168.123.124 > 206.162.166.100: call 4 seq 85 gre-ppp-payload
21:27:16.617159 IP 192.168.123.124.32782 > 206.162.166.100.1723: P 3151481323:3151481339(16) ack 3403836310 win 5840: pptp CTRL_MSGTYPE=ECHORQ ID(11)
21:27:16.662098 IP 192.168.123.124 > 206.162.166.100: call 4 seq 86 gre-ppp-payload
21:27:16.671181 IP 206.162.166.100.1723 > 192.168.123.124.32782: P 1:21(20) ack 16 win 16352: pptp CTRL_MSGTYPE=ECHORP ID(11) RESULT_CODE(1) ERR_CODE(0)
21:27:16.671199 IP 192.168.123.124.32782 > 206.162.166.100.1723: . ack 21 win 5840
21:27:17.662070 IP 192.168.123.124 > 206.162.166.100: call 4 seq 87 gre-ppp-payload
21:27:17.664923 IP 192.168.123.124 > 206.162.166.100: call 4 seq 88 gre-ppp-payload
21:27:17.664952 IP 192.168.123.124 > 206.162.166.100: call 4 seq 89 gre-ppp-payload
21:27:17.711096 IP 206.162.166.100 > 192.168.123.124: call 0 ack 86 no-payload
21:27:18.661881 IP 192.168.123.124 > 206.162.166.100: call 4 seq 90 gre-ppp-payload
21:27:19.661725 IP 192.168.123.124 > 206.162.166.100: call 4 seq 91 gre-ppp-payload
21:27:20.661577 IP 192.168.123.124 > 206.162.166.100: call 4 seq 92 gre-ppp-payload
21:27:21.661350 IP 192.168.123.124 > 206.162.166.100: call 4 seq 93 gre-ppp-payload
21:27:22.661278 IP 192.168.123.124 > 206.162.166.100: call 4 seq 94 gre-ppp-payload
21:27:22.665160 IP 192.168.123.124 > 206.162.166.100: call 4 seq 95 gre-ppp-payload
21:27:22.665188 IP 192.168.123.124 > 206.162.166.100: call 4 seq 96 gre-ppp-payload
21:27:23.661124 IP 192.168.123.124 > 206.162.166.100: call 4 seq 97 gre-ppp-payload
21:27:24.660975 IP 192.168.123.124 > 206.162.166.100: call 4 seq 98 gre-ppp-payload
21:27:25.660820 IP 192.168.123.124 > 206.162.166.100: call 4 seq 99 gre-ppp-payload
21:27:26.660682 IP 192.168.123.124 > 206.162.166.100: call 4 seq 100 gre-ppp-payload
21:27:27.660518 IP 192.168.123.124 > 206.162.166.100: call 4 seq 101 gre-ppp-payload
21:27:27.665510 IP 192.168.123.124 > 206.162.166.100: call 4 seq 102 gre-ppp-payload
21:27:27.665596 IP 192.168.123.124 > 206.162.166.100: call 4 seq 103 gre-ppp-payload
21:27:27.721280 IP 206.162.166.100 > 192.168.123.124: call 0 ack 101 no-payload
21:27:28.660365 IP 192.168.123.124 > 206.162.166.100: call 4 seq 104 gre-ppp-payload
21:27:29.660229 IP 192.168.123.124 > 206.162.166.100: call 4 seq 105 gre-ppp-payload
21:27:30.660065 IP 192.168.123.124 > 206.162.166.100: call 4 seq 106 gre-ppp-payload
21:27:31.659834 IP 192.168.123.124 > 206.162.166.100: call 4 seq 107 gre-ppp-payload
21:27:32.659684 IP 192.168.123.124 > 206.162.166.100: call 4 seq 108 gre-ppp-payload
21:27:32.665738 IP 192.168.123.124 > 206.162.166.100: call 4 seq 109 gre-ppp-payload
21:27:32.665773 IP 192.168.123.124 > 206.162.166.100: call 4 seq 110 gre-ppp-payload
21:27:33.659532 IP 192.168.123.124 > 206.162.166.100: call 4 seq 111 gre-ppp-payload
21:27:34.659455 IP 192.168.123.124 > 206.162.166.100: call 4 seq 112 gre-ppp-payload
21:27:35.659302 IP 192.168.123.124 > 206.162.166.100: call 4 seq 113 gre-ppp-payload
21:27:36.659149 IP 192.168.123.124 > 206.162.166.100: call 4 seq 114 gre-ppp-payload
21:27:37.658997 IP 192.168.123.124 > 206.162.166.100: call 4 seq 115 gre-ppp-payload
21:27:37.665966 IP 192.168.123.124 > 206.162.166.100: call 4 seq 116 gre-ppp-payload
21:27:37.665995 IP 192.168.123.124 > 206.162.166.100: call 4 seq 117 gre-ppp-payload
21:27:37.722973 IP 206.162.166.100 > 192.168.123.124: call 0 ack 116 no-payload
21:27:38.658845 IP 192.168.123.124 > 206.162.166.100: call 4 seq 118 gre-ppp-payload
21:27:39.658691 IP 192.168.123.124 > 206.162.166.100: call 4 seq 119 gre-ppp-payload
21:27:40.658550 IP 192.168.123.124 > 206.162.166.100: call 4 seq 120 gre-ppp-payload
21:27:41.658314 IP 192.168.123.124 > 206.162.166.100: call 4 seq 121 gre-ppp-payload
21:27:42.658250 IP 192.168.123.124 > 206.162.166.100: call 4 seq 122 gre-ppp-payload
21:27:42.666203 IP 192.168.123.124 > 206.162.166.100: call 4 seq 123 gre-ppp-payload
21:27:42.666231 IP 192.168.123.124 > 206.162.166.100: call 4 seq 124 gre-ppp-payload
21:27:43.658085 IP 192.168.123.124 > 206.162.166.100: call 4 seq 125 gre-ppp-payload
21:27:44.657850 IP 192.168.123.124 > 206.162.166.100: call 4 seq 126 gre-ppp-payload
21:27:45.657780 IP 192.168.123.124 > 206.162.166.100: call 4 seq 127 gre-ppp-payload
21:27:46.657633 IP 192.168.123.124 > 206.162.166.100: call 4 seq 128 gre-ppp-payload
21:27:47.657488 IP 192.168.123.124 > 206.162.166.100: call 4 seq 129 gre-ppp-payload
21:27:47.666944 IP 192.168.123.124 > 206.162.166.100: call 4 seq 130 gre-ppp-payload
21:27:47.667256 IP 192.168.123.124 > 206.162.166.100: call 4 seq 131 gre-ppp-payload
21:27:47.722459 IP 206.162.166.100 > 192.168.123.124: call 0 ack 130 no-payload |
|
Back to top |
|
|
egberts Guru
Joined: 04 Nov 2003 Posts: 357 Location: Dimmed Cathode Ray Tube
|
Posted: Thu Mar 17, 2005 4:17 am Post subject: |
|
|
Check the route table on the remote side.
# netstat -rn
If you can, do a tcpdump on the remote side... this will tell you a better story.
If no ICMP ECHO-REPLY packets gets sent back, then its the route table.
# cat /proc/net/ipv4/snmp
Look at ICMP counters... determine where the ICMP: InMsgs, InEchos, OutEchoReps and OutMsgs are bumping... |
|
Back to top |
|
|
Yogi-CH Guru
Joined: 19 Apr 2004 Posts: 372 Location: Somewhere in Texas, last I remember...
|
Posted: Fri Jul 08, 2005 10:11 pm Post subject: |
|
|
What does /etc/resolv.conf look like? I was having problems going through another host and discovered that two nameservers for the internet were missing and the only one in that file was the host's IP. I added the two nameserver xxx.xxx.xxx statements and it worked. _________________ ...Yogi |
|
Back to top |
|
|
zaai Apprentice
Joined: 24 Jul 2004 Posts: 175
|
Posted: Fri Nov 25, 2005 8:30 am Post subject: |
|
|
Did you ever find out what caused it?
I've got the same problem, but I'm almost certain that it is caused by iptables on the VPN server.
When setting the default INPUT chain rule to ACCEPT instead of DROP (eg, disabling the firewall), then pinging the VPN server on its LAN address suddenly starts to work.
Oddly enough, windows boxes just work.
Update:
Found the cause, the firewall rule was missing an entry for ppp* so the VPN connections can relay packets back to the user.
eg:
Quote: | iptables -A INPUT -i ppp+ -j ACCEPT |
Did the trick. _________________ * most bugs can be reduced to either dependency or state *
Athlon64 X2 4800+ on Asus M2N SLI deluxe with 4GB Dual channel
video nVidia GForce 7300 GS 512MB (snail); xorg-7.2
kernel 2.6.24-gentoo-r3 |
|
Back to top |
|
|
ajaygautam Apprentice
Joined: 23 Jan 2003 Posts: 205 Location: London Below
|
Posted: Mon Feb 13, 2006 1:34 am Post subject: |
|
|
I am facing the same problem too. Connects sucessfully (to MS VPN server), but ping fails.
I recently upgraded to 2.6.15 (MPPE builtin in the kernel), and can't connect to anything on the other side!
Everything seems fine: resolv.conf, route -n.
My gentoo laptop which I did not upgrade is working fine
Any help would be highly appreciated.
Ajay |
|
Back to top |
|
|
scoon l33t
Joined: 23 Aug 2003 Posts: 747 Location: Philadelphia, PA
|
Posted: Wed Mar 08, 2006 1:15 am Post subject: |
|
|
Hey there,
Ever get this working. I had it with 2.6.14 and the patch but with 2.6.15, no luck.
-scoon _________________ Hope this helps........ |
|
Back to top |
|
|
saschabieler n00b
Joined: 16 Jun 2004 Posts: 23 Location: Munich
|
Posted: Mon Mar 13, 2006 11:42 pm Post subject: |
|
|
Hi there,
first I got the same problems as discribed above, but now got it working!!! YEAH!
1. Against all tuts I disabled the mppe-mppc use-flag for net-dialup/ppp!!! And made my kernel 2.6.15 ready:
Code: | Cryptographic options --->
--- Cryptographic API
--- HMAC support
--- MD5 digest algorithm
<M> SHA1 digest algorithm
<M> SHA256 digest algorithm
<M> SHA384 and SHA512 digest algorithms
<M> DES and Triple DES EDE cipher algorithms
<M> Blowfish cipher algorithm
<M> AES cipher algorithms (i586)
<M> ARC4 cipher algorithm
<M> Deflate compression algorithm
Device Drivers --->
Networking support --->
<*> PPP (point-to-point protocol) support
[*] PPP multilink support (EXPERIMENTAL)
[*] PPP filtering
<M> PPP support for async serial ports
<M> PPP support for sync tty ports
<M> PPP Deflate compression
<M> PPP BSD-Compress compression
<M> PPP MPPE compression (encryption) (EXPERIMENTAL)
<M> PPP over Ethernet (EXPERIMENTAL)
<M> PPP over ATM |
2. Edited /etc/portage/package.keywords
Code: | net-dialup/ppp ~x86
net-dialup/pptpd ~x86 |
3. Emerged net-dialup/ppp-2.4.3-r11 and net-dialup/pptpd-1.3.0, because I use windbind to authenticate.
4. Edited /etc/ppp/options.pptpd
Code: | plugin winbind.so
ntlm_auth-helper "/usr/bin/ntlm_auth --helper-protocol=ntlm-server-1 --require-membership-of=SID_of_your_VPN_access_group"
noauth
lock
proxyarp
ms-dns ip_of_your_nameserver
ms-wins ip_of_your_wins_server
refuse-pap
refuse-chap
refuse-mschap
require-mschap-v2
require-mppe-128
require-mppe
nobsdcomp
nologfd
defaultroute
#debug
logfile /var/log/pptpd.log |
5. To be sure all neccessary modules will be loaded at boot time added the following to /etc/modules.autoload.d/kernel-2.6
Code: | ppp_generic
ppp_deflate
ppp_mppe |
6. Don't forget to open the relevant tcp-port 1723 and protocol GRE (47) to your ppp+ (ppp*) interfaces
Hope this will help and saves ur nights with ur girls...
Greetings
Sascha |
|
Back to top |
|
|
Naan Yaar Bodhisattva
Joined: 27 Jun 2002 Posts: 1549
|
Posted: Wed Mar 22, 2006 7:46 pm Post subject: |
|
|
Sascha,
I was banging my head over this one last night and stumbled upon your posting. The method suggested below works perfectly. MPPE and ppp have been an adventure, but the current solution without the external patch seems to be reasonably straightforward.
Thanks!
saschabieler wrote: | Hi there,
first I got the same problems as discribed above, but now got it working!!! YEAH!
1. Against all tuts I disabled the mppe-mppc use-flag for net-dialup/ppp!!! And made my kernel 2.6.15 ready:
...
Greetings
Sascha |
|
|
Back to top |
|
|
saschabieler n00b
Joined: 16 Jun 2004 Posts: 23 Location: Munich
|
Posted: Wed Mar 22, 2006 7:59 pm Post subject: |
|
|
Really happy now, that I helped someone out here...
World's best regards
Sascha |
|
Back to top |
|
|
|