|
OpenBSD Packages and Ports Installation and upgrading of packages and ports on OpenBSD. |
|
Thread Tools | Display Modes |
|
|||
poptop on OpenBSD 4.3
Hello,
I am having issues connecting from my Mac and XP PPTP clients to my poptop server. They try and connect and are dropped right away. I have a feeling my issue has to do with how I am configuring ppp. I am running OpenBSD 4.3 and poptop-1.3.0. ( installed using pkg_add) The OpenBSD box is acting as a firewall/router doing nat with pf. My internal ip address on the OBSD box is 192.168.1.1. I loosely followed the instructions found here: http://blogs.techrepublic.com.com/networking/?p=48 and here: http://koychev.com/Setup-OpenBSD-PP...ver-with-Poptop However, in part 1 on the top link the author states to remove: pseudo-device gre # GRE encapsulation interface Which does not make sense, because PopTop uses gre and when I did remove gre, it gave me the error: (May 16 18:21:40 cerberus pptpd[2412]: PPTPD: failed to allow GRE, errno=42) and would not start pptpd. Therefore, I recompiled my kernel with gre. I am now able to start pptpd, but I am now receiving a new error when I try to connect: CTRL: PTY read or GRE write failed (pty,gre)=(7,6) pptpd[1277]: GRE: read(fd=7,buffer=3c0046a0,len=8196) from PTY failed: status = 0 error= No error In my ppp.log I receive this error: ppp[12874]: Warning: Label ipparam rejected -direct connection: Configuration label not found Here are my config files. /etc/ppp/ppp.conf: loop: set timeout 0 set log phase chat connect lcp ipcp command set device localhostpploop set dial set login set mppe * stateful set ifaddr 192.168.1.2 192.168.1.234-192.168.1.254 255.255.255.255 set server /var/tmp/loop "" 0177 loop-in: set timeout 0 set log phase lcp ipcp command allow mode direct pptp: load loop # Disable unsecured auth disable pap disable chap enable mschapv2 disable deflate pred1 deny deflate pred1 disable ipv6 accept mppe enable proxy accept dns set device !/etc/ppp/secure /etc/ppp/secure: #!/bin/sh exec /usr/sbin/ppp -direct loop-in /etc/pptpd.conf: option /etc/ppp/ppp.conf debug logwtmp localip 192.168.1.2 remoteip 192.168.1.234-254 listen xx.xx.xx.xxx pidfile /var/run/pptpd.pid I can make a successful telnet session to my external IP on port 1723 so it does not look like pf is an issue. However, here is what I am doing in pf.conf. #PPTP pass in quick on $ext_if proto tcp from any to $ext_if port = 1723 modulate state pass in quick on $ext_if proto gre from any to $ext_if keep state pass out quick on $ext_if proto gre from $ext_if to any keep state pass in quick log on tun0 all pass out quick log on tun0 all pass in quick log on tun1 all pass out quick log on tun1 all #End PPTP Any help would be appreciated! Cheers, JD |
|
||||
Quote:
For 3 years 5 months (OpenBSD 3.7 thru OpenBSD 4.2), the poptop port remained unchanged -- poptop 1.1.4b4p1. For 4.3, poptop was updated to 1.3.0, and GRE is automatically enabled at runtime. Return to a GENERIC kernel, and you can eliminate your custom kernel as a point-of-error. Disclaimer: I am not a poptop user, I merely read the log for the port's Makefile. Here is a link: http://www.openbsd.org/cgi-bin/cvswe...optop/Makefile Note: your koychev link is broken. |
|
|||
Quote:
-bash-3.2# tcpdump -eni pflog0 tcpdump: listening on pflog0, link-type PFLOG Thoughts? I will recompile the kernel to the GENERIC to see if that fixes anything. However, I only took out some unnecessary device drivers, so I am not too certain that will fix anything, but who knows. |
|
|||
Quote:
http://openbsd.org/faq/faq5.html#Why ...& we follow this same cultural decision here as well. Installing a kernel with the same version number from a mirror would alleviate any remaining questions as to whether customizing is still contributing unexpected behaviors. If & when you do respond again with new information, please provide the output of the following command: $ sysctl kern.version
|
|
|||
-bash-3.2$ sysctl kern.version
kern.version=OpenBSD 4.3 (GENERIC) #0: Sat May 24 20:54:05 PDT 2008 root@cerberus.underachievement.biz:/usr/src/sys/arch/i386/compile/GENERIC I recompiled the kernel to be GENERIC and I am seeing the same behavior. |
|
|||
Are you using a modified version of GENERIC or the default installed during installation?
|
|
|||
Quote:
I also wanted to point out that the tcpdump is working ok. tcpdump -eni pflog0 tcpdump: listening on pflog0, link-type PFLOG 06:58:14.499988 rule 39/(match) block in on vr0: 128.97.xx.xx.52314 > 76.91.xx.xx.80: [|tcp] (DF) 06:58:41.566078 rule 39/(match) block in on vr0: 128.97.xx.xx.52316 > 76.91.xx.xx.80: [|tcp] (DF) 06:59:02.872598 rule 39/(match) block in on vr0: 128.97.xx.xx.52317 > 76.91.xx.xx.23: [|tcp] (DF) 06:59:20.535997 rule 39/(match) block in on vr0: 128.97.xx.xx.52318 > 76.91.26.1xx.xx: [|tcp] (DF) Therefore, I am pretty sure the issue has to do more with ppp rather than firewall issues. Perhaps something I missed in my config. Lastly, I doubt this matters, but I created extra tun devices. cd /dev sh ./MAKEDEV tun5 sh ./MAKEDEV tun6 ect... |
|
|||
Quote:
I realized that I could have just downloaded the GENERIC kernel from openbsd (which would have been faster), but that was an after thought. I am up at the future in-laws right now, so clear uninterrupted thinking is in short supply. =\ |
|
|||
Try adding a "noipparam" in pptpd.conf.
This link talks more about it, as experienced by one user: http://www.pingle.org/2006/04/11/get...er-freebsd-5-6 |
|
|||
No dice, it is displaying the same error as before, but without the leading ipparam before it.
|
|
|||
I read all through the article that funtaff provided, but I am still seeing the same issues. Does anyone else have any suggestions? I have been looking around quite a bit, but I am somewhat at a loss.
|
|
|||
When I run pptpd in the forground using -f I see the error
plugin: Configuration label not found When I try and connect. From the research that I have done, it suggested that I am missing pptp: in my ppp.conf file. However, I have that section in. I have even tried changing my config files around quite a bit, stripping them of all extra stuff and I am seeing the same errors. If anyone could provide some insight that would be great. I feel like I am just spinning my wheels and nothing is changing. Thanks. |
|
|||
Use pptpd's "-e" option
1. create a little script "/etc/ppp/pppd":
#!/bin/sh /usr/sbin/ppp -direct pptp 2. start pptpd with "-e /etc/ppp/pppd" this seems to solve the coordination problems between pptpd/pppd/ppp |
|
|