[pptpd/VPN] werkt niet!

Pagina: 1
Acties:

  • kvdveer
  • Registratie: November 2000
  • Laatst online: 06-11-2025
ik heb op mijn lokale linuxbakje de pptpd deamon geinstalleerd op mijn lokale bak... werkt prima (op wat details na, maar dat komt nog)
probleem is echter. Dat is mijn eigen pc-tje, en niet die van mijn stage.

voordat ik met mijn probleemmachine aan de haal ga, eerst nog wat details over de werkende configuratie:
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
[root@router etc]# grep pptpd < /var/log/syslog
  [snip]
Jan 31 22:36:01 router pptpd[2010]: MGR: Launching /usr/sbin/pptpctrl to handle client
Jan 31 22:36:01 router pptpd[2010]: CTRL: local address = 192.168.0.1
Jan 31 22:36:01 router pptpd[2010]: CTRL: remote address = 192.168.1.1
Jan 31 22:36:01 router pptpd[2010]: CTRL: Client 10.0.0.2 control connection started
Jan 31 22:36:01 router pptpd[2010]: CTRL: Received PPTP Control Message (type: 1)
Jan 31 22:36:01 router pptpd[2010]: CTRL: Made a START CTRL CONN RPLY packet
Jan 31 22:36:01 router pptpd[2010]: CTRL: I wrote 156 bytes to the client.
Jan 31 22:36:01 router pptpd[2010]: CTRL: Sent packet to client
Jan 31 22:36:03 router pptpd[2010]: CTRL: Received PPTP Control Message (type: 7)
Jan 31 22:36:03 router pptpd[2010]: CTRL: 0 min_bps, 1525 max_bps, 32 window size
Jan 31 22:36:03 router pptpd[2010]: CTRL: Made a OUT CALL RPLY packet
Jan 31 22:36:03 router pptpd[2010]: CTRL: Starting call (launching pppd, opening GRE)
Jan 31 22:36:03 router pptpd[2010]: CTRL: pty_fd = 4
Jan 31 22:36:03 router pptpd[2010]: CTRL: tty_fd = 5
Jan 31 22:36:03 router pptpd[2010]: CTRL: I wrote 32 bytes to the client.
Jan 31 22:36:03 router pptpd[2010]: CTRL: Sent packet to client
Jan 31 22:36:03 router pptpd[2011]: CTRL (PPPD Launcher): Connection speed = 115200
Jan 31 22:36:03 router pptpd[2011]: CTRL (PPPD Launcher): local address = 192.168.0.1
Jan 31 22:36:03 router pptpd[2011]: CTRL (PPPD Launcher): remote address = 192.168.1.1
Jan 31 22:36:03 router pptpd[2010]: CTRL: Received PPTP Control Message (type: 15)
Jan 31 22:36:03 router pptpd[2010]: CTRL: Got a SET LINK INFO packet with standard ACCMs
Jan 31 22:36:05 router pptpd[2010]: CTRL: Received PPTP Control Message (type: 15)
Jan 31 22:36:05 router pptpd[2010]: CTRL: Ignored a SET LINK INFO packet with real ACCMs!
Jan 31 22:37:01 router pptpd[2010]: CTRL: Received PPTP Control Message (type: 5)
Jan 31 22:37:01 router pptpd[2010]: CTRL: Made a ECHO RPLY packet
Jan 31 22:37:01 router pptpd[2010]: CTRL: I wrote 20 bytes to the client.
Jan 31 22:37:01 router pptpd[2010]: CTRL: Sent packet to client
[snip]

[root@router etc]# ifconfig
eth0    Link encap:Ethernet  HWaddr 00:60:08:66:4E:BD
  [snip]

eth1    Link encap:Ethernet  HWaddr 00:60:8C:82:D0:82
  [snip]

lo    Link encap:Local Loopback
  [snip]

ppp0    Link encap:Point-to-Point Protocol
        inet addr:192.168.0.1  P-t-P:192.168.1.1  Mask:255.255.255.255
        UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
        RX packets:140 errors:0 dropped:0 overruns:0 frame:0
        TX packets:17 errors:0 dropped:0 overruns:0 carrier:0
        collisions:0 txqueuelen:3
        RX bytes:8822 (8.6 Kb)  TX bytes:576 (576.0 b)

windows:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
D:\>ipconfig

Windows 2000 IP-configuratie

Ethernet adapter LAN-verbinding:

      Verbindingsspecifiek DNS-achtervoegsel:
      IP-adres . . . . . . . . . . . . . . .: 10.0.0.2
      Subnetmask . . . . . . . . . . . . . .: 255.255.255.0
      Standaardgateway . . . . . . . . . . .: 10.0.0.1

PPP adapter Virtuele particuliere verbinding:

      Verbindingsspecifiek DNS-achtervoegsel:
      IP-adres . . . . . . . . . . . . . . .: 192.168.1.1
      Subnetmask . . . . . . . . . . . . . .: 255.255.255.255
      Standaardgateway . . . . . . . . . . .: 192.168.1.1

Tot zo ver de werkende configuratie

+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

De (momenteel) remote server loop ook prima, totdat de gebruikersnaam en wachtwoord zijn gecontroleerd. Dan krijg ik de melding dat de server geen IP-adres heeft toegewezen. (738). Vervolgens wordt de verbinding niet verder tot stand gebracht.

wat details over de nietwerkende server:
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
[root@10 tmp]# grep pptpd < /var/log/syslog
Feb  1 01:05:24 10 pptpd[9025]: MGR: Launching /usr/sbin/pptpctrl to handle client
Feb  1 01:05:24 10 pptpd[9025]: CTRL: Client *MIJN IP* control connection started
Feb  1 01:05:24 10 pptpd[9025]: CTRL: Received PPTP Control Message (type: 1)
Feb  1 01:05:24 10 pptpd[9025]: CTRL: Made a START CTRL CONN RPLY packet
Feb  1 01:05:24 10 pptpd[9025]: CTRL: I wrote 156 bytes to the client.
Feb  1 01:05:24 10 pptpd[9025]: CTRL: Sent packet to client
Feb  1 01:05:24 10 pptpd[9025]: CTRL: Received PPTP Control Message (type: 7)
Feb  1 01:05:24 10 pptpd[9025]: CTRL: Set parameters to 1525 maxbps, 64 window size
Feb  1 01:05:24 10 pptpd[9025]: CTRL: Made a OUT CALL RPLY packet
Feb  1 01:05:24 10 pptpd[9025]: CTRL: Starting call (launching pppd, opening GRE)
Feb  1 01:05:24 10 pptpd[9025]: CTRL: pty_fd = 4
Feb  1 01:05:24 10 pptpd[9025]: CTRL: tty_fd = 5
Feb  1 01:05:24 10 pptpd[9026]: CTRL (PPPD Launcher): Connection speed = 115200
Feb  1 01:05:24 10 pptpd[9025]: CTRL: I wrote 32 bytes to the client.
Feb  1 01:05:24 10 pptpd[9025]: CTRL: Sent packet to client
Feb  1 01:05:24 10 pptpd[9025]: GRE: Discarding duplicate packet
Feb  1 01:05:24 10 pptpd[9025]: CTRL: Received PPTP Control Message (type: 15)
Feb  1 01:05:24 10 pptpd[9025]: CTRL: Got a SET LINK INFO packet with standard ACCMs
Feb  1 01:05:29 10 pptpd[9025]: CTRL: Received PPTP Control Message (type: 15)
Feb  1 01:05:29 10 pptpd[9025]: CTRL: Ignored a SET LINK INFO packet with real ACCMs!
Feb  1 01:05:37 10 pptpd[9025]: CTRL: Received PPTP Control Message (type: 15)
Feb  1 01:05:37 10 pptpd[9025]: CTRL: Ignored a SET LINK INFO packet with real ACCMs!
Feb  1 01:05:37 10 pptpd[9025]: CTRL: Received PPTP Control Message (type: 12)
Feb  1 01:05:37 10 pptpd[9025]: CTRL: Made a CALL DISCONNECT RPLY packet
Feb  1 01:05:37 10 pptpd[9025]: CTRL: Received CALL CLR request (closing call)
Feb  1 01:05:37 10 pptpd[9025]: CTRL: I wrote 148 bytes to the client.
Feb  1 01:05:37 10 pptpd[9025]: CTRL: Sent packet to client
Feb  1 01:05:37 10 pptpd[9025]: CTRL: Error with select(), quitting
Feb  1 01:05:37 10 pptpd[9025]: CTRL: Client *MIJN IP* control connection finished
Feb  1 01:05:37 10 pptpd[9025]: CTRL: Exiting now
Feb  1 01:05:37 10 pptpd[8925]: MGR: Reaped child 9025

Verder kan ik niet echt veel gegevens zien, omdat de verbinding niet tot stand wordt gebracht :'(

Localhost, sweet localhost


  • kvdveer
  • Registratie: November 2000
  • Laatst online: 06-11-2025
sorry voor mijn ongeduld maarem.... Heeft echt niemand een idee?

Localhost, sweet localhost


Verwijderd

Die foutmelding had ik pas ook, en die is opgelost door local en remote ip in /etc/ppp/options op te geven:

Zo: 10.0.0.1:10.0.0.2

Anders post je ff je config files.

  • The Lord
  • Registratie: November 1999
  • Laatst online: 20:41
Kun je er ook schetsjes bij doen van de twee oplossingen?

Wellicht vind er ergens NAT plaats? Dat is namelijk een veel voorkomend probleem met de encapsulation headers van PPTP.

geeft geen inhoudelijke reacties meer


  • kvdveer
  • Registratie: November 2000
  • Laatst online: 06-11-2025
werkende situatie:
code:
1
2
3
4
              ( NAT )
                 |
   ( VPNserver ) ------+------ (Mijn bak)
    (10.0.0.71)         (10.0.0.2)

niet werkende situatie:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
           (4 workstations)
               || ||
                Y Y
                 Y  intern (10.0.0.x)
              ( NAT )
             ( VPNserver )
                 |  Luna (217.x.x.x)
                 ?   
                 ?
                 |  Chello (62.x.x.x)
              ( NAT )
                 |  Intern (10.0.0.x)
            ... -+------ (Mijn bak)

Er zit inderdaad een NAT tussen.
maar PPTP is toch bedoeld om veilig door een NAT heen te komen?

Localhost, sweet localhost


Verwijderd

komt het niet omdat je ipadres op de vpn adapter op je windows machine het zelfde ip is als het remote adres van je linux machine
namelijk 192.168.1.1

  • Freez
  • Registratie: November 2000
  • Laatst online: 19-08 10:13
je krijgt het 192.168.1.1 adres van een dhcp van die linux bak?? zo ja dan is hij niet goed geconfigureerd, het werkt namelijk niet als je eigen ip hetzelfde is als de gateway. zie het stukje ipconfig onder windows.... linux wil ook nog wel es struikelen over een foute subnets: 192.168.x.x is een classe c adres, bij een classe c hoort de subnet van 255.255.255.0.

misschien dat je hier iets mee kan?

  • The Lord
  • Registratie: November 1999
  • Laatst online: 20:41
Zoals jij het wil kan niet met PPTP.

Ongeveer het volgende gebeurt :

- Client encapsulates data-packet in PPTP.
- NAT modificeert IP-source header van het PPTP pakket.
- VPN server :
* krijgt pakket binnen.
* authenticeert pakket.
* gaat PPTP un-encapsulaten.
* bakt een reply en capsulates deze.
* verzend de reply naar het IP adres dat uit de PPPPPTP header is gedistilleerd (dat is dus 10.x.x.x!)

En dat kan niet, want die 10.x.x.x is niet routable vanaf je VPN server.

geeft geen inhoudelijke reacties meer


  • kvdveer
  • Registratie: November 2000
  • Laatst online: 06-11-2025
LET OP! dit is geen standaard tpc/ip configuratie... dit is PPTP, waar alles (blijkbaar) net iets anders gaat. De tutorials tonen gelijksoortige dingen.

Bovendien: configuratie 1 werkt! allen config 2 werkt niet (wellicht door die NAT). Ga dus geen fouten zoeken in config 1 alsjeblieft, want daar schiet niemand wat mee op.

Zou iemand alsjeblief in willen gaan op het probleem (situatie 2) in plaats van het werkende voorbeeld (situatie 1)

Localhost, sweet localhost


  • kvdveer
  • Registratie: November 2000
  • Laatst online: 06-11-2025
Op vrijdag 01 februari 2002 12:02 schreef The Lord het volgende:
Zoals jij het wil kan niet met PPTP.

Ongeveer het volgende gebeurt :

- Client encapsulates data-packet in PPTP.
- NAT modificeert IP-source header van het PPTP pakket.
- VPN server :
* krijgt pakket binnen.
* authenticeert pakket.
* gaat PPTP un-encapsulaten.
* bakt een reply en capsulates deze.
* verzend de reply naar het IP adres dat uit de PPTP header is gedistilleerd (dat is dus 10.x.x.x!)

En dat kan niet, want die 10.x.x.x is niet routable vanaf je VPN server.
De pptpd bakt niet zelf het IP-reactie-pakketje, tenzij 'ie raw sockets gebruikt, wat volgens mij niet het geval is.
Uit jou verhaal blijkt (icm bovenstaande gedachte) dat de VPN een verbinding terug maakt. (dat is namelijk het enige moment dat 'ie een ipadres doorgeeft aan de TCP-IP stack, verder wordt het ip-adres in die stack gehandhaafd, er is tenslotte een verbinding.

Kan ik 'm niet zo configureeren dat ie zijn reactie sturen naar de bron van de verbinding (62.x)?
Het is (imo) in het geheel niet zinnig om een reactie te sturen naar een ipadres dat in het datagedeelte zit, aangezien NAT-routing steeds meer voorkomt op INET

Localhost, sweet localhost


  • kvdveer
  • Registratie: November 2000
  • Laatst online: 06-11-2025
Nieuwe testresultaten met dezelfde server (ik ben nu op locatie.
code:
1
2
3
4
5
6
             ???     
            |   LUNA 217.x.x.x
         (VPN + NAT)
            |   INTERN 10.0.0.1
  (deze pc) ------+------ ...
  10.0.0.51

In bovenstaande situatie krijg ik identieke resultaten als ik verbind naar 217.x.x.x en 10.0.0.1, terwijl bij die laatste NAT er niet tussen zit. NAT is dus (blijbaar) niet de dader.

[edit]
Bij mij thuis (testbak) draait GEEN dhcpd, hiero op de router wel, ik zou deze resultaten dus juist omgekeerd verwachten. Heeft het zin om VPN als subnet toe te voegen? en hoe doe ik dat dan?

Localhost, sweet localhost


  • kvdveer
  • Registratie: November 2000
  • Laatst online: 06-11-2025
[dubbelpost]

Localhost, sweet localhost


  • The Lord
  • Registratie: November 1999
  • Laatst online: 20:41
Mijn vorige post was nogal snel getypt en niet bepaald een duidelijke verhandeling van PPTP. Maar goed.... :
De pptpd bakt niet zelf het IP-reactie-pakketje
Dat klopt, de acknowledges worden gewoon door de TCP/IP stack verzorgd. Maar de deamon bakt wel zelf het PPTP-reactie-pakket. En het nare zit hem in het feit dat het source IP adres waarnaar het PPTP-reactie-pakket wordt teruggestuurd wordt gedestilleerd uit de PPP header die in de PPTP pakketten is ge-encapsulated. En dat is dus gebeurd voordat het pakket door NAT werd gehaald. Zoedoende is dit het 10.x.x.x adres....
Kan ik 'm niet zo configureeren dat ie zijn reactie sturen naar de bron van de verbinding (62.x)?
Nee, helaas. Dat kan niet door de opbouw van PPTP. Maar je wil vast oplossingen, dus :

Oplossing 1 (lokaal unencrypted)
WS A -- NAT -- PPTP -- Internet -- PPTP -- WS B

Oplossing 2 (veel te statisch)
WS A - PPTP - sNAT - I-net - sNAT+static mappings - PPTP - WS B

Oplossing 3 (lokaal encrypted)
WS A + IPSec - NAT+L2TP - I-net - NAT+L2TP - WS B + IPSec

Oplossing 4 (gedeeltelijk lokaal encrypted)
WS A + IPSec - NAT+L2TP - I-net - NAT+L2TP+IPsec - WS B

Dat moet het geloof ik zijn, maar de echte netwerkers mogen uitsluitsel geven.

geeft geen inhoudelijke reacties meer


  • kvdveer
  • Registratie: November 2000
  • Laatst online: 06-11-2025
Bedankt voor je oplossingen, maar helaas heb ik geen controle over de NATter, wat volgens mij bij al jou oplossingen vereist is... Bij mij thuis is dat gewoon een linuxbak waar ik lekker aan kan configureren, maar in productieomgeving is dat een gehuurd ADSL modem, waar we niets me mogen. (nee, ook niet tweaken!)

Bovendien zijn er aanwijzingen dat het niet aan het NATten ligt, omdat het ook niet werkt in een NAT-loze omgeving.
(zie boven)

Security is overigens niet echt heel belangrijk... Heavilly encrypted situaties zijn dus ook niet nodig. :+

Localhost, sweet localhost


  • The Lord
  • Registratie: November 1999
  • Laatst online: 20:41
Zo dan? :
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Stage LAN      10.0.0.x
                |
               NAT
                |
            VPN Server
                |
           Luna 217.x.x.x
                |
              I-Net
                |
           Chello 62.x.x.x
                |
     VPN Server + NAT + Dynamic routes
                |
          Thuis LAN 10.1.x.x

De truuk is dus dat je de VPN pas opzet vanaf jou (Linux?) NAT/Proxy/Enzovoorts.

Twee verschillende subnetten lokaal en remote, de routering voor die twee subnetten voer je uit op jouw VPN/NAT/.... server.

Moet kunnen, succes >:)

geeft geen inhoudelijke reacties meer


  • kvdveer
  • Registratie: November 2000
  • Laatst online: 06-11-2025
Lees mijn bovenstaande posts alsjeblieft even!

HET LIGT NIET AAN DIE NAT.

zonder nat heb ik iedentieke problemen!

Localhost, sweet localhost

Pagina: 1