Post #57,954
10/20/02 12:19:37 PM
|
Too many choices
There are a number of ways PPPoE has been implemented on Linux and every distro has managned to come up with it's own set of wrappers to make things "easier". Net result is that it is very hard to come up with a Howto that helps everyone.
Debian uses two wrapper scripts to control PPP based connections: pon and poff. These scripts use configuration files from the /etc/ppp/peers directory. Two files are provided by Debian, one for dial-up (provider), one for DSL (dsl-provider). The config files contain some useful comments.
About the only thing you must change in the dsl-provider file is the "user" entry. This entry can be case sensitive and is usually of the form yourID@ISPname. (The ISP name is not necessarly the domain name). Make sure that exactly one of the "pty /usr/bin/pppoe" lines is uncommented.
Next, add the same entry to the /etc/ppp/pap-secrets file with the password:
yourID@ISPname * password
That should be enough to get going in most situations. Try "pon dsl-provider" and see what happens.
There are two main problems that I have run in to. One, specific to Debian's Firestarter firewall script, is that the script isn't restarted when the connection is established and you won't get anywhere. If you're using this one, restart it by hand immediately after the pon call. (And not getting any errors here is a quick indication that the connection is up and running properly.)
The second is related to the max. packet size and is regulated by the -m parameter to pppoe. I have no problem with -m 1452, but if you experience slow connections and lots of time-outs, try lowering the number in dsl-provider.
|
Post #57,975
10/20/02 5:02:22 PM
|
Things are beginning to come together...
... and I'd like to thank all of you for your help.\r\n\r\nAt this point, I'm logging in to the provider and getting an IP. However, I'm having a routing problem... I can't ping anyone unless I explicitly set a route for the host first. Furthermore, when I run "netstat -r" or "route -e" the command is hanging up as it tries to fetch the info from the kernel routing table. It just shows the column headers and stops with a blinking cursor... I have to ctrl-c the command to get it back to the prompt.\r\n\r\nThe /etc/ppp/peer/dsl-provider has the defaultroute option set in it... does anyone happen to have any idea what might be going on? One possibility that occurred to me is that I'm currently bringing up eth0 in the /etc/init.d/ppp script just before I fire up "pppd call dsl-provider" with "ifconfig eth0 up" so it has no IP address or anything like that. However, even if I give eth0 a dummy address I still get no output from netstat -r.\r\n\r\nAny ideas what might be happening with that?\r\n\r\nRegards,\r\n\r\nJack
--\r\n-------------------------------------------------------------------\r\n* Jack Troughton jake at consultron.ca *\r\n* [link|http://consultron.ca|http://consultron.ca] [link|irc://irc.ecomstation.ca|irc://irc.ecomstation.ca] *\r\n* Laval Qu\ufffdbec Canada [link|news://news.consultron.ca|news://news.consultron.ca] *\r\n-------------------------------------------------------------------
|
Post #57,996
10/21/02 12:49:01 AM
|
Some hints.
1. A lot of networking tools take a -n to skip reverse name lookup. route -e is probably waiting for a DNS server to respond. Try route -n instead.
2. PPPOE doesn't need an IP address on the ethernet. It just doesn't work that way. And despite [link|http://www.roaringpenguin.com/pppoe/|Roaring Penguin's notes], it's possible to have a working IP segment on the same card as the PPPOE link: the two will never see each other.
Wade.
"Ah. One of the difficult questions."
|
Post #58,024
10/21/02 11:16:35 AM
|
Re: Some hints.
Hi there!\r\n\r\nWell, as it turns out, I've gotten a LOT further along by the time I came across this one.\r\n\r\nThe routing is all set up: put it in ip-up.d IIRC. At any rate, that's all good now. I can put the machine on the Internet and see it, and see the local lan (192.168.0.0/24) with no problems as well. The next stage for me is setting it up to act as a firewall/router/NAT system. IPForward is set to yes... now I need to configure the NAT stuff in a reasonably secure manner. My first plan is just to get it working globally without any firewall rules blocking the usual stuff... just to make sure that people on the net can't use it to masq their ips. After I get the rest of the lan on the net so people can work through the box then I can take my time about getting the rest of it going.\r\n\r\nI was going to use fwctl to do this, but from reading the docs it looks like it does a very bad (ie- none) job of handling an interface with a dynamic IP address... so I'm going to have to set it up explicitly. Can ipchains just use an interface (ie- ppp0) to decide what one end of a rule is? Or do I need to get the address from it and use it to dynamically create the rules? Finally, I also need to be able to log in from a machine on the local lan as root so I can work... the linux box is (hopefully) going into a closet this afternoon. How do I tell the system that it's ok for root to login from the 192.168.0.0 network?\r\n\r\nAny further hints are most welcome!\r\n\r\nThanks again, guys....\r\n\r\nJack\r\n\r\nThe last time I took a serious look at linux was about four or five years ago... things have clearly come a long way since then:)
--\r\n-------------------------------------------------------------------\r\n* Jack Troughton jake at consultron.ca *\r\n* [link|http://consultron.ca|http://consultron.ca] [link|irc://irc.ecomstation.ca|irc://irc.ecomstation.ca] *\r\n* Laval Qu\ufffdbec Canada [link|news://news.consultron.ca|news://news.consultron.ca] *\r\n-------------------------------------------------------------------
|
Post #58,191
10/22/02 1:27:25 AM
|
Yet more hints.
Yes, ipchains can do an interface check. The option is -i and wildcards are +. I setup my rules to check against ppp+ which meant when I got my DSL line, everything worked without modification because it came up as ppp1 :-). If you have a 2.4.x kernel, you could use iptables. They are more flexible and powerful, especially if you have any hairy NATting to do.
Logging in as root is one of those Explicitly Allow configs. Using telnet is probably not a good idea - but if you insist on staying with telnet, you will need to comment out PAM lines that call libsecuretty.so, probably in /etc/pam.d/login but you will have to try it and see. Most people usually log in as an ordinary user and then su to root. This does not require any PAM tinkering.
The alternative is to run SSH with PermitRootLogin set to Yes in /etc/ssh/sshd_config. If you want an SSH client for Windows, I can recommend [link|http://www.chiark.greenend.org.uk/~sgtatham/putty/|PuTTY].
Wade.
"Ah. One of the difficult questions."
|
Post #58,448
10/22/02 3:12:18 PM
|
Re: Yet more hints.
Ok... thanks for letting me know it can be done.
I've been thinking about this since my last (fruitless) round with the box. I'm beginning to think the right way to fire up the firewall is to put it in ip-up.d, so that the firewall gets started right after the ppp interface comes up. I've been trying to use init.d, but it hasn't been working for me yet. Before the ppp interface comes up, the system is in no (well, very little) danger from the private network (there are a potential maximum of five people that will be able to get to it before then... all in the same room). The next issue is what is the right set of rules to set to get NAT going... I was thinking on this this morning and came up with this:
ipchains -P input ACCEPT
ipchains -P forward DENY
ipchains -P output ACCEPT
ipchains -A forward -p 0 -s 192.168.0.0/24 -i ppp0 -j MASQ
The way I have the box configured means that the external interface will always be ppp0.
It also looks to me that I will want to put a rule in before the masq rule that looks something like this:
ipchains -A input -p 0 -s 192.168.0.0/24 -i ppp0 -j DENY
If I read my docs aright, this means that any packets coming in to the ppp0 interface addressed to the internal network will be quietly killed, and shouldn't affect the NAT capabilities. This should avoid issues of people attempting to use this box to masq their own identity... which would mean I'd end up with something like this:
ipchains -P input ACCEPT
ipchains -P forward DENY
ipchains -P output ACCEPT
ipchains -A input -p 0 -s 192.168.0.0/24 -i ppp0 -j DENY
ipchains -A forward -p 0 -s 192.168.0.0/24 -i ppp0 -j MASQ
Est bon, non?
I also know that since the ppp0 interface can change IPs at any time, I need to ensure that the dynamic ip addressing kernel module is loaded.
I'm going to be testing this in a few hours after the office closes up for the day... I've been having a very frustrating time over the last few days because I get into it and then the people there insist on having the inet connection back so they can send a proposal/report/invoice to someone !right away!.
I've pretty much gone to using su to get my root access... it's just a lot easier than trying to figure out how to let me telnet directly in as root from the internal network while avoiding the security issues involved. Thanks for the recc. on an ssh client... I'll have to look into that once I get this machine on the net full time so I can handle admin issues without having to go into the facility to do it.... though at that point I'll probably be using the OS/2 port of the OpenSSH package.
After I get this fired up, the next step for this box will be setting it up to permit email handling... I need to be able to fetch from an external POP machine and put it into local queues which the machines on the private net can get to, also using POP. This will let me copy all mail to the owner, since he wants to be able to see everything that's coming in (and no, I don't want to get into the ethical issues around this thankyouverymuch;). I'm looking at exim (so they can point their clients at the router when sending mail), qpopper, and qmail. Any other recommendations on good packages to use for that would be welcome!
I gotta say... I'm having a lot of fun with this, despite the fact that I could have done this in about three hours with OS/2. The people in question are friends and can't afford the extra five hundred bucks or so to pay for the requisite software, so... I get to learn something new instead, which is always a good thing:)
--\n-------------------------------------------------------------------\n* Jack Troughton jake at consultron.ca *\n* [link|http://consultron.ca|http://consultron.ca] [link|irc://irc.ecomstation.ca|irc://irc.ecomstation.ca] *\n* Laval Qu\ufffdbec Canada [link|news://news.consultron.ca|news://news.consultron.ca] *\n-------------------------------------------------------------------
|
Post #58,701
10/23/02 7:10:16 AM
|
A sample working chain.
#! /bin/sh
# Script for setting up IP Chaining.
# It will work whether or not PPP is actually up.
PATH=/sbin
ANY=0.0.0.0/0
HERE=$ANY
# ^^^ This probably needs to be changed when I get my real addresses.
# ... then again... perhaps not... :-)
# Setup
ipchains -P input DENY
ipchains -P output ACCEPT
ipchains -P forward ACCEPT
ipchains -F
ipchains -X
# PPP input chain
ipchains -N PPP
ipchains -A PPP -s 10.0.0.0/8 -j DENY -l
ipchains -A PPP -d 10.0.0.0/8 -j DENY -l
ipchains -A PPP -s 127.0.0.0/8 -j DENY -l
ipchains -A PPP -p tcp -d $HERE 1024: ! -y -j ACCEPT
ipchains -A PPP -p udp -d $HERE 1024: -j ACCEPT
ipchains -A PPP -p tcp -d $HERE http -j ACCEPT
# ipchains -A PPP -p tcp -d $HERE https -j ACCEPT
# ipchains -A PPP -p tcp -d $HERE ftp -j ACCEPT
ipchains -A PPP -p udp -d $HERE domain -j ACCEPT
ipchains -A PPP -p tcp -d $HERE domain -j ACCEPT
ipchains -A PPP -p tcp -d $HERE smtp -j ACCEPT
ipchains -A PPP -p tcp -d $HERE auth -j REJECT
ipchains -A PPP -p tcp -d $HERE ssh -s $WORK -j ACCEPT
ipchains -A PPP -p tcp -s $ANY ssh -j ACCEPT
ipchains -A PPP -p icmp -s $ANY -j ACCEPT
ipchains -A PPP -p tcp -d $HERE 1024: -s $ANY ftp-data -y -j ACCEPT
ipchains -A PPP -j DENY -l
# input chain
ipchains -A input -i ppp+ -j PPP
ipchains -A input -i eth+ -j ACCEPT
ipchains -A input -i lo -j ACCEPT
ipchains -A input -l
# forwarding
ipchains -A forward -s 10.0.0.0/8 -d 10.0.0.0/8 -j ACCEPT
ipchains -A forward -s 10.0.0.0/8 -i ppp+ -j MASQ
# output
ipchains -A output -i eth+ -j ACCEPT
ipchains -A output -i lo -j ACCEPT
ipchains -A output -i ppp+ -p tcp -d $ANY 137:139 -j DENY
This should get you started. I know I'm being somewhat lazy :-) in not just explaining things. You've got the basic idea, but I think the forward chain needs to default to ACCEPT.
As regards saving them, I would actually suggest you tinker with the rules directly with the ipchains command, and then use /etc/init.d/ipchains save to actually save it. Remember to use chkconfig to make sure the IP chains are loaded at bootup!
As regards email, you probably want a combination of fetchmail and something else. Normally I would recommend [link|http://www.courier-mta.org/|Courier], but I've had trouble with Fetchmail delivering to Courier and no-one associated with either product was interested in investigating it. (This is a bit of a shame as Courier includes an IMAP server, a POP3 server and a webmail server.)
Wade.
"Ah. One of the difficult questions."
|
Post #58,755
10/23/02 9:36:55 AM
|
Re: A sample working chain.
Well, you've got some extra stuff that I don't, for security reasons... but wrt masq, that's exactly what I have. I also tried it with ipchains -P forward ACCEPT, but that didn't make any difference... and I didn't think it would because there are a lot of websites that DO work... it's just a significant number of them that don't. At any rate, it's working now with squid as a proxy, exim as an smtp forwarder, and other protocols like telnet, ftp, pop, nntp, etc working just fine via nat. Personally, I think it's the provider... there have been three NAT engines on that network now (linux, warp, and windows based) and ALL of them do the same thing... which I believe means it's not them doing it at all. I mean, I've used the OS/2 solution (safefire) for well over a year on my home network on adsl, and it's always worked fine... I've seen wingate in action on plenty of networks, and I have little doubt that the linux NAT can handle a little http without breathing hard, but my home provider is not the same outfit as these guys have... and since we're talking about Ma Bell here, it wouldn't surprise me in the least if they were playing games... and esp. considering that it's very clear that have things configured in a similar manner for their smtp server (only the router can connect... masqed packets get denied... not rejected, denied) I'm about 99% sure it's them. I'm not sure what it is about these sites that trip their firewalls... but trip them it seems to do. As soon as there's dynamic content on the site, the jig is up. Either they're doing it on purpose or they have some VERY badly configured proxies in there somewhere...
--\n-------------------------------------------------------------------\n* Jack Troughton jake at consultron.ca *\n* [link|http://consultron.ca|http://consultron.ca] [link|irc://irc.ecomstation.ca|irc://irc.ecomstation.ca] *\n* Laval Qu\ufffdbec Canada [link|news://news.consultron.ca|news://news.consultron.ca] *\n-------------------------------------------------------------------
|
