Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm in the process of setting up an Ubuntu Linux box to act as a router. Its a fairly normal setup with NATing using IPTables - and its working fine for me.

I'm about to put this into production, and I've thus far, for testing, been putting multiple WAN IPs in stanzas in the /etc/network/interfaces file:

# WAN Interface
iface eth0 inet static
    address 123.123.456.345
    netmask 255.255....
    network ...
    broadcast ...
    gateway ...

iface eth0:1 inet static
    address 123.456.789.123
    netmask ...

iface eth0:2 inet static ...

The problem I've found is that we have about 20 WAN IPs that this Linux box needs to do NATing for right now, which means I need to assign all 20 of those IPs onto this box, which it can then translate into the correct private IP.

That's the thing - the interfaces file is steadily growing larger, and I'm starting to wonder if this is going to become difficult to manage in the near future. But the above example is pretty much the only way I've ever done it, and by far the most common example I can find when searching.

The only other method I've found and considered is here:

# Internet interface
auto eth0
iface eth0 inet static
    up ip addr add brd dev eth0 label eth0:0

Is there a way of organising this that someone else can recommend for a large number of IP aliases? And why did you choose that over any other method?


As two answers now have basically suggested, don't use NAT, just bridge the traffic through the firewall and assign IPs directly on the server. I should add, we're already using that method in production but have decided to move away from it.

  • We want to save our public address space, many of the devices or VMs only need one public port open, and no other public service. For that reason, we want to be able map ports on a single public IP to separate internal devices.

  • We're moving forward to a VPN infrastructure that allows customers to VPN in and access their allocated subnet/VLAN, and therefore have access to their servers.

  • VLANs with a bridged firewall configuration has proven troublesome. Because the packets are hitting our upstream provider still tagged, the packets get rejected.

I should be clear that this is not entirely a 1:1 NAT setup. Its just that, right now, all devices have their own WAN IP - so that's the best description of what we're having to move to right now.

Many of the devices will still need their own IP, and in those cases, we NAT and allow the ports individually, so its kind of like 1-1 NAT, with firewalling. In some cases, though, the devices will not need a WAN IP at all.


share|improve this question
I suspect I would spend time trying to figure out why tagged VLAN frames are crossing the Linux box. Sounds to me like you have something messed up there. – Zoredache Jul 22 '11 at 7:57
BTW the up option in the interfaces just runs an external command. You could just build a script with a for loop in it or something that adds all the addresses and call that script with the up option. – Zoredache Jul 22 '11 at 8:00

Do this the right way -- get the address range routed to your firewall and put the IP addresses where they're supposed to be, on the destination devices.

share|improve this answer
You've given no justification as to why your way is "the right way" for my scenario. I also commented in the answer by Dave as to why we want to move away from that. Maybe I'm missing something? – Geekman Jul 22 '11 at 4:32
You're not currently routing, you're bridging. Routing is the right way because NAT is evil, and bridging/Proxy ARP is a hack. But hey, if you want a broken, hard to manage network, go for your life. – womble Jul 22 '11 at 4:51

Rather than NAT'ing that many addresses, why don't you use your firewall to bridge the two networks, and assign the real IPs directly to the systems in question. You can still filter traffic to protect the hosts, and you can ease the load (not that it will be that much, probably) on the firewall by not having to maintain all those NATs.

Search for linux bridging, brctl and ebtables.

share|improve this answer
A bridged firewall setup is actually what we currently have now in production. But we want to move away from that for two reasons: 1) Eventually begin to save our public IP space 2) Make it easier to allow customers to VPN to the servers on their particular VLAN/Subnet. – Geekman Jul 22 '11 at 3:36

Your Answer


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.