From: Karl K. <la...@va...> - 2004-02-27 15:02:39
|
A week ago I wrote in with a link to some documentation that I am writing up, a how-to on setting up a PPTP server with Devil-Linux... Well, we had a box fail (a quiet fan go t even quieter... it died and the HD followed it shortly), and I needed my new DL box to fill in, but a message on the list seemed to indicate that DL 1.0.x could not serve as both a router (with firewall) and a PPTP server, but that 1.1.x could. I can now report without a doubt that it does work with 1.1.x. So a download, and a bit of configuring later (10 minutes.. I love DL), I have a 1.1.x server up and running. I will be writing up my new instructions this weekend, but I have a couple of questions: 1: Does anyone have any comments on the documentation I submitted before. I see in the server logs that a number of people viewed it, but I only got one comment about it from Heiko. Feedback would be good. If I can get feedback I will probably start working a bit more on documentation. I will be working on it again this weekend, and it would be good to have feedback. 2: What is the expected timeline on the 1.1 tree? Can I get a few config files changed. If this can happen, then I could shorten up my written directions. Specifically I would like changes made to the generic files at: /ppp/pptpd.conf, /etc/init.d/firewall.rules: /ppp/pptpd.conf: the line: #option /etc/ppp/options.pptpd should loose the 'd' and the '#' to become: option /etc/ppp/options.pptp and the line: #bcrelay eth1 should become: bcrelay eth1 People will still have to edit this file to put in the proper addresses, but having these lines would reduce the directions required, and would not affect people who do not use pptp. /etc/init.d/firewall.rules (using the default 2 card setup) per Friedrihch Lobenstock's email message, I added the following lines: ${MODPROBE} ip_conntrack_proto_gre ${MODPROBE} ip_conntrack_pptp ${MODPROBE} ip_nat_pptp ${MODPROBE} ip_nat_proto_gre and then I added the rules: ${IPTABLES} -A INPUT -p 47 -j ACCEPT ${IPTABLES} -A OUTPUT -p 47 -j ACCEPT ${IPTABLES} -A INPUT -p tcp --dport 1723 -i ${OUT_DEV} -j ACCEPT ${IPTABLES} -A INPUT -s 128.1.1.0/24 -d 128.1.1.0/24 -j ACCEPT ${IPTABLES} -A FORWARD -s 128.1.1.0/24 -d 128.1.1.0/24 -j ACCEPT The last two lines I am a bit unsure what exactly they do (one or both are required... but they could probably be better written), and they do need to track with your inside IP address range. Anyone have a suggestion on how to do that automatically? And is there a mechanism already setup to punch holes in the firewall rules for specific services? Could this be wrapped in an if clause testing if pptp is turned on? 3. I was just musing, and thought that since all of the config files wind up being zipped up into one file it would be possible to make a config-o-matic in PHP that you could make a number of configuration choices and it could make up a zip file for instant download, and moving onto a floppy/usb disk. This could make getting started with DL one step easier. Anyone have any thoughts? Karl Kuehn la...@so... |
From: Brian T. <br...@tr...> - 2004-02-27 18:23:38
|
> A week ago I wrote in with a link to some documentation that > I am writing > up, a how-to on setting up a PPTP server with Devil-Linux... > Well, we had a > box fail (a quiet fan go t even quieter... it died and the HD > followed it > shortly), and I needed my new DL box to fill in, but a > message on the list > seemed to indicate that DL 1.0.x could not serve as both a > router (with > firewall) and a PPTP server, but that 1.1.x could. I can now > report without > a doubt that it does work with 1.1.x. > I have a pptp server running on 1.0.4 just fine. 1.0.3 did not have the proper ms-chapv2 patches in the kernel for the best Security. 1.0.4 added them. Also, the conntract_nat_pptp or whatever is not in there, so you cannot use that to allow related connections into the firewall box. You instead have to allow GRE packets to enter. I don't know what if any security problems there may be with allowing that, but it works fine once you do. I have it set up to only allow mschapv2 with 128 bit encription. |
From: Karl K. <la...@so...> - 2004-02-27 19:18:36
|
Any chance I could get you to send me a copy of a couple of files from your box? I would like to tweak my how-to so that everything runs with a firewall, but I have moved on to 1.1.x with my main server (and don't have many intel boxes hanging around), and so I am worried about everything being correct. If you would send me a copy of: /etc/ppp/options.pptp (or pptpd depending on what you decided to change) /etc/init.d/firewall.rules I am going to try and work on this over the weekend, so it would be nice to be able to compare things. If you want, you are free to scrub the files for IP addresses, etc. And my examples will not use your addresses. Thanks! Karl Kuehn la...@so... On Feb 27, 2004, at 1:13 PM, Brian Treadway wrote: > I have a pptp server running on 1.0.4 just fine. 1.0.3 did not have the > proper ms-chapv2 patches in the kernel for the best > Security. 1.0.4 added them. Also, the conntract_nat_pptp or whatever > is not > in there, so you cannot use that to allow related connections into the > firewall box. You instead have to allow GRE packets to enter. I don't > know > what if any security problems there may be with allowing that, but it > works > fine once you do. I have it set up to only allow mschapv2 with 128 bit > encription. |
From: Heiko Z. <he...@zu...> - 2004-02-28 15:52:16
|
Karl Kuehn wrote: [...] > /ppp/pptpd.conf: > the line: > #option /etc/ppp/options.pptpd > should loose the 'd' and the '#' to become: > option /etc/ppp/options.pptp DONE > and the line: > #bcrelay eth1 > should become: > bcrelay eth1 I'm not sure if we really should change this line, because I requires some thinking (setting the correct interface) on the side of the administrtor. > People will still have to edit this file to put in the proper addresses, > but having these lines would reduce the directions required, and would > not affect people who do not use pptp. > /etc/init.d/firewall.rules (using the default 2 card setup) > per Friedrihch Lobenstock's email message, I added the following lines: > ${MODPROBE} ip_conntrack_proto_gre > ${MODPROBE} ip_conntrack_pptp > ${MODPROBE} ip_nat_pptp > ${MODPROBE} ip_nat_proto_gre > and then I added the rules: > ${IPTABLES} -A INPUT -p 47 -j ACCEPT > ${IPTABLES} -A OUTPUT -p 47 -j ACCEPT > ${IPTABLES} -A INPUT -p tcp --dport 1723 -i ${OUT_DEV} -j ACCEPT > ${IPTABLES} -A INPUT -s 128.1.1.0/24 -d 128.1.1.0/24 -j ACCEPT > ${IPTABLES} -A FORWARD -s 128.1.1.0/24 -d 128.1.1.0/24 -j ACCEPT Changes to the firewall scripts is the decision of Bruce, he's the master of it. > The last two lines I am a bit unsure what exactly they do (one or both > are required... but they could probably be better written), and they do > need to track with your inside IP address range. Anyone have a > suggestion on how to do that automatically? And is there a mechanism > already setup to punch holes in the firewall rules for specific > services? Could this be wrapped in an if clause testing if pptp is > turned on? > 3. I was just musing, and thought that since all of the config files > wind up being zipped up into one file it would be possible to make a > config-o-matic in PHP that you could make a number of configuration > choices and it could make up a zip file for instant download, and moving > onto a floppy/usb disk. This could make getting started with DL one step > easier. Anyone have any thoughts? I would actually prefer the use of Webmin, all kinds of modules are available already. We would just need to add our own. Writing something new in PHP sounds nice, but is too much work. Heiko |
From: Heiko Z. <he...@zu...> - 2004-02-28 16:02:18
|
My english sucks this morning... ... and no, I didn't drink (much) yesterday. Heiko |
From: Karl K. <la...@so...> - 2004-02-28 16:41:54
|
Aso.. denn schreibt einfach auf Deutsch... Karl Kuehn la...@so... PS.. meine schlechte Deutsch hat gar nichts mit Bier zum tun... Sondern weil ich eine ami bin... On Feb 28, 2004, at 10:49 AM, Heiko Zuerker wrote: > My english sucks this morning... > ... and no, I didn't drink (much) yesterday. > > Heiko |
From: Heiko Z. <he...@zu...> - 2004-02-28 16:57:20
|
Karl Kuehn wrote: > Aso.. denn schreibt einfach auf Deutsch... > > Karl Kuehn > la...@so... > > PS.. meine schlechte Deutsch hat gar nichts mit Bier zum tun... Sondern > weil ich eine ami bin... What's wrong with that world? Americans go to Germany and the Germans (like me) go to the U.S. ... It was just a little early, my english is usually getting better later in the day (and the more I drink. ;-) ). Heiko |
From: Bruce S. <bw...@ar...> - 2004-02-28 18:05:04
|
> > People will still have to edit this file to put in the proper addresses, > > but having these lines would reduce the directions required, and would > > not affect people who do not use pptp. > > /etc/init.d/firewall.rules (using the default 2 card setup) > > per Friedrihch Lobenstock's email message, I added the following lines: > > ${MODPROBE} ip_conntrack_proto_gre > > ${MODPROBE} ip_conntrack_pptp > > ${MODPROBE} ip_nat_pptp > > ${MODPROBE} ip_nat_proto_gre > > and then I added the rules: > > ${IPTABLES} -A INPUT -p 47 -j ACCEPT > > ${IPTABLES} -A OUTPUT -p 47 -j ACCEPT > > ${IPTABLES} -A INPUT -p tcp --dport 1723 -i ${OUT_DEV} -j ACCEPT > > ${IPTABLES} -A INPUT -s 128.1.1.0/24 -d 128.1.1.0/24 -j ACCEPT > > ${IPTABLES} -A FORWARD -s 128.1.1.0/24 -d 128.1.1.0/24 -j ACCEPT > > Changes to the firewall scripts is the decision of Bruce, he's the > master of it. I'm sorry, I haven't really been paying attention to this thread, since I've never used PPTP. Can you bring me up to speed on what you're suggesting we change in the firewall script, and the purpose? TIA! - BS |
From: Randolph W. <as...@rw...> - 2004-02-28 23:49:05
|
I recently needed to set up a firewall in a hurry, and while I hadn't ever tried DL, it seemed like a great idea. My hardware was a new no-name motherboard w/ amd 1600 cpu, 512mb of ram, cd-rom, no hd, two Hawking nics, and one on-board SIS nic. I repeatedly experienced "spurious interrupt 7" messages, failed boots, and system crashes after it was booted and running a while. I tried every setting I could think of, new download and burn of dl, new cd-rom drive, etc. to no avail. I then added a hard drive, installed SUSE 9.0, and configured it. The system has been running like a champ with this setup. Absolutely 0 problems during install, and 48 hours (so far) of operation. Very puzzling. Time pressures prohibit me playing around on this particular installation - so I'll let sleeping dogs lie. BUT - I love the concept of DL, and I hope to try it again soon - has anyone had a similar experience, or any insight for me? I hope that next time things will go a little more smoothly. TIA |
From: Friedrich L. <fl...@fl...> - 2004-02-29 00:19:43
|
Randolph Wilson wrote on 29.02.2004 00:37 MET: > I recently needed to set up a firewall in a hurry, and while I hadn't > ever tried DL, it seemed like a great idea. > > My hardware was a new no-name motherboard w/ amd 1600 cpu, 512mb of ram, > cd-rom, no hd, two Hawking nics, and one on-board SIS nic. > > I repeatedly experienced "spurious interrupt 7" messages, Those messages tell you that there was lost interrupt. Quite usual for me to see one or two of those messages during boot up BUT not more than that or later. > failed boots, and system crashes after it was booted and running a while. Any more details on that? Otherwise we can't really say anything. > I tried every setting I could think of, new download and burn of dl, new > cd-rom drive, etc. to no avail. > I then added a hard drive, installed SUSE 9.0, and configured it. The > system has been running like a champ with this setup. > Absolutely 0 problems during install, and 48 hours (so far) of operation. But you might want to compare the SuSE 9.0 system to the DL system eg. driver versions, "cat /proc/pci", "lspci -v", .... to see if you can spot something that's different. Might it be the SiS Chip you seem to have on this board? What if you increase the CAS and RAS select times via the boards bios to their maximum, reduce the speed of the CPU to the possible minimun. Does that make any difference > Very puzzling. Time pressures prohibit me playing around on this > particular installation - so I'll let sleeping dogs lie. > BUT - I love the concept of DL, and I hope to try it again soon - has > anyone had a similar experience, or any insight for me? I can think of a problem with your chipset. Try my tips about the bios settings. I had something similar where slowing down the system to the max. helped. > I hope that next time things will go a little more smoothly. Have you tried the latest development version 1.1.x instead of the stable 1.0.x? Get a DL 1.1.x from one of our mirrors: ftp://ftp.tugraz.at/mirror/devil-linux/devel/testing/ ftp://xenia.sote.hu/pub/mirrors/devil-linux/devel/testing/ ftp://ftp.univ-lille1.fr/pub/os/linux/distributions/devil-linux/devel/testing/ ftp://ftp.devil-linux.org/pub/devel/testing/ PS: Please DON'T reply to a mail on the list to start a new thread. Apparently you've replied to the mail "Re: [Devil-Linux-discuss] Firewall stuff - was: PPTP Server on 1.1.x musings". Next time copy the mailaddress and start a new mail. THX! -- MfG / Regards Friedrich Lobenstock ____________________________________________________________________ Friedrich Lobenstock Linux Services Lobenstock URL: http://www.lsl.at/ Email: fl...@fl... ____________________________________________________________________ |
From: Randolph W. <as...@rw...> - 2004-02-29 02:43:38
|
>> I repeatedly experienced "spurious interrupt 7" messages, > > Those messages tell you that there was lost interrupt. Quite usual for > me to see one or two of those messages during boot up BUT not more > than that During boot, but sometimes more than a few.... >> failed boots, and system crashes after it was booted and running a >> while. > > Any more details on that? Otherwise we can't really say anything. Not much to tell - it just locked up at no particular time or place - sometimes during boot, sometimes after running for an hour or two. I turned off everything on the mb I could, including the sis nic, serial and parallel ports, tried various modes on the ide interface, etc. Didn't try playing with timing on anything, but it was all set up plain vanilla - no overclocking or anything strange. > > But you might want to compare the SuSE 9.0 system to the DL system > eg. driver versions, "cat /proc/pci", "lspci -v", .... > to see if you can spot something that's different. Yes - these are the kind of suggestions I was looking for...thanks. I will try this next weekend when I can take the system down for a bit. > PS: Please DON'T reply to a mail on the list to start a new oops, sorry. thanks. |
From: Friedrich L. <fl...@fl...> - 2004-02-29 04:05:25
|
Randolph Wilson wrote on 29.02.2004 03:32 MET: >> Any more details on that? Otherwise we can't really say anything. > > Not much to tell - it just locked up at no particular time or place - > sometimes during boot, sometimes after running for an hour or two. I > turned off everything on the mb I could, including the sis nic, serial > and parallel ports, tried various modes on the ide interface, etc. > Didn't try playing with timing on anything, but it was all set up plain > vanilla - no overclocking or anything strange. You definitely have to try to change the memory and cpu timing, ide and all the peripheral stuff will not really help. Increase all memory timing parameters to the max and minimize all cpu timing parameters. I can only guess that there is some kind of hardware problem/miss-match. If you've got troubles running Linux it's 95% the hardware or the motherboard drivers I would say from experience. -- MfG / Regards Friedrich Lobenstock ____________________________________________________________________ Friedrich Lobenstock Linux Services Lobenstock URL: http://www.lsl.at/ Email: fl...@fl... ____________________________________________________________________ |
From: Tim T. <t....@co...> - 2004-02-29 05:50:41
|
Friedrich Lobenstock wrote: > Randolph Wilson wrote on 29.02.2004 03:32 MET: > >>> Any more details on that? Otherwise we can't really say anything. >> >> >> Not much to tell - it just locked up at no particular time or place - >> sometimes during boot, sometimes after running for an hour or two. I >> turned off everything on the mb I could, including the sis nic, >> serial and parallel ports, tried various modes on the ide interface, >> etc. Didn't try playing with timing on anything, but it was all set >> up plain vanilla - no overclocking or anything strange. > > > You definitely have to try to change the memory and cpu timing, ide > and all the peripheral stuff will not really help. Increase all memory > timing parameters to the max and minimize all cpu timing parameters. > > I can only guess that there is some kind of hardware > problem/miss-match. If you've got troubles running Linux it's 95% the > hardware or the motherboard drivers I would say from experience. I have had problems with AMD chips and both a Via and nForce2 motherboard. There is a feature called "CPU Disconnect" that is used to save power when idle. But it creates a lot of problems which usually appear as spurious interrupts, it has something to due with read latency. In anycase turning it off solved my problems. The Via mothterboard has a BIOS option to shut it off, but the nForce2 one didn't. I found a package called linux "athcool" which can disable it (or enable with the aim or reducing power usage by turning it on hence the name) which is the only way I could get that system stable under linux. There were some kernel hacks to work around it too (adding a time delay before reading the PIT) but I didn't try them. Maybe not your problem but worth a shot. FYI, I couldn't get the source to compile under DL so I just used the binary. Tim |
From: Heiko Z. <he...@zu...> - 2004-02-29 15:27:51
|
Randolph Wilson wrote: >>> I repeatedly experienced "spurious interrupt 7" messages, >> >> >> Those messages tell you that there was lost interrupt. Quite usual for >> me to see one or two of those messages during boot up BUT not more >> than that > > > During boot, but sometimes more than a few.... > >>> failed boots, and system crashes after it was booted and running a >>> while. >> >> >> Any more details on that? Otherwise we can't really say anything. > > > Not much to tell - it just locked up at no particular time or place - > sometimes during boot, sometimes after running for an hour or two. I > turned off everything on the mb I could, including the sis nic, serial > and parallel ports, tried various modes on the ide interface, etc. > Didn't try playing with timing on anything, but it was all set up plain > vanilla - no overclocking or anything strange. > >> >> But you might want to compare the SuSE 9.0 system to the DL system >> eg. driver versions, "cat /proc/pci", "lspci -v", .... >> to see if you can spot something that's different. > > > Yes - these are the kind of suggestions I was looking for...thanks. I > will try this next weekend when I can take the system down for a bit. Trying the 1.1.x version is a very good idea, too. The latest version uses Kernel 2.4.25 which has a lot of bug fixes. Heiko |
From: Karl K. <la...@so...> - 2004-02-28 23:04:59
|
I would like to get PPTP Server closer to being an out-of-the box thing for Devil-Linux, mostly since I am new to the list and picked up DL to exactly that. On the firewall side of things a few things are needed, and I am hoping that you will help me work out exactly what they are, and see if it would be a good idea to move them into the default firewall rules. PPTP needs a single tcp port open (1723), and needs to talk through protocol 47 (GRE). I am hoping that I can convince you to add a few lines to do this to the default firewall rules (the two, and possibly 3 card rules), if it could be wrapped with an 'if' statement to only activate if pptp is turned on for init.d, that would be the best of all worlds. I am a little unsure if the ip_nat_ppp module is actually needed, but it is a part of 1.1.x (and possibly in 1.0.4). It sounds like the conntrack modules could come in handy, but I don't think my example bellow actually uses them. A quick google leads me to believe that this might be better: iptables -A FORWARD --protocol gre --match state --state RELATED,ESTABLISHED --jump ACCEPT but this might be for a gre pass-through (not what I am looking for). The nat lines might also be for more of that. It would be a good idea to have in the firewall, but is not what I am looking for on this round. I am also a bit of a newbie with iptables, so I think I might have some extra lines on the rules lines (especially the last two). Any chance you would take a look at them and possibly move them into the main-stream for 1.1.x? On Feb 28, 2004, at 12:53 PM, Bruce Smith wrote: >>> ${MODPROBE} ip_conntrack_proto_gre >>> ${MODPROBE} ip_conntrack_pptp >>> ${MODPROBE} ip_nat_pptp >>> ${MODPROBE} ip_nat_proto_gre >>> and then I added the rules: >>> ${IPTABLES} -A INPUT -p 47 -j ACCEPT >>> ${IPTABLES} -A OUTPUT -p 47 -j ACCEPT >>> ${IPTABLES} -A INPUT -p tcp --dport 1723 -i ${OUT_DEV} -j ACCEPT >>> ${IPTABLES} -A INPUT -s 128.1.1.0/24 -d 128.1.1.0/24 -j ACCEPT >>> ${IPTABLES} -A FORWARD -s 128.1.1.0/24 -d 128.1.1.0/24 -j ACCEPT >> >> Changes to the firewall scripts is the decision of Bruce, he's the >> master of it. > > I'm sorry, I haven't really been paying attention to this thread, since > I've never used PPTP. Can you bring me up to speed on what you're > suggesting we change in the firewall script, and the purpose? TIA! |
From: Bruce S. <bw...@ar...> - 2004-02-29 13:37:26
|
> I would like to get PPTP Server closer to being an out-of-the box > thing for Devil-Linux, mostly since I am new to the list and picked up > DL to exactly that. On the firewall side of things a few things are > needed, and I am hoping that you will help me work out exactly what > they are, and see if it would be a good idea to move them into the > default firewall rules. I can try, but as I said before, I've never used PPTP client or server, so you'll have to do the testing to make sure it works. > PPTP needs a single tcp port open (1723), and needs to talk through > protocol 47 (GRE). I am hoping that I can convince you to add a few > lines to do this to the default firewall rules (the two, and possibly 3 > card rules), if it could be wrapped with an 'if' statement to only > activate if pptp is turned on for init.d, that would be the best of all > worlds. It will definitely have to be wrapped, or commented out by default. I don't want those rules in my firewall, and I don't think other non-PPTP users want the rules either. > I am a little unsure if the ip_nat_ppp module is actually needed, but > it is a part of 1.1.x (and possibly in 1.0.4). It sounds like the > conntrack modules could come in handy, but I don't think my example > bellow actually uses them. A quick google leads me to believe that this > might be better: > > iptables -A FORWARD --protocol gre --match state --state > RELATED,ESTABLISHED --jump ACCEPT > > but this might be for a gre pass-through (not what I am looking for). > The nat lines might also be for more of that. It would be a good idea > to have in the firewall, but is not what I am looking for on this > round. You're saying that works for a PPTP client, but not a server? Can other PPTP client users verify if that is required to get PPTP working? Or does the normal (already included) ESTABLISHED,RELATED line cover GRE? Is there any easy way to tell if the client is configured to run on DL? (variable in /etc/sysconfig/config or something) > I am also a bit of a newbie with iptables, so I think I might have > some extra lines on the rules lines (especially the last two). Any > chance you would take a look at them and possibly move them into the > main-stream for 1.1.x? Is the list below what you're proposing we add? Or has it changed? > >>> ${MODPROBE} ip_conntrack_proto_gre > >>> ${MODPROBE} ip_conntrack_pptp > >>> ${MODPROBE} ip_nat_pptp > >>> ${MODPROBE} ip_nat_proto_gre > >>> and then I added the rules: > >>> ${IPTABLES} -A INPUT -p 47 -j ACCEPT > >>> ${IPTABLES} -A OUTPUT -p 47 -j ACCEPT > >>> ${IPTABLES} -A INPUT -p tcp --dport 1723 -i ${OUT_DEV} -j ACCEPT > >>> ${IPTABLES} -A INPUT -s 128.1.1.0/24 -d 128.1.1.0/24 -j ACCEPT > >>> ${IPTABLES} -A FORWARD -s 128.1.1.0/24 -d 128.1.1.0/24 -j ACCEPT What's the 128.1.1.0 numbers? We obviously can't hard code them into the firewall scripts. Can you replace them with the interfaces instead? - BS |