Using A CentOS 6 Machine As A Gateway/router/home Server

Home » CentOS » Using A CentOS 6 Machine As A Gateway/router/home Server
CentOS 31 Comments


I’m rebuilding a machine to function as a gateway/router to Verizon DSL.

It has two NICs eth0 and eth1 (static set to

eth0 connects to the DSL modem.

I’ve setup Verizon DSL usine pppoe-setup, and it works.

I can connect from home machines to the server (; while logged in to the server, I can connect to both the internet, and the home machines.

But …

I can’t connect from the home machines directly to the Internet.

I have set net.ipv4.ip_forward = 1
in /etc/sysctl.conf

I haven’t setup the firewall yet (dangerous, I know) until I get the connectivity working.

I’m obviously overlooking some other configuration settings required for machines inside the network being able to connect through the gateway/router.

Thanks for any advice in advance.

Max Pyziur

31 thoughts on - Using A CentOS 6 Machine As A Gateway/router/home Server

  • Am 28.06.2015 um 20:50 schrieb Max Pyziur:

    [ … ]

    Part of the firewall setup (iptables) is to configure masquerading. That’s you issue, the missing masquerading of the traffic from the LAN
    hosts through the gateway.


  • As others have pointed out, you’re either missing a NAT layer or you got a large enough IP allocation to subnet and you haven’t set up routing. Probably safe to assume it’s NAT.

    I’d suggest at a minimum you install something like shorewall to assist in managing your firewall and IP masquerading tasks. It’s available in EPEL, is very well documented, and provides enough built in sanity checks to protect you against making some silly (and some not so silly)
    mistakes in your firewall management.

  • Thanks to all for pointing me in the direction of iptables and IP

    From several sources, code, the stock CentOS iptables I’ve cobbled the following
    /etc/sysconfig/iptables; while it works, I suspect that there are holes:
    # Firewall configuration written by system-config-firewall
    # Manual customization of this file is not recommended.
    :OUTPUT ACCEPT [0:0]
    :INPUT DROP [0:0]
    :OUTPUT ACCEPT [0:0]
    -A INPUT -p icmp -j ACCEPT
    -A INPUT -i lo -j ACCEPT
    -A INPUT -m state –state NEW -m tcp -p tcp –dport 22 -j ACCEPT
    -A INPUT -m state –state NEW -m tcp -p tcp –dport 80 -j ACCEPT
    -A INPUT -m state –state NEW -m tcp -p tcp –dport 443 -j ACCEPT

    I also seem to need to load iptable_nat nf_nat_ftp

    via rc.local

    Is this correct?

    Thank you again,


  • as others have stated, you need to use nating; you won’t actually be routing traffic (unless you’ve been allocated a routable network.
    which is possible, but pretty unlikely). the script I use (stolen from some google search, I’m sure. I can’t give proper attribution if pressed):

    iptables –flush # Flush all the rules in filter and nat tables iptables –table nat –flush iptables –delete-chain
    # Delete all chains that are not in default filter and nat table iptables –table nat –delete-chain
    # Set up IP FORWARDing and Masquerading iptables –table nat –append POSTROUTING –out-interface eth2 -j MASQUERADE
    iptables –append FORWARD –in-interface eth3 -j ACCEPT
    # Enables packet forwarding by kernel echo 1 > /proc/sys/net/ipv4/ip_forward

    in this case eth3 would be your local, non-routed network (e.g. 10.* or
    192.168.*) and eth2 would be your regular network interface (like the one plugged into your cable modem or DSL connection)
    it’d likely need to be customized for your environment and running it would likely destroy any firewall rules you have setup, fair warning.

  • only if you’re running some Linux build from the 1990s.

    nothing on RHEL/CentOS should need anything in rc.local

  • Hi,

    May I ask why you don’t just use a made-for-the-purpose-distro like Smoothwall to do this?
    I takes (almost) all of the pain out of configuring stuff, and is quite secure due to not having as much “junk” pre-installed as CentOS 6?

  • secure due

    Please note: I’m not criticizing, just curious about the argument behind using a regular OS to do firewall-stuff.

  • indeed, I use pfSense, running on a APU1D4 [1] router board as my firewall, and a separate home server on a HP Microserver [2]. IMHO, keeping the firewall function completely separate simplifies security.

    that router board can handle 300 Mbit/sec of NAT firewall rules, since I
    only have 30Mbit internet, thats plenty of headroom. the Microserver has 4×3 TB SATA drives in a raidZ (ZFS) for 7.5 TiB usable.

    I can muck about with the server at my leisure, and reboot it, and not affect internet routing to my wife. the firewall doesn’t need mucking about with and has uptimes measured in months (time between pfSense upgrades). pfSense provides the DHCP and DNS and NTP services for the LAN.


  • cores)

    Gotcha’. Fewer watts may be worth it in the long run, as this is a device that’s always on for obvious reasons.

  • depends entirely on your performance requirements. the APU has no fans AND no vents, the case sheet metal is the heatsink. this means it won’t fill up with dust over time. the lower end avoton/rangley chips have a heatsink and case vents, but not a fan, convection will move air and dust through the case.

  • OS 6?


    A consistent set of expectations does wonders for debugging odd-ball occurrences. Why learn the idiosyncrasies of two distros when one suffices? Just start with a minimal CentOS install on your router/gateway and add only the packages that you know that you need. Any critical omission will evidence itself in short order and can be added then; or the source of the need removed as circumstance warrants.

  • suffices?
    only then;

    Sorry for OT.

    Even considering a minimal CentOS install, is that still less minimal than e.g. Smoothwall or Ipcop?
    In my world, security has a price and, and that might be the need to learn another distro in order to minimize security issues (and maybe as in this case minimize attack-surfaces).

    Still just curious about the arguments pro/con regular OS:s as firewall. 8-)

  • Am 29.06.2015 um 15:46 schrieb Sorin Srbu :

    +1 – we use here for “all” the same distro because normally the most security holes are done by the configuration abilities of humans. to catch this effectively the distro is not a variable. Therefore I appreciate the great work of the “CentOS on ARM7”-team!

  • James B. Byrne wrote:

    Yup. For, um, about a dozen years, I ran RH 7.1,7.2, 7.3, and eventually 9
    on an old box that was nothing but a firewall router. I was seriously paranoid – no gcc or any development tools, no X, not much of anything. To the best of my knowledge, we never had a breakin.

    I’m running DD-WRT on an ASUS router these days, and I’m *NOT* wildly impressed. I mean, it seems ok, but the project is run in what I can only describe as “amateur”, in the worst sense of the word. The several official developers release a build, and you can choose which one of who’s; people on the mailing list have “favorite builds”, which is not a phrase I have *ever* heard used with an o/s before, and I’m afraid to update, as some of their “documentation” is out of date, or wrong.

    At some point, I may just get a PI, and run CentOS, or some firewall/router distro, though that would mean not having WiFi for guests.


  • At 07:43 AM 6/29/2015, you wrote:

    Mark The WiFi solution I use still uses a CentOS 6
    firewall/router/gateway, but one of my inside devices is a WiFi router. Rather than doing double routing, I connect one of the WiFi’s LAN connections via a switch to my Router via a switch, leaving the WiFi Router’s WAN conection unused. That way, my gateway
    (and not the WiFi router) is the DHCP server, and can enforce whatever firewall rules I want to apply.

    No need to give up your guest WiFi if you stick with a CentOS gateway.


  • david wrote:

    Hmmm… that’s a thought. On the other hand, for defence in depth, I’m sort of leary about using my own system as a firewall. As I noted, on my old firewall/router box, I had almost nothing. That’s why I’m considering a PI….


  • Then what is the appropriate way to ensure that these modules are loaded?

    Should they be placed in the /etc/init.d/iptables script?
    IPTABLES_MODULES=”iptable_nat ip_nat_ftp ip_conntrack ip_conntrack_ftp”

    or somewhere else?



  • It should do it automatically for you. Try it. Editing system init scripts is rarely recommended.


    This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify

    The views expressed within this email are those of the individual, and not necessarily those of the organisation

  • It worked.

    There are a lot of website guides to Linux homenetworking, some going back as far as tldp days (late 1990s, early 2000s). Understandably, there is no one that presents itself as being authoritative.

    Rebuilding a CentOS box is an occasional endeavour, not a weekly one. So the reliance is on the informational sources that are there (some of which do recommend hacking rc.local or /etc/init.d/iptables), memory, and trial-and-error (typos and misspecified NICs can become time-sinks).


  • Some holes, yes. I’d recommend that your FORWARD table be similar to INPUT. It should DROP by default, and ACCEPT on traffic coming in the LAN interface and going out the WAN interface (and ESTABLISHED data).
    As it is now, a host on your WAN interface could use your system as its gateway, and you’d MASQ its traffic.


    :FORWARD DROP [0:0]
    -A FORWARD -m state –state NEW -i eth0 -o eth1 -j ACCEPT

    Best practice is to apply both egress and ingress filters as well. You should only forward traffic to the WAN if the source address is one that you use on your LAN. You should only forward traffic to your LAN if the source is *not* an address you use in your LAN.

    I think that looks like this in iptables, but I might be wrong…

    :FORWARD DROP [0:0]
    -A FORWARD -m state –state ESTABLISHED,RELATED -i eth1 -s ! -j ACCEPT
    -A FORWARD -m state –state ESTABLISHED,RELATED -i eth0 -j ACCEPT
    -A FORWARD -m state –state NEW -i eth0 -o eth1 -s -j ACCEPT

  • I’m using a UniFi AP for my wireless, actually, I have two of them at home for full coverage. it works SO much smoother than the consumer routers I’d tried before. the UniFi is a ceiling mount device that looks like a smoke detector, it gets its power from the ethernet wire
    (comes with the PoE injector), the two of them act as a single wireless access point, one at each end of my rather long house provides corner to corner coverage.

  • Yes, a minimal install of CentOS is probably larger (less minimal) than a specialized distribution.

    When all of your systems are one OS, you can more easily build an infrastructure that provides backups, security and bug fix updates, monitoring, etc for all of your systems. Specialized devices are often left out when admins set up infrastructure to provide those services for their primary systems. That’s one way that a general purpose OS can be significantly better than a specialized OS.

  • I get good results with IPCop on an older box. I happened to already have my WAP set up, similar to David, with ethernet cable into my Netgear gigabit switch. But IPCop has a zone now for wifi and I could hook it into my IPCop and and get all it’s benefits.

    I haven’t bothered because I’m in the boonies with little traffic, meaning less “drive-by” traffic/chance of someone trying to break in via that route, and my security key is very long and follows all the usual guidlines re case, numbers, etc. Everyone that I’ve authorized has had to attempt multiple times to finally get in, even me, until the device in use (IPHone, Android phone, Kindle Fire, …) remembers a successful access completion.

    I’m very pleased with IPCop – going on near a decade by now I guess.

    MHO, Bill

  • OT but for firewalls I do lots of work with various flavors, I have pretty much settled on Pfsense, since I most of what I run is *nix based I like the fact that its BSD based. I have tired and tested lots of stuff and that is the one that I have settled on, use and support. Just something else to add to the list

  • Am 29.06.2015 um 19:40 schrieb Gordon Messmer :

    our dedicated DNS systems are minimal without effort (234 packages / 1,1GB total), with more effort we could reduce it under 1GB (logfiles are included).


  • sort PI….

    I used to use a similar solution at home with Smoothwall and an AP. Worked fine till the computer running Smoothwall died. Worked fine for home use. IDK if it would be a good solution in a
    “professional” environment as well, but scaled up of course.

  • left out primary

    Those are good points, thanks.

    I’m probably somewhat indoctrinated by the Smoothwall community and the thesis that an appliance like that, that only does one thing is really good at doing just that.

    Thanks all for your thoughts on this!

  • Being a longtime RH/CentOS user recently flirting with debian, I have to agree. Another advantage to using a single distro across multiple machines is the ability to compare them (e.g., does this system system file have the same size and timestamp on all my systems?).

    I agree on dd-wrt. Several docs and occasional forum postings say,
    “check the wiki.” Other docs and forum postings say, “ignore the wiki, it’s outdated.” Finding the latest build is like an easter egg hunt. The whole project seemed to me to be very disorganized.

    Re: administration and docs again: My router’s wifi radio seemed to go out one day (after a power outage). I couldn’t connect to the router anymore via wifi. The lack of reliable docs made figuring out the settings a guessing game. And I didn’t know what tools existed for diagnosing the hardware and software.

    I have to sympathize with the dd-wrt developers though. There are a lot of routers on the market. Most are vastly different in what hardware and features they have. And too, in most case (I’d think) they have docs from manufacturers, so have to reverse-engineer the code, and do this separately for dozens if not hundreds of routers on the market. Given these circumstances, it’s amazing they’ve been able to do what they’ve done.

    Waxing further off-topic, a solution to this, IMO, would be something very much like a Raspberry Pi router: essentially an RPi with a half-dozen RJ45 ports. It would be nice to have the wifi built into it, but because these are country-specific, the wifi-radio would probably need to be a separate plug-in part. But having non-volatile memory on a card, as RPi’s already have, would make testing and upgrading– and also downgrading– much easier and worry-free.

    When the radio on my wifi went out, I found it a simple matter to set up a secure wifi AP (using hostapd) on an RPi and plug it into an RJ45 on my router.