Note: maybe the "Background" and "Plan" are not really necessary; feel free to skip to the "Problem" immediately...

Background

We have recently migrated a bunch of servers from one subnet into another. They used to have the IP addresses 192.168.0.0/24; now they have 10.1.2.0/24.

To avoid having to actually change the addresses on the servers and make the switch as simple as possible, we did not change anything on them; they still are configured to use 192.168.0.x and know nothing at all about 10.1.2.x.

Instead, the router (pfSense 2.3.2) in front of them does 1:1 NAT, mapping between the two subnets.

There is no VLAN or other special networking going on here; just the two regular physical ethernet ports of some machine, one for LAN, one for WAN (the WAN side is a simple ethernet uplink, no dial-up/DSL or something like that).

Everything works great, and all is well. I can reach the servers from the outside using their 10.1.2.x addresses (NATted by the router); and I can reach the outside from the servers - and they appear with their 10.1.2.x addresses as one would expect.

Plan

Right now, the router has the IP 192.168.0.1 on the LAN interface, and this IP is configured as default gateway for the servers (the usual, trivial setup).

Now we want to get rid of the old 192.168.0.x addresses and the NAT translation. To avoid having a single instance in time where we have to do the switch, I would like to make it so that I can move one server after the other around.

To my understanding, this could be done by giving the physical interface of the router the additional IP address 10.1.2.1 (on a Linux machine, I would simply add an IP alias), add the new IP addresses on the servers as IP aliases (does not matter whether all at the same time or individually), switch the servers to use 10.1.2.1 as default gateway instead of 192.168.0.1, disable the 1:1 NAT for that server IP, and be done with it. The server would then use its 10.1.2.x IP as "main" IP, and still listen on the old IP in case someone else inside the LAN still uses that. We can then phase out the old IPs over time.

Problem

How do we configure pfSense to have an IP alias on its LAN interface? Is that even possible? I can find no mention about IP aliases (secondary IPs on the physical interfaces) at all.

Is there another way to achieve what we want using pfSense?

I have a fairly simple iptables firewall on a server that provides MySQL services, but iptables seems to be giving me very inconsistent results.

The default policy on the script is as follows:

iptables -P INPUT DROP

I can then make MySQL public with the following rule:

iptables -A INPUT -p tcp --dport 3306 -j ACCEPT

With this rule in place, I can connect to MySQL from any source IP to any destination IP on the server without a problem. However, when I try to restrict access to just three IPs by replacing the above line with the following, I run into trouble (xxx=masked octect):

iptables -A INPUT -p tcp --dport 3306 -m state --state NEW -s 208.XXX.XXX.184 -j ACCEPT 
iptables -A INPUT -p tcp --dport 3306 -m state --state NEW -s 208.XXX.XXX.196 -j ACCEPT 
iptables -A INPUT -p tcp --dport 3306 -m state --state NEW -s 208.XXX.XXX.251 -j ACCEPT 

Once the above rules are in place, the following happens:

• I can connect to the MySQL server from the .184, .196 and .251 hosts just fine as long as am connecting to the MySQL server using it's default IP address or an IP alias in the same subnet as the default IP address.

• I am unable to connect to MySQL using IP aliases that are assigned to the server from a different subnet than the server's default IP when I'm coming from the .184 or .196 hosts, but .251 works just fine. From the .184 or .196 hosts, a telnet attempt just hangs...

  # telnet 209.xxx.xxx.22 3306
  Trying 209.xxx.xxx.22...
  

• If I remove the .251 line (making .196 the last rule added), the .196 host still can not connect to MySQL using IP aliases (so it's not the order of the rules that is causing the inconsistent behavior). I know, this particular test was silly as it shouldn't matter what order these three rules are added in, but I figured someone might ask.

• If I switch back to the "public" rule, all hosts can connect to the MySQL server using either the default or aliased IPs (in either subnet):

  iptables -A INPUT -p tcp --dport 3306 -j ACCEPT
  

The server is running in a CentOS 5.4 OpenVZ/Proxmox container (2.6.32-4-pve).

And, just in case you prefer to see the problem rules in the context of the iptables script, here it is (xxx=masked octect):

# Flush old rules, old custom tables
/sbin/iptables --flush
/sbin/iptables --delete-chain

# Set default policies for all three default chains
/sbin/iptables -P INPUT DROP
/sbin/iptables -P FORWARD DROP
/sbin/iptables -P OUTPUT ACCEPT

# Enable free use of loopback interfaces
/sbin/iptables -A INPUT -i lo -j ACCEPT
/sbin/iptables -A OUTPUT -o lo -j ACCEPT

# All TCP sessions should begin with SYN
/sbin/iptables -A INPUT -p tcp ! --syn -m state --state NEW -j DROP

# Accept inbound TCP packets (Do this *before* adding the 'blocked' chain)
/sbin/iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Allow the server's own IP to connect to itself
/sbin/iptables -A INPUT -i eth0 -s 208.xxx.xxx.178 -j ACCEPT

# Add the 'blocked' chain *after* we've accepted established/related connections
#   so we remain efficient and only evaluate new/inbound connections
/sbin/iptables -N BLOCKED
/sbin/iptables -A INPUT -j BLOCKED

# Accept inbound ICMP messages
/sbin/iptables -A INPUT -p ICMP --icmp-type 8 -j ACCEPT
/sbin/iptables -A INPUT -p ICMP --icmp-type 11 -j ACCEPT

# ssh (private)
/sbin/iptables -A INPUT -p tcp --dport 22 -m state --state NEW -s xxx.xxx.xxx.xxx -j ACCEPT          

# ftp (private)
/sbin/iptables -A INPUT -p tcp --dport 21 -m state --state NEW -s xxx.xxx.xxx.xxx -j ACCEPT          

# www (public)
/sbin/iptables -A INPUT -p tcp --dport 80 -j ACCEPT                                
/sbin/iptables -A INPUT -p tcp --dport 443 -j ACCEPT                               

# smtp (public)
/sbin/iptables -A INPUT -p tcp --dport 25 -j ACCEPT                                
/sbin/iptables -A INPUT -p tcp --dport 2525 -j ACCEPT                              

# pop (public)
/sbin/iptables -A INPUT -p tcp --dport 110 -j ACCEPT                               

# mysql (private)
/sbin/iptables -A INPUT -p tcp --dport 3306 -m state --state NEW -s 208.xxx.xxx.184 -j ACCEPT 
/sbin/iptables -A INPUT -p tcp --dport 3306 -m state --state NEW -s 208.xxx.xxx.196 -j ACCEPT 
/sbin/iptables -A INPUT -p tcp --dport 3306 -m state --state NEW -s 208.xxx.xxx.251 -j ACCEPT 

Any ideas? Thanks in advance. :-)

When setting up a web server with multiple IP-based virtual hosts, I've always used the eth0:x alias notation in /etc/network/interfaces. The wiki on my hosting provider states however that this is deprecated and one should now use the iproute tools.

Is this correct, and what's the difference between using aliases and using iproute?

System: HP Proliant DL360 G5 running CentOS 5.4

Bonded interface is working fine for a long time. I just went to add an alias the way I always have on a regular interface, and on first check it works (pinging on the local box) but it is not accessable from outside (iptables is turned off). In addition with this setup the normal network response started to decline, hanging for around a minute before I could get a prompt on login.

Here are my config files:

[root network-scripts]# cat ifcfg-eth0 
DEVICE=eth0
BOOTPROTO=none
ONBOOT=yes
MASTER=bond0
SLAVE=yes
USERCTL=no

[root network-scripts]# cat ifcfg-eth1
DEVICE=eth1
BOOTPROTO=none
ONBOOT=yes
MASTER=bond0
SLAVE=yes
USERCTL=no

[root network-scripts]# cat ifcfg-bond0 
DEVICE=bond0
BONDING_OPTS="mode=1 miimon=100"
BOOTPROTO=none
ONBOOT=yes
NETWORK=10.2.1.0
NETMASK=255.255.255.0
IPADDR=10.2.1.11
USERCTL=no

[root network-scripts]# cat ifcfg-bond0:1 
DEVICE=bond0:1
BOOTPROTO=static
ONBOOT=yes
NETWORK=10.2.1.0
NETMASK=255.255.255.0
IPADDR=10.2.1.12
USERCTL=no

any thoughts?

I have a server running Ubuntu Server with four IP addresses aliased on a single NIC.

eth0       192.168.1.100
eth0:0     192.168.1.101
eth0:1     192.168.1.102
eth0:2     192.168.1.103

(Using 192.168.x.x for sake of example, assume these are NAT-ed to a range of public IP addresses)

One of our clients publishes their inventory via FTP, so we log in nightly to download a large file from their server. Their firewall expects our (passive) FTP connection to be made from 192.168.1.100.

Given that my server logically has four IP addresses on a single adapter, how does the operating system determine which IP address is used as source for outbound TCP/IP connections?

Let's say I ssh into my server on 192.168.1.101 and run FTP interactively. Will the outbound TCP/IP connection use 192.168.1.101 because the OS knows that's the interface over which my shell is connected?

What if the FTP task is run non-interactively via a cron job where there is no shell?

As you can probably tell, this has me quite confused, so I hope my questions have at least made sense.

Edit

To clarify why I'm asking -- I haven't made any changes to the routing table and it actually lists 'eth0' as the IFace for the 0.0.0.0 routes. However, all indications are that it is actually using eth0:0 as the source.

Destination    Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.1.0    0.0.0.0         255.255.255.0   U     0      0        0 eth0
0.0.0.0        192.168.1.1     0.0.0.0         UG    100    0        0 eth0

I can fiddle with the routing table or have our client change their firewall rules to get the behavior I need, but I'm trying to gain a little insight into how this works to know if there's a bug in the OS or just my naive understanding of how all the pieces fit together.

Thanks