how-to block ads
2.95 Using Linux for Routing
A regular modem such as the Speedstream 5100 will also work with FreeBSD's ppp client to route all the static IPs. You actually have 6 IPs available for use. One for the router itself (the FreeBSD box) and the other 5 for other machines. The ppp setup described here works fine: »www.freebsd.org/doc/en_US.ISO885···poe.html
See this forum thread for more information.
trader22 contributed to this entry.
I had a setup using ipchains and portforwarding to use the 5 IPs we get from SBC, but I had wanted to make the move to iptables for some time, and with SBC chaning my statics on me, I took this as the opportunity to do some digging. I found a number of people in various forums asking how to even use the 5 IPs with Linux and PPP. Almost all of them were asking in terms of SBC. I did not find any answers out there, so I wanted to write this up, hopefully to be picked up by the search engines for others to be able to do the same.
Note. Other than playing with Knoppix, I have always used Red Hat variants. My current Linux Firewall/Server is running CentOS (www.centos.org), which is a Red Hat Enterprise Linux clone. I assume that these instructions will work for the Fedora series, and they may work for others, but I do not know. This should give someone knowledgeable enough the clues needed to get it working on another architecture.
What this covers: Getting a single Linux machine so that it will grab, respond to and use all 8 of your SBC assigned IPs.
What this does not cover: Firewall/Forwarding setup to get your Linux NATing for your internal network. (If you are sophisticated enough to try using all 8 IPs on Linux, I figure you already have a NAT setup.)
Pre-reqs for these instructions:
1) Cayman 3546
2) Recent Red Hat Linux based distribution.
3) Static account with SBC
1) Cayman 3546 has its admin interface available at 192.168.1.254 (The default)
2) Static address block is 220.127.116.11 - 18.104.22.168
Overview: I accomplished this basically by first putting the 3546 in bridge mode, setting up a ppp0 interface to handle the PPPOE connection to the redback, and finally setting up ip-aliases ppp0:1 through ppp0:7 for the remaining IP addresses.
1. SET UP THE ETHERNET CARD TO TALK TO THE CAYMAN
The Linux box has a single ethernet card plugged into the 3546. That ethernet card is set up to have an IP address that is in the same network as the 3546. This way, even after you have the PPPOE set up, you can still get into the Cayman. The ethernet card will not have any IP address configured from the block of statics, only the network for the 3546. Most likely, you can skip this section.
I'll refer to some pages of the Red Hat Enterprise Linux 3 System Administration Guide for some of the work involved in this. To set up an ethernet card, need to configure the appropriate ethernet interface.
First, start up the Network Administration Tool (To start the application, go to the Main Menu Button (on the Panel) => System Settings => Network, or type the command redhat-config-network at a shell prompt (for example, in an XTerm or a GNOME terminal). If you type the command, the graphical version is displayed if X is running, otherwise, the text-based version is displayed. ) (see the network admin section).
You want to choose the ethernet interface (eth1 in my setup) that is plugged into the 3546 and chose to give it a static ip address of the 192.168.1.1, a netmask of 255.255.255.0 and you can leave the gateway at 192.168.1.1. (This ethernet interface will never be used for anything at the IP level other than talking to the 3546.
2. PUT THE CAYMAN INTO BRIDGE MODE
Refer to the instructions on the Netopia site for putting the Cayman into bridged mode.
Before saving and restarting with the new settings, make sure you have printed copies of any reference material you need online, because you'll be unable to browse for a bit. After completing the changes and re-starting the modem, confirm that you can still get into the admin interface at 192.168.1.254. If not, re-set the 3546 and start over.
3. SET UP YOUR LINUX BOX TO HANDLE MAKING A PPPOE CONNECTION
Detailed instructions for setting up a DSL connection are available in the Red Hat manual.
Basically, using the Network Administration Tool, add an interface. Choose ppp. Select eth1 (or the one connected to the 3546) as the device to use. Type SBC into the Provider box. Fill in your log-in name (remember this is of the form email@example.com) and your password. Click, Forward and then Apply. A new device (ppp0) should now show up in your devices list.
Click on the ppp0 device and then click the Edit button. Make sure you check the "Activate device when computer starts" option.
Go to the Advanced tab and check "Restart if connection dies" and "Make this connection the default route." (I think the latter will already be checked.)
I am not covering iptables firwall or NAT set-up here. However, you should set rules for both, and you should make sure that you activate them now, before making your PPPOE connection live. In fact, to get one of the seven IP addresses and not cause yourself problems, you are going to have to have some firewall rules in place. I do have a few comments about setting this up at the end, but I do not include any detailed instructions.
4. TEST YOUR PPPOE CONNECTION
Restart your network connection ("/etc/rc.d/init.d/network restart" at a root prompt) and confirm that you can surf from the Linux box.
5. INTERMISSION: DISCUSSION OF IP BLOCKS
Before we create ip aliases for your other static ips, a word about your netblock. You should already know the netblock that SBC has assigned to you. If for some odd reason, you don't, you can do issue an "ifconfig" command at a root prompt to see what IP address that SBC assigned to your ppp0 interface, and then do a "whois x.x.x.x." on that IP address to see the ARIN entry for you block of 8. Here is a portion of the Ameritech - SBC FAQ on static IPs, with the IP addresses modified slightly to fit my example:
SBC/Ameritech bridges the subnet across 1 IP, your router takes up 1 IP, and there is the
Actually, I've found that in the above example 0 and 7 are usable and I am running into no problems. (To get the broadcast usable, I had to do set things up in a way that you probably shouldn't, but it has been working so far. I'll post a followup if it causes problems.)
Ignoring the broadcast and network addresses for now, this set-up will get you 6, not 5, ip addresses because the one reserved for your WAN interface is the one your ppp0 connection gets from SBC when it does PPPOE.
6. HAND CREATE ppp0 IP ALIAS FILES
We are going to use IP aliasing to bind all 8 ip addresses to the ppp0 connection. There is no way to set up the appropriate entries using the Red Hat Network Admin Tool. So, we are going to first hand-create some files and then we will use the Network Admin Tool to make sure they are active at startup and adjust netmasks if need be.
If you look in /etc/sysconfig/network-scripts/ you should see a file created by the network admin tool called ifcfg-ppp0. Make sure your ppp0 connection is active and look at the file. It should look something like:
# Please read /usr/share/doc/initscripts-*/sysconfig.txt
Note the GATEWAY address. For the two different static blocks I've received, it has always been a x.x.x.254 address, but check just to be sure. (Yes, it also says FIREWALL=NONE. I'm not using the firewall scripts that come with the Red Hat distribution.)
Now, create 6 files: ppp0:1, ppp0:2, ppp0:3, ppp0:4, ppp0:5, ppp0:6. (We'll talk about the seventh one, the broadcast address, in more detail in a different section.) Each file should look like the following. The only thing that will be different are the IPADDR and the DEVICE lines.
Now, I know it says "TYPE=Ethernet" and that the PEERDNS setting is pointless because of the ppp0 device, but both of those get added by the network admin tool when you administer these devices. (It won't let you create them, but it will administer them--sort of. It sometimes misreports their up or down status in the network admin tool, though an "ifconfig" always seems correct.)
After this, go ahead and open the network admin tool and make sure they are all set to be activated at startup and that the settings look ok in there. Uncheck and check something so it thinks things have changed and then save your settings. You are doing this to make sure that there are no problems with the files and that the network admin tool will write out correct ones if you ever really do need to edit them.
Now, restart your network ("/etc/rc.d/init.d/network restart" at a root prompt) and you should have 7 usable addresses. Depending on your firewall rules, you can try pinging them from a neighbors DSL connection or something else, but all 7 are active and respond.
7. CONCLUSION: DISCUSSION OF THE BROADCAST ADDRESS
Originally, I set my Linux box up to use just the 6 (22.214.171.124 to 126.96.36.199 in our example) IPs that were supposed to be usable. However, I also had my firewall logging some outside connection attempts and I noticed that ppp0 was seeing packets bound for 188.8.131.52 and 184.108.40.206. That got me to thinking. So, I added a ppp0:x file for each of them as described in the previous section. It worked for 220.127.116.11 but was a no go for 18.104.22.168, even though I could still see packets coming in at 87.
After a little playing around, I realized the issue was my netmask. The ppp0 device is going to get a netmask of 255.255.255.248 from the redback. Nothing you can do to change that. I had used that for my other ips, but you don't have to. At least, I mean no one is making you. Really, you should, but you don't have to. You see, that netmask tells all the ppp0 interfaces that 22.214.171.124 is the broadcast address. A packet addressed to that IP address is supposed to go to all the other IPs in the network. And that is why I couldn't use it. When I tried to route traffic out that IP, either the userland tool or the networking stuff in the kernel realized it was stupid to make a web connection to a broadcast address and it silently prevented me.
So, I got to thinking, what if I told it that 126.96.36.199 wasn't my broadcast address? What if I gave it a slightly larger netmask so that 188.8.131.52 was not the last address in the block? Turns out, if I do that, then I can use that "broadcast" IP address.
Now, I don't know if I should be doing that. It goes against everything not to have a broadcast address in a network. However, every IP in the network is bound to a single interface, so doing anything to the broadcast address seems kind of silly anyway.
What I did, though, was adjust my netblock and firewall any packet inbound or outbound that would go to any other IP in the netblock that I've told my interface it is in. This means that if any SBC customers put up some really cool stuff on their static and they happen to be sitting right next to me, I won't be able to get to it. I've totally blocked myself off from a portion of the aDSL static blocks. But the bragging rights of saying that I have 8 usable IPs on SBC's PPPOE static package is worth it. If someone next to me puts up something really, really cool, then I can always lose the one IP I gain by doing this.
However, figuring out what netmask to use and what IPs to block gets a bit involved. I'll go over the theory briefly. I suspect that if you are the kind of person to try this, you may not even need it.
I also suspect that all the SBC static blocks are carved out of /24 CIDR networks, that they all use the 254 IP address for their gateway and thus that the final /29 in each /24 is unassigned. Given that the first /29 contains the network address, I suspect that it too, is unassigned. However, given that the redback is forwarding my traffic destined for the first and last IPs in my /29, I suspect that the redbacks do not have the network segmented into a bunch of small /29 CIDR blocks.
But, figuring out the netmask to use to make sure that your "broadcast" address is not a "broadcast" address is going to depend on where you fall within the /24.
For example, in the 184.108.40.206/29 that we are using, if we were to lie and say our network were actually a 220.127.116.11/28, then it would go from 18.104.22.168 to 22.214.171.124. That would make 126.96.36.199 the broadcast address.
So, we could get our Linux box to respond to 188.8.131.52 requests by changing the netmask in all the ppp0:x files to 255.255.255.240. (Can't do it on the ppp0 file because that gets overwritten each time a PPPOE connection is made. In fact, I you probably only need to do it for the ppp0:x file that is used for your "broadcast" address, but I've not tested that.) Then, before actually making the change live, we'd want to blackhole 184.108.40.206 - 220.127.116.11.
Of course, that's why I picked this network range for the example. If we were actually in the 18.104.22.168/29 network, then a network of 22.214.171.124/28 would not work because that would go from 126.96.36.199 - 188.8.131.52 and our "broadcast" would still be a "broadcast" on the network. So, we'd have to go with 184.108.40.206/27 and then blackhole 220.127.116.11 - 18.104.22.168 and 22.214.171.124 - 126.96.36.199.
If you are unlucky enough to have a /29 broadcast that ends in 128, you'll have to use a full /24 for your network. In that case, be sure to remember to leave a the x.x.x.254 gateway open so you can get out.
That's it and likely more than most people wanted to read, I'm sure, but if someone else is trying to set this up even just to get their Linux box to use the 6 approved IP addresses, this will serve to help get them going.
Thread from original post where there may be useful follow-up: »Using all 8 statics with Linux