VPN Problemen

[armageddon_2k1]

Ik heb sinds kort een Macbook Pro met Leopard, die helemaal geupdate is. Ik heb het VPN van thuis al toegevoegd en dat werkt perfect. Geen speciale instellingen nodig. Maar het VPN van mijn werk kan niet connecten met de melding "Cannot negotiate a connection to the remote PPP server". Nu heb ik Bootcamp erop gezet en in Windows XP Pro SP2 dezelfde verbinding toegevoegd en daar werkt ie dus ook niet! Dus ik dacht dat het aan mijn werk lag, maar op mijn oude laptop (XP Pro SP2) werkt het dus wel gewoon. De instellingen kunnen niet simpeler, ik hoef namelijk NIKS te veranderen aan de basisinstellingen. Waar gaat het nou fout dan? Is het de Apple hardware? De ene VPN (thuis) is kwa instellingen identiek aan het werk, maar thuis werkt wel (op OSX en XP Pro), maar werk niet (maar wel op oude laptop).

[benoni]

Moet je misschien je MAC-adres toevoegen op de firewall of server om toegang te krijgen?

[armageddon_2k1]

Nee, dat is niet het geval. Of het moet van de een op de andere dag toegevoegd zijn.
EDIT: Ik kan ook met een willekeurige andere computer me aanmelden.

[ Voor 29% gewijzigd door armageddon_2k1 op 26-01-2008 23:18 ]

[benoni]

Kun je wat zinnigs vinden in de logbestanden?

Open Console.app, 'Logbestanden', kijk bij system.log, /var/log/ppp/ppp.log...


Gezien je edit zal 't wel niet, maar mocht het toch iets met MAC adres zijn, die zou je kunnen proberen om die te spoofen of te vervangen.

Van de wired ethernetverbinding kun je de MAC aanpassen. Voor de zekerheid eerst even de oude uitlezen:

sudo ifconfig en0

En zo kun je de MAC aanpassen:

sudo ifconfig en0 ether 00:mac:van:andere:laptop:hier

Die andere laptop wel afkoppelen van 't netwerk.

[armageddon_2k1]

Uit mijn PPP log komt niks zinnigs:

code:

Sun Jan 27 00:04:36 2008 : PPTP connecting to server 'xxxxxxxx.nl' (xx.xx.xxx.xxx)...
Sun Jan 27 00:04:37 2008 : PPTP connection established.
Sun Jan 27 00:04:37 2008 : Using interface ppp0
Sun Jan 27 00:04:37 2008 : Connect: ppp0 <--> socket[34:17]
Sun Jan 27 00:05:07 2008 : LCP: timeout sending Config-Requests
Sun Jan 27 00:05:07 2008 : Connection terminated.
Sun Jan 27 00:05:07 2008 : PPTP disconnecting...
Sun Jan 27 00:05:07 2008 : PPTP disconnected

Zover was ik ook wel dat er een time-out was. Ik zal eens kijken of ik Mac-adress kan faken.

Hmm, ik zit wel draadloos, dus niet wired.

[ Voor 3% gewijzigd door armageddon_2k1 op 27-01-2008 00:07 ]

[armageddon_2k1]

Nou, ik ben nog geen stap verder. Heb gewoon een willekeurige computer gepakt die nog nooit op dat netwerk heeft gezeten en die komt er (met basisinstellingen) gewoon op....probleem lijkt dus bij de Mac hardware i.c.m. die server te liggen. VPN'en naar een ander VPN lukt wel.
Ook al gekeken of mijn computernaam uitmaaktte, firewall instellingen etc, maar zowel in OSX als XP geen succes.

Heb geen idee nu.

[benoni]

Mijn kennis schiet hierin ook tekort, ik kan nog wel deze achtergrondinfo aandragen (voor wie de link wil leggen met een probleem in Leopard, of een specifieke hardware- of VPN misconfiguratie):

quote: http://pptpclient.sourcef...agnosis.phtml#lcp_timeout

LCP: timeout sending Config-Requests

This is a general error condition that is common to a number of causes. It means that pppd did not receive any LCP configuration requests from the peer, or was unable to agree on LCP parameters. Enable debug logging, try the connection again, and look at messages just prior to this message.
There are many causes for the timeout error:

-> MSCHAP negotiation failed,
-> no GRE packets were received by the client,
-> no GRE packets were transmitted by the server,
-> invalid GRE packets were transmitted by the server,
-> no GRE packets were transmitted by the client.
-> invalid GRE packets were transmitted by the client,

Use tcpdump to check the flow of GRE packets.


-> No GRE received by PPTP Client

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. Prove this using the GRE step in the Fault Tree.


-> No GRE transmitted by PPTP Server

Symptom: GRE packets are emitted by the client, but none are returned by the server, but a tunnel from another machine on the same LAN works fine. The client is behind a NAT gateway with respect to the server.
Diagnosis: PPTP servers will not allow a connection to start from the same IP address that they perceive an active connection on already.

Solution: use alternate PPTP server IP addresses.


-> Invalid GRE packets transmitted by server

Symptom: GRE packets are emitted by the client, GRE packets are returned by the server, but the client makes no sense of them, reporting in the debug log the following asynchronous PPP packet:
rcvd [proto=0x7eff] 7d 23 c0 21 7d 21 7d 21 7d 20 7d 39 7d 22 ...]
Diagnosis: you may be running pppd with the sync option, with a version of the GRE-to-PPP gateway that will recognise sync mode, but the server is returning asynchronous responses.

Solution: turn off sync and try again.


-> No GRE packets transmitted by client

There are two known causes.
Symptom: tcpdump shows no GRE packets are being transmitted by the client. strace shows no write() on the GRE socket by the GRE-to-PPP gateway process.

Diagnosis: you may be running pppd with the sync option, which prevents older version of the GRE-to-PPP gateway from forwarding the packets.

Solution: turn off sync and try again.

Symptom: tcpdump shows no GRE packets are being transmitted by the client. However, strace shows a successful write() on the GRE socket by the GRE-to-PPP gateway process.

Diagnosis: your system may have iptables or ipchains rules that prevent GRE transmission. The GRE-to-PPP gateway sends the packets, but they are dropped by the packet filter before being transferred to the interface.

Solution: check the firewall rules, remove or add replacements, and try again. The following iptables rules may be added to allow GRE through eth0. Change eth0 to the name of the interface through which the PPTP Server is contacted.

iptables --insert OUTPUT 1 \
--source 0.0.0.0/0.0.0.0 \
--destination 0.0.0.0/0.0.0.0 \
--jump ACCEPT --protocol gre \
--out-interface eth0

iptables --insert INPUT 1 \
--source 0.0.0.0/0.0.0.0 \
--destination 0.0.0.0/0.0.0.0 \
--jump ACCEPT --protocol gre \
--in-interface eth0

These rules can be refined further to constrain the GRE traffic.


-> Invalid GRE packets transmitted by client

Symptom: 10 or more GRE packets are emitted by the client in less than a second, and the number of GRE packets is far greater than the number of LCP requests logged.
Diagnosis: you may be running pppd with the pty option and the debug option but not the logfd 2 option. This can cause pppd to send the debug messages out the psuedo-tty file descriptor to the GRE-to-PPP gateway process, and then to the PPTP Server. The server refuses to respond once it sees random traffic like this.

Solution: Add the logfd 2 option.

[Verwijderd]

Hey, ik heb hetzelfde probleem, heb je het al opgelost ?
Ik krijg dezelfde foutmelding in mijn logfile. Ook ik kan vanaf mijn mac gewoon op een XP of Vista VPN connecten maar op mijn SBS2008 niet.

Iemand enig idee ?

[hans_lenze]

Het is oud, maar wie weet.

Link

Ik dacht bij het lezen van dit topic vooral aan een incompatibiliteit icm MS CHAPv2 maar dat blijkt niet het geval. Mac OS moet dit ondersteunen volgens de man pagina van pppd (peer to peer protocol deamon, de achterliggende UNIX tool voor de VPN verbinding).