Toon posts:

[Ubuntu] LCP Timeout probleem bij verbinden VPN

Pagina: 1
Acties:

Onderwerpen

Ubuntu

zaterdag 17 oktober 2009 21:17

Acties:
  • 0 Henk 'm!
  • JasperE
  • Registratie: December 2003
  • Laatst online: 18:26

JasperE

Topicstarter
Het lukt mij niet om een een VPN tunnel op te zetten vanuit mijn Ubuntu server naar een CISCO router vanwege foutmelding "LCP: timeout sending Config-Requests".
Vanuit een XP computer op het LAN achter deze ubuntu server lukt dit wel.
Deze handleiding heb ik gebruikt om mijn server te configureren.

De debug output bij verbinden
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

root@srv01:~# pppd call mijnvpn dump debug logfd 2 nodetach
pppd options in effect:
debug           # (from command line)
nodetach                # (from command line)
logfd 2         # (from command line)
dump            # (from command line)
noauth          # (from /etc/ppp/options.pptp)
refuse-chap             # (from /etc/ppp/options.pptp)
refuse-mschap           # (from /etc/ppp/options.pptp)
refuse-eap              # (from /etc/ppp/options.pptp)
name jasper             # (from /etc/ppp/peers/mijnvpn)
remotename PPTP         # (from /etc/ppp/peers/mijnvpn)
                # (from /etc/ppp/options.pptp)
pty pptp 123.123.123.123  --nolaunchpppd          # (from /etc/ppp/peers/mijnvpn)
crtscts         # (from /etc/ppp/options)
                # (from /etc/ppp/options)
asyncmap 0              # (from /etc/ppp/options)
lcp-echo-failure 4              # (from /etc/ppp/options)
lcp-echo-interval 30            # (from /etc/ppp/options)
hide-password           # (from /etc/ppp/options)
ipparam mijnvpn         # (from /etc/ppp/peers/mijnvpn)
proxyarp                # (from /etc/ppp/options)
nobsdcomp               # (from /etc/ppp/options.pptp)
nodeflate               # (from /etc/ppp/options.pptp)
require-mppe-128                # (from /etc/ppp/options.pptp)
noipx           # (from /etc/ppp/options)
using channel 64
Using interface ppp0
Connect: ppp0 <--> /dev/pts/2
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x44d5bf7f> <pcomp> <accomp>]
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x44d5bf7f> <pcomp> <accomp>]
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x44d5bf7f> <pcomp> <accomp>]
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x44d5bf7f> <pcomp> <accomp>]
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x44d5bf7f> <pcomp> <accomp>]
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x44d5bf7f> <pcomp> <accomp>]
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x44d5bf7f> <pcomp> <accomp>]
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x44d5bf7f> <pcomp> <accomp>]
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x44d5bf7f> <pcomp> <accomp>]
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x44d5bf7f> <pcomp> <accomp>]
LCP: timeout sending Config-Requests
Connection terminated.
Modem hangup
Waiting for 1 child processes...
  script pptp 123.123.123.123  --nolaunchpppd, pid 22814
sending SIGTERM to process 22814


Volgens deze site is deze situatie typisch voor wanneer er geen GRE communicatie mogelijk is.
If you see a series of sent [LCP ConfReq ...] messages with no rcvd messages, then you may not have GRE connectivity to the PPTP Server.
Hier wordt uitgelegd hoe tcpdump gebruikt kan worden om te analyseren wat er verzonden en ontvangen wordt.

De output van tcpdump:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

root@srv01:~# tcpdump -i eth0  -s 0 tcp port 1723 or proto 47
20:53:44.150867 IP srv01.mshome.33828 > de.vpn.server.net.1723: S 470263735:470263735(0) win 5840 <mss 1460,sackOK,timestamp 275393343 0,nop,wscale 6>
20:53:44.161173 IP de.vpn.server.net.1723 > srv01.mshome.33828: S 2758575726:2758575726(0) ack 470263736 win 4128 <mss 536>
20:53:44.161203 IP srv01.mshome.33828 > de.vpn.server.net.1723: . ack 1 win 5840
20:53:44.161954 IP srv01.mshome.33828 > de.vpn.server.net.1723: P 1:157(156) ack 1 win 5840: pptp CTRL_MSGTYPE=SCCRQ PROTO_VER(1.0) FRAME_CAP(AS) BEARER_CAP(DA) MAX_CHAN(65535) FIRM_REV(1) HOSTNAME(local) VENDOR(cananian)
20:53:44.173072 IP de.vpn.server.net.1723 > srv01.mshome.33828: P 1:157(156) ack 157 win 3972: pptp CTRL_MSGTYPE=SCCRP PROTO_VER(1.0) RESULT_CODE(1) ERR_CODE(0) FRAME_CAP(AS) BEARER_CAP(DA) MAX_CHAN(0) FIRM_REV(4608) HOSTNAME(C871) VENDOR(Cisco Systems, Inc.)
20:53:44.173097 IP srv01.mshome.33828 > de.vpn.server.net.1723: . ack 157 win 6432
20:53:45.162495 IP srv01.mshome.33828 > de.vpn.server.net.1723: P 157:325(168) ack 157 win 6432: pptp CTRL_MSGTYPE=OCRQ CALL_ID(0) CALL_SER_NUM(0) MIN_BPS(2400) MAX_BPS(10000000) BEARER_TYPE(Any) FRAME_TYPE(E) RECV_WIN(3) PROC_DELAY(0) PHONE_NO_LEN(0) PHONE_NO() SUB_ADDR()
20:53:45.172236 IP de.vpn.server.net.1723 > srv01.mshome.33828: . ack 325 win 3804
20:54:20.266597 IP srv01.mshome.33828 > de.vpn.server.net.1723: P 325:341(16) ack 157 win 6432: pptp CTRL_MSGTYPE=CCRQ CALL_ID(0)
20:54:20.266679 IP srv01.mshome.33828 > de.vpn.server.net.1723: F 341:341(0) ack 157 win 6432
20:54:20.276472 IP de.vpn.server.net.1723 > srv01.mshome.33828: . ack 341 win 3788
20:54:20.485524 IP srv01.mshome.33828 > de.vpn.server.net.1723: F 341:341(0) ack 157 win 6432
20:54:20.495029 IP de.vpn.server.net.1723 > srv01.mshome.33828: . ack 342 win 3788
20:54:20.495791 IP de.vpn.server.net.1723 > srv01.mshome.33828: R 2758575883:2758575883(0) win 3788

478 packets captured
478 packets received by filter
0 packets dropped by kernel

Er lijkt dus geen GRE netwerkverkeer te zijn.

Mijn Ubuntu server waarmee ik verbinding probeer te maken heeft twee netwerkkaarten en functioneert als NAT gateway voor mijn LAN. Vanaf mijn XP computer op dit LAN kan ik -wel- een VPN verbinding maken, maar vanaf ubuntu niet.

In mijn iptables kan ik geen regels vinden die protocol 47 zouden blokkeren. Dit wordt zelfs expliciet toegestaan.
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

root@srv01:~# iptables -L -n
Chain INPUT (policy DROP)
target     prot opt source               destination         
ACCEPT     47   --  0.0.0.0/0            0.0.0.0/0           
fail2ban-apache  tcp  --  0.0.0.0/0            0.0.0.0/0           multiport dports 80,443 
fail2ban-ssh  tcp  --  0.0.0.0/0            0.0.0.0/0           multiport dports 22 
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           
Badflags   tcp  --  0.0.0.0/0            0.0.0.0/0           tcp flags:0x11/0x01 
Badflags   tcp  --  0.0.0.0/0            0.0.0.0/0           tcp flags:0x18/0x08 
Badflags   tcp  --  0.0.0.0/0            0.0.0.0/0           tcp flags:0x30/0x20 
Badflags   tcp  --  0.0.0.0/0            0.0.0.0/0           tcp flags:0x05/0x05 
Badflags   tcp  --  0.0.0.0/0            0.0.0.0/0           tcp flags:0x03/0x03 
Badflags   tcp  --  0.0.0.0/0            0.0.0.0/0           tcp flags:0x06/0x06 
Badflags   tcp  --  0.0.0.0/0            0.0.0.0/0           tcp flags:0x3F/0x3F 
Badflags   tcp  --  0.0.0.0/0            0.0.0.0/0           tcp flags:0x3F/0x00 
Badflags   tcp  --  0.0.0.0/0            0.0.0.0/0           tcp flags:0x3F/0x29 
Badflags   tcp  --  0.0.0.0/0            0.0.0.0/0           tcp flags:0x3F/0x2B 
Badflags   tcp  --  0.0.0.0/0            0.0.0.0/0           tcp flags:0x3F/0x37 
ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0           icmp type 8 limit: avg 1/sec burst 5 
Firewall   icmp --  0.0.0.0/0            0.0.0.0/0           
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:22 
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:80 
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED 
DROP       udp  --  0.0.0.0/0            0.0.0.0/0           udp dpts:137:139 
Rejectwall  all  --  0.0.0.0/0            0.0.0.0/0           

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
DROP       all  --  0.0.0.0/0            0.0.0.0/0           state INVALID,NEW 

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     47   --  0.0.0.0/0            0.0.0.0/0           

Chain Badflags (11 references)
target     prot opt source               destination         
DROP       all  --  0.0.0.0/0            0.0.0.0/0           

Chain Firewall (6 references)
target     prot opt source               destination         
DROP       all  --  0.0.0.0/0            0.0.0.0/0           

Chain Rejectwall (1 references)
target     prot opt source               destination         
REJECT     all  --  0.0.0.0/0            0.0.0.0/0           reject-with icmp-port-unreachable 

Chain fail2ban-apache (1 references)
target     prot opt source               destination         
RETURN     all  --  0.0.0.0/0            0.0.0.0/0           

Chain fail2ban-ssh (1 references)
target     prot opt source               destination         
RETURN     all  --  0.0.0.0/0            0.0.0.0/0


Op de eerder geplaatste site wordt vervolgens gezegd dat met hping2 GRE connectiviteit getest kan worden.
code:
1
2
3
4
5
6
7

root@srv01:~# hping -0 -H 47 -d 10 --traceroute de.vpn.server.net
HPING de.vpn.server.net (eth0 123.123.123.123): raw IP mode set, 20 headers + 10 data bytes
hop=1 TTL 0 during transit from ip=195.169.xxx.xxx name=rtr.xxxx.net
hop=2 TTL 0 during transit from ip=131.174.xxx.xxx name=xxx.nl
hop=3 TTL 0 during transit from ip=145.145.xxx.xxx name=xxxsurf.net
hop=4 TTL 0 during transit from ip=145.145.xxx.xxx name=xxxsurf.net
hop=5 TTL 0 during transit from ip=195.69.xxx.xxx name=xxx.kpn.net

Als ik tijdens dit pingen tcpdump draai verschijnt er wel GRE verkeer:
code:
1
2
3
4
5
6

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
21:08:38.620559 IP srv01.mshome > de.vpn.server.net: GREv0, off 0x5858[|gre]
21:08:39.620474 IP srv01.mshome > de.vpn.server.net: GREv0, off 0x5858[|gre]
21:08:40.620531 IP srv01.mshome > de.vpn.server.net: GREv0, off 0x5858[|gre]
etc...


Met hping2 lijkt er dus wel GRE verkeer tot stand te komen maar met pppd niet :/


Mijn pppd peer configuratie:
code:
1
2
3
4
5
6
7

root@srv01:~# cat /etc/ppp/peers/mijnvpn
pty "pptp 123.123.123.123  --nolaunchpppd"
name jasper
remotename PPTP
require-mppe-128
file /etc/ppp/options.pptp
ipparam mijnvpn



Ik kom er dus niet uit waarom het GRE verkeer niet tot stand komt :(
Iemand ideeen?

Overige info:
code:
1
2
3
4

root@srv01:~# uname -a
Linux srv01 2.6.24-24-server #1 SMP Sat Aug 22 01:40:42 UTC 2009 i686 GNU/Linux
root@srv01:~# pppd --version
pppd version 2.4.4

De configuratie van mijn cisco router: http://gathering.tweakers.net/forum/view_message/32753502

maandag 19 oktober 2009 16:34

Acties:
  • 0 Henk 'm!
  • JasperE
  • Registratie: December 2003
  • Laatst online: 18:26

JasperE

Topicstarter
Kickje....

woensdag 21 oktober 2009 20:08

Acties:
  • 0 Henk 'm!
  • JasperE
  • Registratie: December 2003
  • Laatst online: 18:26

JasperE

Topicstarter
Nu blijkt dat ik met andere VPN servers vanaf mijn ubuntu servers wel verbinding kan maken, bijvoorbeeld vpn.uni-due.de (gevonden via google om te testen). Met GRE netwerkverkeer zit het dus blijkbaar wel goed.

Dus met mijn CISCO kan ik vanaf XP wel verbinding maken, maar vanaf ubuntu niet. Terwijl ubuntu wel met andere VPN servers verbinding kan krijgen.

Na enkele debug options op de cisco router aangezet te hebben krijg ik de volgende output als ik met ubuntu verbhinding probeer te krijgen:

CISCO DEBUG OUTPUT:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

.Oct 21 17:47:39.003: PPTP tnl   352341:_____: I 009C00011A2B3C4D0001000001000000000000030000...
.Oct 21 17:47:39.003: PPTP tnl   352341:_____: I SCCRQ
.Oct 21 17:47:39.003: PPTP tnl   352341:_____: protocol version 100
.Oct 21 17:47:39.003: PPTP tnl   352341:_____: framing caps 3
.Oct 21 17:47:39.003: PPTP tnl   352341:_____: bearer caps 3
.Oct 21 17:47:39.003: PPTP tnl   352341:_____: max channels 65535
.Oct 21 17:47:39.003: PPTP tnl   352341:_____: firmware rev 1
.Oct 21 17:47:39.003: PPTP tnl   352341:_____: hostname "local"
.Oct 21 17:47:39.003: PPTP tnl   352341:_____: vendor "cananian"
.Oct 21 17:47:39.007: PPTP tnl   352341:_____: O SCCRP
.Oct 21 17:47:40.003: PPTP tnl   352341:_____: I 00A800011A2B3C4D0007000000000000000009600098...
.Oct 21 17:47:40.003: PPTP tnl   352341:_____: CC I OCRQ
.Oct 21 17:47:40.003: PPTP tnl   352341:_____: call id 0
.Oct 21 17:47:40.003: PPTP tnl   352341:_____: serial num 0
.Oct 21 17:47:40.003: PPTP tnl   352341:_____: min bps 2400
.Oct 21 17:47:40.003: PPTP tnl   352341:_____: max bps 10000000
.Oct 21 17:47:40.003: PPTP tnl   352341:_____: bearer type 3
.Oct 21 17:47:40.007: PPTP tnl   352341:_____: framing type 3
.Oct 21 17:47:40.007: PPTP tnl   352341:_____: recv win size 3
.Oct 21 17:47:40.007: PPTP tnl   352341:_____: ppd 0
.Oct 21 17:47:40.007: PPTP tnl   352341:_____: phone num len 0
.Oct 21 17:47:40.007: PPTP tnl   352341:_____: phone num ""
C871#

En dan niets meer....

Als ik met XP verbinding maakt (werkt wel)
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

.Oct 21 17:48:24.356: PPTP tnl   356438:_____: I 009C00011A2B3C4D0001000001000000000000010000...
.Oct 21 17:48:24.356: PPTP tnl   356438:_____: I SCCRQ
.Oct 21 17:48:24.356: PPTP tnl   356438:_____: protocol version 100
.Oct 21 17:48:24.356: PPTP tnl   356438:_____: framing caps 1
.Oct 21 17:48:24.356: PPTP tnl   356438:_____: bearer caps 1
.Oct 21 17:48:24.356: PPTP tnl   356438:_____: max channels 0
.Oct 21 17:48:24.356: PPTP tnl   356438:_____: firmware rev A28
.Oct 21 17:48:24.356: PPTP tnl   356438:_____: hostname ""
.Oct 21 17:48:24.356: PPTP tnl   356438:_____: vendor "Microsoft Windows NT"
.Oct 21 17:48:24.356: PPTP tnl   356438:_____: O SCCRP
.Oct 21 17:48:24.368: PPTP tnl   356438:_____: I 00A800011A2B3C4D00070000400052240000012C05F5...
.Oct 21 17:48:24.368: PPTP tnl   356438:_____: CC I OCRQ
.Oct 21 17:48:24.368: PPTP tnl   356438:_____: call id 16384
.Oct 21 17:48:24.368: PPTP tnl   356438:_____: serial num 21028
.Oct 21 17:48:24.368: PPTP tnl   356438:_____: min bps 300
.Oct 21 17:48:24.368: PPTP tnl   356438:_____: max bps 100000000
.Oct 21 17:48:24.368: PPTP tnl   356438:_____: bearer type 3
.Oct 21 17:48:24.368: PPTP tnl   356438:_____: framing type 3
.Oct 21 17:48:24.368: PPTP tnl   356438:_____: recv win size 64
.Oct 21 17:48:24.368: PPTP tnl   356438:_____: ppd 0
.Oct 21 17:48:24.368: PPTP tnl   356438:_____: phone num len 0
.Oct 21 17:48:24.368: PPTP tnl   356438:_____: phone num ""
.Oct 21 17:48:24.372: PPTP _____:356438:_____: CC O OCRP
.Oct 21 17:48:24.376: AAA/BIND(00000017): Bind i/f
.Oct 21 17:48:24.380: AAA/BIND(00000017): Bind i/f Virtual-Template1
etc. etc. etc.


Nu zegt deze debug output mij vrij weinig en erop googlen lukt ook niet echt.

De regel die bij ubuntu niet meer voorkomt die er bij XP wel staat en vanaf waar het stil blijft bevat de term
OCRP = Outgoing-Call-Reply. Bij ubuntu wordt er dus schijnbaar geen outgoing call reply gestuurd door de CISCO router...

Iemand enig idee hoe verder te gaan of waar 't fout gaat?

vrijdag 23 oktober 2009 19:08

Acties:
  • 0 Henk 'm!
  • JasperE
  • Registratie: December 2003
  • Laatst online: 18:26

JasperE

Topicstarter
Nogmaals een subtiel kickje, misschien tijd voor een move naar het NT of PNS forum?

woensdag 28 oktober 2009 00:06

Acties:
  • 0 Henk 'm!
  • JasperE
  • Registratie: December 2003
  • Laatst online: 18:26

JasperE

Topicstarter
Kick :| -O-

[ Voor 26% gewijzigd door JasperE op 28-10-2009 16:29 ]

Reageer

Apple iPhone 16e LG OLED evo G5 Google Pixel 10 Samsung Galaxy S25 Star Wars: Outlaws Nintendo Switch 2 Apple AirPods Pro (2e generatie) Sony PlayStation 5 Pro

Tweakers is onderdeel van DPG Media B.V.
Alle rechten voorbehouden - Auteursrecht © 1998 - 2025 • Hosting door TrueFullstaq