Using aliases in a clustered environment only works if the aliases share the cluster / member networks.
It usually works between reboots if you remove the aliases before the reboot and add it afterwards (ignoring the message that you should reboot after adding the alias) - no guarantee of course.
The place to add aliases depends on which version of the firewall you have. In pre-70006 I believe you add them in the High Availability section (we don't have any HA pairs at the lower versions to check this). In 70006 and later you add them in the Interfaces screen. If you add the alias to the Primary firewall and then Save the change, it will be pushed to the secondary.
At 70006 and 70007, you can see that the Cluster IP is an alias on each firewall. When you add a real alias, this goes alongside the cluster IP. On 70100 and later, they introduced the concept of Shared IPs between the firewalls (it's just a way of showing the user that the IP is shared between the members of a pair).
You can add any IP as an alias. It does not have to be in the same network as your interface's IP. However, you HAVE to reboot after adding an alias (or changing an IP) on an HA pair. The reason is that the faild process (the failover process) only reads IPs on boot. You cannot restart the faild process to get it to read your IPs. Faild transfers the IPs between members on a failover, so if you add an alias on the primary but do not reboot, the standby firewall will not have that alias (because faild has not read the IP yet).
I just tried this out, here's how it went:
- Peer to peer HA pair (meaning whichever firewall is Primary stays primary, as opposed to Active/Standby where one firewall takes over as Primary if it's running)
- I added an alias on the Primary (FW1) (Network -> Interfaces -> edit internal interface -> add alias address. I added an alias that is NOT in the same network as my current interface IPs.
- Save. Check the interfaces of the Secondary (FW2) firewall in the GUI -- the IP is there.
- Check 'ifconfig' on the Primary -- the IP is there (it's in the kernel). Check 'cf int q' on the Primary -- the IP is there.
- Check 'ifconfig on the Secondary -- the IP is not there. That's good; it should not be loaded into the kernel. Check 'cf int q' on the Secondary -- the IP is there as an alias; that's good, it's in the database.
Now, what you should do here is reboot the Secondary firewall. That way, faild can read the IP of and know that it is supposed to load this IP when this firewall becomes the primary. What I did was reboot the Primary firewall to show you what happens.
- Reboot the Primary
- FW2 becomes the Primary now.
- Check 'cf int q' on FW2 -- the alias is still there. Check 'ifconfig' on FW2 -- the IP is NOT there. We have not reboot FW2 (the old Secondary). Faild did not read this IP so this IP is not loaded into the kernel, and therefore this firewall will not respond to ARPs for that IP (and thus no traffic to that IP will flow to FW2)
- Reboot FW2. FW1 becomes Primary again
- Check 'ifconfig' and 'cf int q' on FW1 -- the IP is there. Faild read the IP when we rebooted this box earlier.
- Reboot FW1. FW2 becomes the primary
- Check 'ifconfig' on FW2 -- now the IP is there. Faild has read the IP and loaded it into the kernel. Now the alias is on both firewalls and will work when either is primary.
My fault: the problem only appears when you do this in a burb where failover is running
Yes, oreeh, that's correct.