RE: Anyone using pptp?
> > Dear Thomas, > > > > > Well - I'm still trying to get pptp to cooperate and set up > > a VPN connection to a Microsoft VPN server. > > > > I'm just wondering - is there _anyone_ out there that has > > met with success using pptp - and, if so, could you share > > your /etc/ppp/ppp.conf settings? > > > http://kjkoster.org/?page=content/adsl.jsp It's specific for my provider, > though. > > Kees Jan > Thanks Kees! I read through your web pages - very nicely done, by the way! But - I'm afraid your /etc/ppp/ppp.conf doesn't work for me. Here's the current issue: The Microsoft VPN server I'm talking to is insisting on an encrypted MPPE connection at the LCP level. That connection requires MSChapV2 (0x81). If I add enable MSChapV2 in /etc/ppp/ppp.conf - then our ppp client requires that the peer (the Microsoft VPN server) authenticate using MSChapV2. But, the Microsoft VPN peer refuses that (it's configured to not use MSChapV2. So - I'm in the situation of both requiring and disallowing MSChapV2. Does anyone know if there is a way in /etc/ppp/ppp.conf to accomplish this? Some people on the Linux lists suggested that the FreeBSD ppp might have a "noauth" option, which meant that the peer didn't have to authenticate itself - but I couldn't find such an option. Any pointers would be appreciated! - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
source MAC address
Hello all, I am implementing mobileIP in user space on freeBSD and was curious about something. In order to do mobileIP IP address assignment, my process on freeBSD has to be able to receive an IP packet and learn the source MAC address that it came from (I am sure that the packet is only going one hop). I have been able to do this using the BPF device, but am concerned about a few things: 1) When using the BPF device, the IP packet still goes to the IP stack, and since I am no longer listening on the UDP port number, a ICMP port unreachable is sent. I guess I could us ip_fw to fix this. 2) When using the BPF device, I am bypassing the IP stack. Therefore, I am losing things like reassembly, IPSEC, etc.. Is there another way to get this info up to an application without using BPF? Likewise, I also want to be able to force IP packets out to a particular MAC address, regardless of the IP destination address of the packet. Once again, I know BPF can do this, but then I have similar concerns to the ones above. For example, what do I set the IP ID field to?? If I accidentally match an ID field that the kernel has used previously, then reassembly could get confused on the end host. thanks a lot, matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: source MAC address
look at the following alternat ways to get data out of the kernel: 1/ ipfw + divert 2/ netgraph (can attach to sockets and interfaces and can provide sockets and interfaces.. mix-n-match) On Thu, 2 May 2002, Matt Impett wrote: > Hello all, > > I am implementing mobileIP in user space on freeBSD and was curious about > something. In order to do mobileIP IP address assignment, my process on > freeBSD has to be able to receive an IP packet and learn the source MAC > address that it came from (I am sure that the packet is only going one hop). > I have been able to do this using the BPF device, but am concerned about a > few things: > 1) When using the BPF device, the IP packet still goes to the IP stack, and > since I am no longer listening on the UDP port number, a ICMP port > unreachable is sent. I guess I could us ip_fw to fix this. > 2) When using the BPF device, I am bypassing the IP stack. Therefore, I am > losing things like reassembly, IPSEC, etc.. > > Is there another way to get this info up to an application without using > BPF? > > Likewise, I also want to be able to force IP packets out to a particular MAC > address, regardless of the IP destination address of the packet. Once > again, I know BPF can do this, but then I have similar concerns to the ones > above. For example, what do I set the IP ID field to?? If I accidentally > match an ID field that the kernel has used previously, then reassembly could > get confused on the end host. > > thanks a lot, > matt > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Anyone using pptp?
Thomas David Rivers writes: > If I add > enable MSChapV2 > in /etc/ppp/ppp.conf - then our ppp client requires that the > peer (the Microsoft VPN server) authenticate using MSChapV2. But, > the Microsoft VPN peer refuses that (it's configured to not use > MSChapV2. Don't you want something like "allow MSChapV2" and "disable MSChapV2" ? -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Anyone using pptp?
> > Thomas David Rivers writes: > > If I add > > enable MSChapV2 > > in /etc/ppp/ppp.conf - then our ppp client requires that the > > peer (the Microsoft VPN server) authenticate using MSChapV2. But, > > the Microsoft VPN peer refuses that (it's configured to not use > > MSChapV2. > > Don't you want something like "allow MSChapV2" and "disable MSChapV2" ? > > -Archie > Something like that... but - that's the default setting. With the default setting, it seems to pass through CHAP (0x80) Authentication. But - then, the MPPE encryption is not allowed - because MPPE compression requires MSChapV2 (0x81) Authentication... and, the VPN server doesn't authenticate that way. I notice there is a line in the ppp man page: For now, ppp can only get encryption keys from CHAP 81 authentication. But - the (Microsoft Win2000) VPN server I'm trying to talk do doesn't allow CHAP 81 authentication, but wants to use MPPE... - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Anyone using pptp?
Thomas David Rivers writes: > > > enable MSChapV2 > > > in /etc/ppp/ppp.conf - then our ppp client requires that the > > > peer (the Microsoft VPN server) authenticate using MSChapV2. But, > > > the Microsoft VPN peer refuses that (it's configured to not use > > > MSChapV2. > > > > Don't you want something like "allow MSChapV2" and "disable MSChapV2" ? > > Something like that... but - that's the default setting. With the > default setting, it seems to pass through CHAP (0x80) Authentication. > > But - then, the MPPE encryption is not allowed - because MPPE > compression requires MSChapV2 (0x81) Authentication... and, the > VPN server doesn't authenticate that way. > > I notice there is a line in the ppp man page: > > For now, ppp can only get encryption keys from CHAP 81 > authentication. > > But - the (Microsoft Win2000) VPN server I'm trying to talk do doesn't > allow CHAP 81 authentication, but wants to use MPPE... In that case you need to use mpd I guess. -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Anyone using pptp?
Archie Cobbs <[EMAIL PROTECTED]> wrote: > > Thomas David Rivers writes: > > > > enable MSChapV2 > > > > in /etc/ppp/ppp.conf - then our ppp client requires that the > > > > peer (the Microsoft VPN server) authenticate using MSChapV2. But, > > > > the Microsoft VPN peer refuses that (it's configured to not use > > > > MSChapV2. > > > > > > Don't you want something like "allow MSChapV2" and "disable MSChapV2" ? > > > > Something like that... but - that's the default setting. With the > > default setting, it seems to pass through CHAP (0x80) Authentication. > > > > But - then, the MPPE encryption is not allowed - because MPPE > > compression requires MSChapV2 (0x81) Authentication... and, the > > VPN server doesn't authenticate that way. > > > > I notice there is a line in the ppp man page: > > > > For now, ppp can only get encryption keys from CHAP 81 > > authentication. > > > > But - the (Microsoft Win2000) VPN server I'm trying to talk do doesn't > > allow CHAP 81 authentication, but wants to use MPPE... > > In that case you need to use mpd I guess. > > -Archie > Yes - after some other investigation - I arrived at the same idea. mpd fails as well... with something very similar... it seems to send a CCP configuration request and simply gets no answer back from the Microsoft server. From the VPN log (you can see toward the bottom that both IPCP and CCP complain that parameter negotiation failed): [vpn] LCP: authorization successful [vpn] LCP: phase shift AUTHENTICATE --> NETWORK [vpn] up: 1 link, total bandwidth 64000 bps [vpn] IPCP: Up event [vpn] IPCP: state change Starting --> Req-Sent [vpn] IPCP: SendConfigReq #1 IPADDR 192.168.1.1 COMPPROTO VJCOMP, 16 comp. channels, no comp-cid [vpn] CCP: Open event [vpn] CCP: state change Initial --> Starting [vpn] CCP: LayerStart [vpn] CCP: Up event [vpn] CCP: state change Starting --> Req-Sent [vpn] CCP: SendConfigReq #1 MPPC 0x0160: MPPE, 40 bit, 128 bit, stateless [vpn] IPCP: SendConfigReq #2 IPADDR 192.168.1.1 COMPPROTO VJCOMP, 16 comp. channels, no comp-cid [vpn] CCP: SendConfigReq #2 MPPC 0x0160: MPPE, 40 bit, 128 bit, stateless [vpn] IPCP: SendConfigReq #3 IPADDR 192.168.1.1 COMPPROTO VJCOMP, 16 comp. channels, no comp-cid [vpn] CCP: SendConfigReq #3 MPPC 0x0160: MPPE, 40 bit, 128 bit, stateless [vpn] IPCP: SendConfigReq #4 IPADDR 192.168.1.1 COMPPROTO VJCOMP, 16 comp. channels, no comp-cid [vpn] CCP: SendConfigReq #4 MPPC 0x0160: MPPE, 40 bit, 128 bit, stateless [vpn] IPCP: SendConfigReq #5 IPADDR 192.168.1.1 COMPPROTO VJCOMP, 16 comp. channels, no comp-cid [vpn] CCP: SendConfigReq #5 MPPC 0x0160: MPPE, 40 bit, 128 bit, stateless [vpn] IPCP: SendConfigReq #6 IPADDR 192.168.1.1 COMPPROTO VJCOMP, 16 comp. channels, no comp-cid [vpn] CCP: SendConfigReq #6 MPPC 0x0160: MPPE, 40 bit, 128 bit, stateless [vpn] IPCP: SendConfigReq #7 IPADDR 192.168.1.1 COMPPROTO VJCOMP, 16 comp. channels, no comp-cid [vpn] CCP: SendConfigReq #7 MPPC 0x0160: MPPE, 40 bit, 128 bit, stateless [vpn] IPCP: SendConfigReq #8 IPADDR 192.168.1.1 COMPPROTO VJCOMP, 16 comp. channels, no comp-cid [vpn] CCP: SendConfigReq #8 MPPC 0x0160: MPPE, 40 bit, 128 bit, stateless [vpn] IPCP: SendConfigReq #9 IPADDR 192.168.1.1 COMPPROTO VJCOMP, 16 comp. channels, no comp-cid [vpn] CCP: SendConfigReq #9 MPPC 0x0160: MPPE, 40 bit, 128 bit, stateless [vpn] IPCP: SendConfigReq #10 IPADDR 192.168.1.1 COMPPROTO VJCOMP, 16 comp. channels, no comp-cid [vpn] CCP: SendConfigReq #10 MPPC 0x0160: MPPE, 40 bit, 128 bit, stateless [vpn] IPCP: state change Req-Sent --> Stopped [vpn] IPCP: LayerFinish [vpn] IPCP: parameter negotiation failed [vpn] IPCP: LayerFinish [vpn] CCP: state change Req-Sent --> Stopped [vpn] CCP: LayerFinish [vpn] CCP: parameter negotiation failed [vpn] CCP: Close event [vpn] CCP: state change Stopped --> Closed [vpn] CCP: encryption required, but MPPE was not negotiated in both directions [vpn] CCP: failed to negotiate required encryption [vpn] CCP: Close event [vpn] CCP: LayerFinish [vpn] IPCP: failed to negotiate required encryption [vpn] IPCP: LayerFinish [vpn] CCP: LayerFinish [vpn] bundle: CLOSE event in state OPENED [vpn] closing link "vpn"... [vpn] bundle: CLOSE event in state CLOSED [vpn] closing link "vpn"... [vpn] link: CLOSE event [vpn] LCP: Close event [vpn] LCP: state change Opened --> Closing [vpn] LCP: phase shift NETWORK --> TERMINATE [vpn] up: 0 links, total bandwidth 9600 bps [vpn] IPCP: Down event [vpn] IPCP: state change Stopped --> Starting [vpn] IPCP: LayerStart [vpn] CCP: Down event [vpn] CCP: state change Closed --> Initial [vpn] CCP: Close event [vpn] closing link "vpn"... [vpn] LCP: SendTerminateReq #4 [vpn] LCP: LayerDown [vpn] bundle: CLOSE event in state CLOSED [vpn] link: CLOSE event [vpn] LCP: Close event [vpn] bundle: OPEN event in state CLOSED [vpn] opening link "vpn"... [vpn] link: CLOSE event [vpn] LCP:
Re: Anyone using pptp?
[ note: freebsd-hackers being removed from the cc: list ] Thomas David Rivers writes: > mpd fails as well... with something very similar... it seems to > send a CCP configuration request and simply gets no answer > back from the Microsoft server. From the VPN log (you can see > toward the bottom that both IPCP and CCP complain that > parameter negotiation failed): Maybe the server is having trouble acquiring an IP address for you via DHCP? Sometimes this kind of trace results from the server 'freezing up' due to any random error condition such as no DHCP, network access denied, etc. -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Anyone using pptp?
Archie Cobbs wrote: > [ note: freebsd-hackers being removed from the cc: list ] > Thomas David Rivers writes: > > mpd fails as well... with something very similar... it seems to > > send a CCP configuration request and simply gets no answer > > back from the Microsoft server. From the VPN log (you can see > > toward the bottom that both IPCP and CCP complain that > > parameter negotiation failed): > > Maybe the server is having trouble acquiring an IP address > for you via DHCP? Sometimes this kind of trace results from > the server 'freezing up' due to any random error condition > such as no DHCP, network access denied, etc. Actually, I've seen something very similar to this; the Windows stuff actually says "authenticating with server" followed by "authenticating to network". It actually goes through two authentication cycles, for some types of connections. Maybe it's not reauthenticating? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
PHY patch, please test. (fwd)
Poul-Henning is proposing removing some synchronization features of miibus. Can somebody who understands this please check into it? I'm forwarding it here because it was posted to the wrong list. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 --- Forwarded Message Date:Wed, 01 May 2002 11:45:37 +0200 From:Poul-Henning Kamp <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: PHY patch, please test. This patch simplifies the auto-negotiation in the MII/PHY code, but I don't have enough weird ethernet cards to test it out. Please test and if it doesn't work send me dmesg -v output and info on what netcard it breaks. http://phk.freebsd.dk/patch/phy00.patch I hope to commit it this weekend. I am also interested to hear from people using the NetGear 622 or other if_nge based gigabit cards. Thanks in advance! - -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message --- End of Forwarded Message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Anyone using pptp?
Archie Cobbs wrote: > Thomas David Rivers writes: > > If I add > > enable MSChapV2 > > in /etc/ppp/ppp.conf - then our ppp client requires that the > > peer (the Microsoft VPN server) authenticate using MSChapV2. But, > > the Microsoft VPN peer refuses that (it's configured to not use > > MSChapV2. > > Don't you want something like "allow MSChapV2" and "disable MSChapV2" ? The MS PAP/CHAP stuff never made it to RFC because of the protocol layering violations. I think the problem T.D.R. is seeing are a result of not having some covert channel, which is *not* MSChapV2, to get a session key for the VPN session. I guess we need to see a packet trace for a Windows machine being successful, and a FreeBSD machine being unsuccessful, in order to run a side-by-side comparison. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Anyone using pptp?
Terry Lambert <[EMAIL PROTECTED]> wrote: > > Archie Cobbs wrote: > > Thomas David Rivers writes: > > > If I add > > > enable MSChapV2 > > > in /etc/ppp/ppp.conf - then our ppp client requires that the > > > peer (the Microsoft VPN server) authenticate using MSChapV2. But, > > > the Microsoft VPN peer refuses that (it's configured to not use > > > MSChapV2. > > > > Don't you want something like "allow MSChapV2" and "disable MSChapV2" ? > > The MS PAP/CHAP stuff never made it to RFC because of the > protocol layering violations. > > I think the problem T.D.R. is seeing are a result of not > having some covert channel, which is *not* MSChapV2, to get > a session key for the VPN session. > > I guess we need to see a packet trace for a Windows machine > being successful, and a FreeBSD machine being unsuccessful, > in order to run a side-by-side comparison. Believe me! I've asked for such a thingy... apparently, the "magic software" needed to do a packet trace on Windows isn't installed on the server. - Dave Rivers - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Anyone using pptp?
Thomas David Rivers wrote: > > I guess we need to see a packet trace for a Windows machine > > being successful, and a FreeBSD machine being unsuccessful, > > in order to run a side-by-side comparison. > > Believe me! I've asked for such a thingy... apparently, > the "magic software" needed to do a packet trace on Windows > isn't installed on the server. You should be able to do it at the client (your) end, and they should be able to do it with some pain on their end by setting up a "monitoring port" on the switch for the server traffic, and doing a dump on whatever box they have available that can do dumps. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: source MAC address
On Thu, May 02, 2002 at 11:26:16AM -0400, Matt Impett wrote: > Hello all, > > I am implementing mobileIP in user space on freeBSD and was curious about > something. In order to do mobileIP IP address assignment, my process on > freeBSD has to be able to receive an IP packet and learn the source MAC > address that it came from (I am sure that the packet is only going one hop). > I have been able to do this using the BPF device, but am concerned about a > few things: > 1) When using the BPF device, the IP packet still goes to the IP stack, and > since I am no longer listening on the UDP port number, a ICMP port > unreachable is sent. I guess I could us ip_fw to fix this. By the time the system learns its IP address, you can open up a UDP socket and listen there. No need to use bpf(4). No ICMP unreachable sent. In the initial phases, before the system learns its IP, this is when you need to use bpf(4), but the system won't generate ICMP unreachable since the packet doesn't go to the IP stack. > 2) When using the BPF device, I am bypassing the IP stack. Therefore, I am > losing things like reassembly, IPSEC, etc.. Make sure you don't need those things in the bootstrapping phases. ;) > Is there another way to get this info up to an application without using > BPF? Even the dhclient(8) uses bpf(4) now. I seems to be the best tool for the job. > Likewise, I also want to be able to force IP packets out to a particular MAC > address, regardless of the IP destination address of the packet. Once > again, I know BPF can do this, but then I have similar concerns to the ones > above. For example, what do I set the IP ID field to?? IP ID? Set the DF bit, then the IP ID field won't ever be used. Set it to zero or the constant value of your choice. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
