I know in the hot spare server you restore here on the spare system, however there is no option to ignore firewall polices on restore. Everyone’s situation is different, but I see times where we don’t want to restore the primary firewall because the environment is different.
This also means that if you want to accept something from a certain IP range on the Hot Spare, you will have to program that same firewall policy on the primary, so it makes it to the spare.
@xrobau I know this was your brainchild at one point, not sure if you have any workaround or suggestions, or if this makes sense to when there is time add it in to the restore here process as an option to exclude.
I agree if you use it as a spare in the same network, however all of the hotspare servers I configure are in geographically different locations intentionally as well as scenario’s where some clients have a local server and then we hot spare to a web server.
Scenario’s of Primary provider (Virtual), physical ( at client location or data center) going down, failover to external ( virtual or physical ).
This allows us to continue to receive calls at the Spare, take voicemail etc.
If phones are dual registered, they can of course get the call from that registration.
This allows us to protect against power, internet outages, and since we are in Florida, fun things like hurricanes which can cause several issues.
Exactly my point. If you need to allow access from two IP ranges, you need to allow it from everywhere. What if they go down and you don’t?
There is no reason why the firewall ingress rules should be different on the hot spare (again, disregarding the interface config which is obviously machine specific)
I’ll give you a scenario, there may be more.
I have no problem adding them to the primary and allowing them to sync, although there may be some scenarios we wouldn’t want.
Example:
Internal PBX, allows local network and policy is set to consider 10.x local.
The backup of that PBX of course can’t communicate on 10.x since it’s external, so I need to add the internal location’s External IP address to the policy, to insure remote management of the Secondary PBX.
In this scenario, the primary physical PBX could crash and I still have internet access, so I need connect to the Secondary to see who registered etc.
Thanks, and great module by the way, this is a critical component in my opinion!
I was originally thinking that I should default 10.0.0.0/8, 192.168.0.0/16 and 172.16.0.0/12 to be ‘internal’ or ‘trusted’, but, there’s enough people running in shared environments where you CAN’T trust all your RFC1918 addressees (eg, AWS) that I talked myself out of it.
If you’re not running in AWS, then you probably should just click ‘Yes’ in the firewall wizard and add them all.
If your next response is ‘Well, primary CAN trust 10.0.0.0/8 and secondary CAN’T trust 10.0.0.0/8’ my simple answer is ‘Don’t do that then’
I understand and have for multiple internal PBX’s vpn’d environments I do that, but this is one of those inside/outside and outside isn’t in your control.
So I do think there are times ( maybe not many ) where either the backup option needs to remove certain things from being backed up, therefore never restored, or the restore needs the don’t restore firewall option.
