Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

This is a bit complex so bear with me. I do have a pretty good working knowledge of IP but I'm looking for help on the best way to implement this.

My ISP has given me a block of static IPs as well as a single IP. For privacy's sake, here's the network layout I'll be using in my examples:

  • 192.168.1.0/24 - LAN
  • 172.16.0.1/30 - Single static IP, default gw 172.16.0.2
  • 172.16.1.1-5/28 - Range of static IPs, default gw 172.16.1.6

In these examples, 172.16.0.1 and 172.16.1.1-5 in reality are world-routable Internet IPs. I'm using private IP blocks for privacy's sake. So pretend that 172.16.0.1 is whatever public IP you want to imagine, and same for the 172.16.1.1 block.

My service is provided via a single cable modem interface with a single Ethernet port. In other words, all of the switching, routing, etc. is expected to be done on the customer side.

I currently have a Linux server with two Ethernet interfaces. It is assigned 172.16.0.1 static and uses NAT to provide Internet to the LAN interface, which works perfectly. I've used this setup for years to provide me with a NAT router that I have a lot deeper control over than an off-the-shelf router.

Now, I want to begin utilizing those other static IPs I have. The catches are these:

  1. I still want to be able to, at least to some degree, control the access to those boxes. So, at the main Linux box, I'd like to be able to say that "172.16.1.1 cannot receive any incoming connections except via port 80" or "172.16.1.2 cannot connect outbound to anything except port 22". Just some examples. In other words, I still want firewall control over these boxes. Similar to how I can presently use iptables to block say 192.168.1.5 from going anywhere except where I want it, and in this instance, also counting the inbound connections as well. Ideally this would mean that I can get all packets destined for one of the five public statics routed via iptables and have the same level of control I do over LAN packets.

  2. Computers on the LAN (192.168.1.0/24) may need to access these public-facing machines as well. In addition, computers on the public IPS may need to access the LAN computers. So, 172.16.1.2 may need to access 192.168.1.5 and vice versa.

  3. The computers that have static world-routable IPs should if at all possible be self-aware of their public-facing IP. One suggestion I saw for this suggested plopping the public computers on the LAN and giving them LAN addresses, then using multihoming on the Linux box and forwarding all ports from the desired static to the desired LAN IP. This certainly does work but it creates some messy situations - the Linux box now needs to be aware of every single static IP and thus this wouldn't scale well. So for instance "eth1" (the WAN interface) would need to not only have the IP that it already uses, but also all five other IPs. This might be fine for five, but what about scalability when in the future there's 2000 IPs....

One idea I thought of was adding a third interface to the Linux router and setting up a small network that contains only the public-facing machines. The only question then is routing between those machines and the Internet. On top of that, the only simple way I could think of to accomplish it this way was to give the Linux box a second IP address on eth2, which would use up one of those five precious statics.

I do not want to have to use any commercial solutions to accomplish this. I would feel Linux should be able to handle this sort of situation.

Layout This is the layout I'm hoping will work but I just need to figure out how to do the routing itself on Linux.

share|improve this question
    
No interest in a firewall that can address multiple public WAN addresses? Something like a Cisco ASA. –  ewwhite Jun 5 '13 at 0:14
    
Really don't want to go with commercial solutions.. This is for a very small home-based business as well as some personal cloud stuff. I feel like there should be some way to accomplish this with Linux's powerful networking stack; just looking for some direction. –  fdmillion Jun 5 '13 at 3:59
    
A key point would be that I need to figure out how to get packets coming in from the router and destined for the second block of IPs to pass up into iptables. Once they're in there, I could do whatever routing, redirecting or mangling necessary to get them to and from where I want. Problem is Linux only passes packets it "expects" to see through iptables. In other words it won't process packets not destined for addresses it itself knows about. Adding the IPs to Linux AND to the servers would create some confusion on the LAN with respects to ARP and such... –  fdmillion Jun 5 '13 at 4:02
    
It's a small home-based business that has 3 different ISP uplinks? Just buy the hardware. It's $260 for an ASA5505 on Amazon, which is probably less than you'd pay for 3 SOHO firewalls at big box computer store. –  Magellan Jun 5 '13 at 4:06
    
No, it's a single ISP link with multiple IP addresses on the same Ethernet, as stated in my original post. In my example, 172.16.0.1 is a single static IP, and 172.16.1.x is five additional static IPs, but they ALL come in off the same Ethernet cable. To test, I put a switch between the Linux router and the modem and setup a second box with a static, and it worked. This is another idea I had, but it still doesn't solve the problem of routing 192.168.1.x FROM those five IPs into the LAN. This won't work as those boxes wouldn't be using my router as their gateway. –  fdmillion Jun 5 '13 at 4:25

3 Answers 3

up vote 0 down vote accepted

I finally figured this out, and for the benefit of everyone else, it's worth writing about here.

I am going to be getting a box with three Ethernet interfaces. Here is how we wire them:

  • eth0 -> to cable modem
  • eth1 -> to a switch on which computers with public WAN addresses shall reside
  • eth2 -> to a switch for LAN (NATted) computers

We setup a Linux bridge using bridge-utils (brctl), br0, that bridges eth0 and eth1.

We can then give the br0 interface one of the public facing IP addresses. This will end up being the address that packets coming from LAN computers will come from. For the best security, I will use iptables to block ALL non-NAT traffic to this IP:

iptables -A INPUT d 172.16.0.1 -j DROP

This works since NAT traffic will be passed on the FORWARD chain, while unsolicited Internet traffic will appear on INPUT.

Now, on the WAN switch, I can place other hosts. I'll move my main server - the webserver and so on - to that switch and statically assign it one of the world-routable public IPs.

The real reason that this wasn't obvious to me before was that I didn't think I could firewall on a bridge interface - I didn't realize that a bridge's packets do indeed pass through iptables. Turns out not only can I do that, but I can even use tricks like ulogd and similar tools to do bandwidth monitoring and so on. The key to this is an iptables module called physdev, which lets you firewall based on which physical interface a packet is coming into or going out of, regardless of the bridge-ness of the interfaces.

So I could add firewall rules to the FORWARD table, e.g.:

iptables -A FORWARD -d 172.16.1.2 -p tcp --dport 80 -m physdev --physdev-in eth0 -j ACCEPT
iptables -A FORWARD -d 172.16.1.2 -m physdev --physdev-in eth0 -j DROP

This ends up only allowing port 80 traffic to 172.16.1.2 from the Internet, even though that machine has a public IP. (Remember in my examples 172.16.x.x are public, even though we all know in reality they're not.)

Since I am using physdev, this means that machines on the LAN side can still have full access to that host. So from the LAN side, I can still SSH to 172.16.0.1. From the perspective of a LAN machine, 172.16.0.1 has no firewall at all. From the perspective of another DMZ machine, same thing. However, from the perspective of the Internet, 172.16.0.1 is locked down.

Solution found! This has turned out to be a really fun project.

F

share|improve this answer

The functionnality you're looking for is "network aliases", I suppose. Then what you need to do is to configure "multiple NAT" for these network aliases.

I dunno what you're running actually on your router linux box, but if I could suggest one solution, just install "pfSense" which has a lot of features ( http://www.pfsense.org/index.php@option=com_content&task=view&id=40&Itemid=43.html ) or IPCop ( http://www.ipcop.org/ ), then it's much easier to administrate as it's a graphical solution.

It's exactly corresponding to your use case :

Moreover, it runs on really old hardware.

Yann

share|improve this answer
    
With IPCop, your public network is the RED zone, your server/DMZ is ORANGE, and your workstation are GREEN ( or BLUE if wireless ). So you can check on Google for "IPCop Orange multiple" –  Yannovitch Jun 5 '13 at 8:28

if you add the third interface like you have above to build a DMZ, the routing is dead simple. quite literally all you need to do is enable IP Forwarding and it will forward packets between the connected interfaces.

either

sysctl -w net.ipv4.ip_forward=1

or

echo 1 > /proc/sys/net/ipv4/ip_forward

to enable it on the fly

or set

net.ipv4.ip_forward=1 in /etc/sysctl.conf

Then you would just need firewall rules to control access to the Lan computers from the DMZ, you would still utilize NAT from the Wan interface to the LAN interface, you would rely on Routing + access rules to control from the WAN to DMZ and the DMZ to LAN. The fact the DMZ and the LAN's default GW is the same box, you will not have to relay on static routes on the DMZ or LAN computers to access each other. Another option is to put 2 ethernet cards in each DMZ host, and connect them to the lan as well, but that isn't as clean as using the Router in the middle and access lists (iptables) to dictate what can talk to what.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.