Re: Upgrading a CARP firewall cluster
‐‐‐ Original Message ‐‐‐ On Tuesday, April 30, 2019 9:29 PM, Lyndon Nerenberg wrote: > On our systems, we run the 'a' machine as primary and the 'b' machine > as backup. When upgrading, we do the 'b' machine first, since this > doesn't disrupt the primary. After the 'b' machine is fully configured, > monitor its state table to ensure it's consistent with the 'a' > machine. Once you are convinced pf is staying in sync, demote the > 'a' machine and upgrade it. Thanks for your procedure tips, that's pretty much the same procedure I use except that I didn't even demote the "a" machine before upgrading it. Now I guess demoting the machine in question before upgrading it is the best practice and so I checked the OpenBSD FAQ about CARP and see different methods. The "carpdemote" way seems the cleanest way so as I have 8 carp interfaces all in the default carp group, should I simply run the following command: $ ifconfig -g carp carpdemote 50 or what is your way of demoting the server before upgading it? Regards, Mabi
Re: Upgrading a CARP firewall cluster
mabi writes: > Now I would first like to upgrade the cluster to 6.4 and then to 6.5 and was > wondering if it is possible to operate that cluster for a short amount of tim > e having one node running 6.3 and the other node with 6.4 and then the same f > or going to 6.4 to 6.5. In general this is not a problem. We run several carp-ed firewall (and load balancer/proxy) pairs, and upgrade them in this manner. As was already mentioned, always read the release notes to look for carp or pfsync changes that might cause trouble. On our systems, we run the 'a' machine as primary and the 'b' machine as backup. When upgrading, we do the 'b' machine first, since this doesn't disrupt the primary. After the 'b' machine is fully configured, monitor its state table to ensure it's consistent with the 'a' machine. Once you are convinced pf is staying in sync, demote the 'a' machine and upgrade it. Make sure you have 'net.inet.carp.preempt=1' in /etc/sysctl.conf, and set advskew appropriately on each host in the pair. --lyndon
Re: Upgrading a CARP firewall cluster
mabi(m...@protonmail.ch) on 2019.04.30 08:21:43 +: > Hello, > > I have an OpenBSD 6.3 firewall cluster made out of two nodes (one master, one > backup) using CARP and pfsync. This cluster also makes use of trunk and vlan > interfaces. > > Now I would first like to upgrade the cluster to 6.4 and then to 6.5 and was > wondering if it is possible to operate that cluster for a short amount of > time having one node running 6.3 and the other node with 6.4 and then the > same for going to 6.4 to 6.5. > > Is this safe? or could there be any incompatibilities in carp/pfsync which > would prevent me to do that upgrade in two steps while keeping everything > online? > > Cheers, > Mabi This is only a problem when we change the protocols involved, and that would be mentioned in the upgrade guide. Since there were no protocol changes to carp(4) or pfsync(4) between 6.3 and 6.5, you should not have a problem with this upgrade. In fact, you could go 63 -> 64 -> 65 on one firewall while the other stays on 63. /Benno
Re: Upgrading a CARP firewall cluster
‐‐‐ Original Message ‐‐‐ On Tuesday, April 30, 2019 11:20 AM, Igor Podlesny wrote: > CARP should be of no worries at all and PF state table's sync is > easily verified. > If after backup's upgrade-reboot it has roughly same amount of entries > you can safely demote master and repeat procedure. > Even if there were some major differences maximum what you could loose > is connections state table. Thank you Igor for the details. As you mention it doesn't really matter much if the connection state table gets lost in the worst case.
Re: Upgrading a CARP firewall cluster
On Tue, 30 Apr 2019 at 15:24, mabi wrote: [...] > Is this safe? or could there be any incompatibilities in carp/pfsync which > would prevent me to do that upgrade in two steps while keeping everything > online? CARP should be of no worries at all and PF state table's sync is easily verified. If after backup's upgrade-reboot it has roughly same amount of entries you can safely demote master and repeat procedure. Even if there were some major differences maximum what you could loose is connections state table. -- End of message. Next message?
Upgrading a CARP firewall cluster
Hello, I have an OpenBSD 6.3 firewall cluster made out of two nodes (one master, one backup) using CARP and pfsync. This cluster also makes use of trunk and vlan interfaces. Now I would first like to upgrade the cluster to 6.4 and then to 6.5 and was wondering if it is possible to operate that cluster for a short amount of time having one node running 6.3 and the other node with 6.4 and then the same for going to 6.4 to 6.5. Is this safe? or could there be any incompatibilities in carp/pfsync which would prevent me to do that upgrade in two steps while keeping everything online? Cheers, Mabi
Re: Firewall cluster.
Le Wed, 09 Jul 2014 20:33:47 +0200, Mxher a écrit : Hello, > >> I'm doing few more tests and now I'm wondering if this is possible > >> to disallow CARP to have some resources on serverA and others on > >> serverB? You can use ifstated to implement your own logic. I have a pair of firewall, the first is the normal master, the second is the backup. If a problem occurs on the first, carp allows the second to become master. But then, ifstated running on the first fw disallows carp to prevent it to become master again (even if a problem occurs on the second). To make the first master again, someone must, by hand, check the situation and enable carp on it. This is because the failover depends on some BGP sessions here. Regards,
Re: Firewall cluster.
First, thanks for trying to help! Le 09/07/2014 07:08, Remi Locherer a écrit : > On Mon, Jul 07, 2014 at 08:44:43PM +0200, Mxher wrote: >> Hello again, >> >> I'm doing few more tests and now I'm wondering if this is possible to >> disallow CARP to have some resources on serverA and others on serverB? > > Have you set the sysctl net.inet.carp.preempt=1? > Yes it is. >> >> Here is my tests (advbase=1 and advskew=0 for every interfaces on both >> servers): > > advskew should be different on master from backkup. Try advskew=200 on > obsd2. > > Please read man carp. The first example is exactly what you need. > It's not; I will describe my tests more precisely (sorry for the long post again): 1) Initial state root@obsd1:~# sysctl -a|grep net.inet.carp.preempt net.inet.carp.preempt=1 root@obsd2:~# sysctl -a|grep net.inet.carp.preempt net.inet.carp.preempt=1 root@obsd1:~# ifconfig HA|grep carp: carp: MASTER carpdev em0 vhid 1 advbase 1 advskew 0 carp: MASTER carpdev em1 vhid 2 advbase 1 advskew 0 carp: MASTER carpdev em2 vhid 3 advbase 1 advskew 0 carp: MASTER carpdev em3 vhid 4 advbase 1 advskew 0 root@obsd2:~# ifconfig HA|grep carp: carp: BACKUP carpdev em0 vhid 1 advbase 1 advskew 200 carp: BACKUP carpdev em1 vhid 2 advbase 1 advskew 200 carp: BACKUP carpdev em2 vhid 3 advbase 1 advskew 200 carp: BACKUP carpdev em3 vhid 4 advbase 1 advskew 200 2) Unplug of em3 on obsd1: the failover is done as expected root@obsd1:~# ifconfig HA|grep carp: carp: BACKUP carpdev em0 vhid 1 advbase 1 advskew 0 carp: BACKUP carpdev em1 vhid 2 advbase 1 advskew 0 carp: BACKUP carpdev em2 vhid 3 advbase 1 advskew 0 carp: INIT carpdev em3 vhid 4 advbase 1 advskew 0 root@obsd2:~# ifconfig HA|grep carp: carp: MASTER carpdev em0 vhid 1 advbase 1 advskew 200 carp: MASTER carpdev em1 vhid 2 advbase 1 advskew 200 carp: MASTER carpdev em2 vhid 3 advbase 1 advskew 200 carp: MASTER carpdev em3 vhid 4 advbase 1 advskew 200 3) (re)Plug of em3 on obsd1: resources gets back on obsd1 because of the advskew greater on obsd2 (this is the exact purpose of advskew, and I want to avoid it, but I did it to show you). root@obsd1:~# ifconfig HA|grep carp: carp: MASTER carpdev em0 vhid 1 advbase 1 advskew 0 carp: MASTER carpdev em1 vhid 2 advbase 1 advskew 0 carp: MASTER carpdev em2 vhid 3 advbase 1 advskew 0 carp: MASTER carpdev em3 vhid 4 advbase 1 advskew 0 root@obsd2:~# ifconfig HA|grep carp: carp: BACKUP carpdev em0 vhid 1 advbase 1 advskew 200 carp: BACKUP carpdev em1 vhid 2 advbase 1 advskew 200 carp: BACKUP carpdev em2 vhid 3 advbase 1 advskew 200 carp: BACKUP carpdev em3 vhid 4 advbase 1 advskew 200 4) Unplug of em2 on obsd2 AND unplug of em3 on obsd1: resources get "mixed" between the two nodes. I don't think this is a bug, it seems to be design to act like this and I can understand why. But, in my case, I must avoid that. root@obsd1:~# ifconfig HA|grep carp: carp: MASTER carpdev em0 vhid 1 advbase 1 advskew 0 carp: MASTER carpdev em1 vhid 2 advbase 1 advskew 0 carp: MASTER carpdev em2 vhid 3 advbase 1 advskew 0 carp: INIT carpdev em3 vhid 4 advbase 1 advskew 0 root@obsd2:~# ifconfig HA|grep carp: carp: BACKUP carpdev em0 vhid 1 advbase 1 advskew 200 carp: BACKUP carpdev em1 vhid 2 advbase 1 advskew 200 carp: INIT carpdev em2 vhid 3 advbase 1 advskew 200 carp: MASTER carpdev em3 vhid 4 advbase 1 advskew 200
Re: Firewall cluster.
On Mon, Jul 07, 2014 at 08:44:43PM +0200, Mxher wrote: > Hello again, > > I'm doing few more tests and now I'm wondering if this is possible to > disallow CARP to have some resources on serverA and others on serverB? Have you set the sysctl net.inet.carp.preempt=1? > > Here is my tests (advbase=1 and advskew=0 for every interfaces on both > servers): advskew should be different on master from backkup. Try advskew=200 on obsd2. Please read man carp. The first example is exactly what you need. > * Initial state > root@obsd1:~# ifconfig HA |grep status > status: master > status: master > status: master > status: master > root@obsd2:~# ifconfig HA |grep status > status: backup > status: backup > status: backup > status: backup > > * I unplugged em2 and em3 on obsd2 and em1 on obsd1: > root@obsd1:~# ifconfig HA |grep status > status: master > status: invalid > status: master > status: master > root@obsd2:~# ifconfig HA |grep status > status: backup > status: master > status: invalid > status: invalid > > > obsd2 became master for em1 while obsd1 is master for everything else. > Is there any (proper and automatic) way to avoid that ? > > I know that kind of situation will not happens often but... > > > Thanks again! > > > Le 06/07/2014 13:13, Mxher a écrit : > > Le 06/07/2014 12:05, Otto Moerbeek a écrit : > >> On Sun, Jul 06, 2014 at 10:59:16AM +0200, Janne Johansson wrote: > >> > >>> The sysctl for carp.preempt controls if they should all fail at the same > >>> time. > >> > >> read carp(4). It contains answers to some questions asked. > >> > >>-Otto > >> > > > >>> Den 6 jul 2014 10:12 skrev "Adam Thompson" : > I recall someone pointing out that interface groups of carp interfaces > will all transition simultaneously. I find ifconfig(8) inconclusive; run > your own tests and if that works, you have a built-in solution for > keeping > all the carp interfaces in sync. > Then, use ifstated to manage the pppoe interfaces depending on ifstate of > the relevant wan interface? You could set up a carp interface with no IP > address bound, set it into the common if group and it would go up/down > with > the other carp ifs. > Maybe. I haven't tried anything like that myself. > -Adam > > > > I run some tests and this is working as expected! > > > > Only thing I see is that there will be no group failback if this is a > > virtual carp interface which goes down. > > > > To be clear if the parent interface of carp2 goes down the whole group > > will switch but not if carp2 goes down by itself (by an admin mistake > > for example): > > * initial states > > root@obsd1:~# sysctl -a|grep preem > > net.inet.carp.preempt=1 > > root@obsd1:~# ifconfig HA |grep status > > status: master > > status: master > > status: master > > status: master > > > > root@obsd2:~# sysctl -a|grep preem > > net.inet.carp.preempt=1 > > root@obsd2:~# ifconfig HA |grep status > > status: backup > > status: backup > > status: backup > > status: backup > > > > > > * states with carp2 down on obsd1 > > root@obsd1:~# ifconfig carp2 down > > root@obsd1:~# ifconfig HA |grep status > > status: master > > status: master > > status: invalid > > status: master > > > > root@obsd2:~# ifconfig HA |grep status > > status: backup > > status: backup > > status: master > > status: backup > > > > > > * also unfortunately when carp2 goes UP again on obsd1 it still remains > > on obsd2: > > root@obsd1:~# ifconfig carp2 up > > root@obsd1:~# ifconfig HA |grep status > > status: master > > status: master > > status: backup > > status: master > > > > root@obsd2:~# ifconfig HA |grep status > > status: backup > > status: backup > > status: master > > status: backup > > > > > > Anyway I think this is an acceptable risk. > > > > > > @Adam: I will now try to use ifstated to manage pppoe interfaces like > > you suggest. > > > > > > Thanks to everyone of you.
Re: Firewall cluster.
Hello again, I'm doing few more tests and now I'm wondering if this is possible to disallow CARP to have some resources on serverA and others on serverB? Here is my tests (advbase=1 and advskew=0 for every interfaces on both servers): * Initial state root@obsd1:~# ifconfig HA |grep status status: master status: master status: master status: master root@obsd2:~# ifconfig HA |grep status status: backup status: backup status: backup status: backup * I unplugged em2 and em3 on obsd2 and em1 on obsd1: root@obsd1:~# ifconfig HA |grep status status: master status: invalid status: master status: master root@obsd2:~# ifconfig HA |grep status status: backup status: master status: invalid status: invalid obsd2 became master for em1 while obsd1 is master for everything else. Is there any (proper and automatic) way to avoid that ? I know that kind of situation will not happens often but... Thanks again! Le 06/07/2014 13:13, Mxher a écrit : > Le 06/07/2014 12:05, Otto Moerbeek a écrit : >> On Sun, Jul 06, 2014 at 10:59:16AM +0200, Janne Johansson wrote: >> >>> The sysctl for carp.preempt controls if they should all fail at the same >>> time. >> >> read carp(4). It contains answers to some questions asked. >> >> -Otto >> > >>> Den 6 jul 2014 10:12 skrev "Adam Thompson" : I recall someone pointing out that interface groups of carp interfaces will all transition simultaneously. I find ifconfig(8) inconclusive; run your own tests and if that works, you have a built-in solution for keeping all the carp interfaces in sync. Then, use ifstated to manage the pppoe interfaces depending on ifstate of the relevant wan interface? You could set up a carp interface with no IP address bound, set it into the common if group and it would go up/down with the other carp ifs. Maybe. I haven't tried anything like that myself. -Adam > > I run some tests and this is working as expected! > > Only thing I see is that there will be no group failback if this is a > virtual carp interface which goes down. > > To be clear if the parent interface of carp2 goes down the whole group > will switch but not if carp2 goes down by itself (by an admin mistake > for example): > * initial states > root@obsd1:~# sysctl -a|grep preem > net.inet.carp.preempt=1 > root@obsd1:~# ifconfig HA |grep status > status: master > status: master > status: master > status: master > > root@obsd2:~# sysctl -a|grep preem > net.inet.carp.preempt=1 > root@obsd2:~# ifconfig HA |grep status > status: backup > status: backup > status: backup > status: backup > > > * states with carp2 down on obsd1 > root@obsd1:~# ifconfig carp2 down > root@obsd1:~# ifconfig HA |grep status > status: master > status: master > status: invalid > status: master > > root@obsd2:~# ifconfig HA |grep status > status: backup > status: backup > status: master > status: backup > > > * also unfortunately when carp2 goes UP again on obsd1 it still remains > on obsd2: > root@obsd1:~# ifconfig carp2 up > root@obsd1:~# ifconfig HA |grep status > status: master > status: master > status: backup > status: master > > root@obsd2:~# ifconfig HA |grep status > status: backup > status: backup > status: master > status: backup > > > Anyway I think this is an acceptable risk. > > > @Adam: I will now try to use ifstated to manage pppoe interfaces like > you suggest. > > > Thanks to everyone of you.
Re: Firewall cluster.
Le 06/07/2014 12:05, Otto Moerbeek a écrit : > On Sun, Jul 06, 2014 at 10:59:16AM +0200, Janne Johansson wrote: > >> The sysctl for carp.preempt controls if they should all fail at the same >> time. > > read carp(4). It contains answers to some questions asked. > > -Otto > >> Den 6 jul 2014 10:12 skrev "Adam Thompson" : >>> I recall someone pointing out that interface groups of carp interfaces >>> will all transition simultaneously. I find ifconfig(8) inconclusive; run >>> your own tests and if that works, you have a built-in solution for keeping >>> all the carp interfaces in sync. >>> Then, use ifstated to manage the pppoe interfaces depending on ifstate of >>> the relevant wan interface? You could set up a carp interface with no IP >>> address bound, set it into the common if group and it would go up/down with >>> the other carp ifs. >>> Maybe. I haven't tried anything like that myself. >>> -Adam I run some tests and this is working as expected! Only thing I see is that there will be no group failback if this is a virtual carp interface which goes down. To be clear if the parent interface of carp2 goes down the whole group will switch but not if carp2 goes down by itself (by an admin mistake for example): * initial states root@obsd1:~# sysctl -a|grep preem net.inet.carp.preempt=1 root@obsd1:~# ifconfig HA |grep status status: master status: master status: master status: master root@obsd2:~# sysctl -a|grep preem net.inet.carp.preempt=1 root@obsd2:~# ifconfig HA |grep status status: backup status: backup status: backup status: backup * states with carp2 down on obsd1 root@obsd1:~# ifconfig carp2 down root@obsd1:~# ifconfig HA |grep status status: master status: master status: invalid status: master root@obsd2:~# ifconfig HA |grep status status: backup status: backup status: master status: backup * also unfortunately when carp2 goes UP again on obsd1 it still remains on obsd2: root@obsd1:~# ifconfig carp2 up root@obsd1:~# ifconfig HA |grep status status: master status: master status: backup status: master root@obsd2:~# ifconfig HA |grep status status: backup status: backup status: master status: backup Anyway I think this is an acceptable risk. @Adam: I will now try to use ifstated to manage pppoe interfaces like you suggest. Thanks to everyone of you.
Re: Firewall cluster.
On Sun, Jul 06, 2014 at 10:59:16AM +0200, Janne Johansson wrote: > The sysctl for carp.preempt controls if they should all fail at the same > time. read carp(4). It contains answers to some questions asked. -Otto > Den 6 jul 2014 10:12 skrev "Adam Thompson" : > > > On July 6, 2014 2:51:03 AM CDT, Mxher wrote: > > >Le 06/07/2014 04:34, Giancarlo Razzolini a ??crit : > > >> Em 05-07-2014 16:20, Mxher escreveu: > > >>> 1) Can I group multiple virtuals ips to make them switch all at the > > >same > > >>> time using CARP ? > > >> AFAIK, no. But you can use ifstated. > > >I have to admit that I didn't knew about ifstated; I will test it. > > > > > >>> 2) About modems interfaces, I can't have them UP on both firewalls > > >at > > >>> the same time. > > >>> How would you managed that? > > >> You're dialing to your modems using pppoe? If so, them no, you > > >probably > > >> can't have both them up, even with carp. If you could change your > > >> configuration for routing instead, you could use carp on your > > >external > > >> interface to talk with your modems. > > >Yes, unfortunately I have to use pppoe on two (of the five) modems. > > > > > >> > > >> Cheers, > > >> > > > > > >Thanks for your answer! > > > > I recall someone pointing out that interface groups of carp interfaces > > will all transition simultaneously. I find ifconfig(8) inconclusive; run > > your own tests and if that works, you have a built-in solution for keeping > > all the carp interfaces in sync. > > Then, use ifstated to manage the pppoe interfaces depending on ifstate of > > the relevant wan interface? You could set up a carp interface with no IP > > address bound, set it into the common if group and it would go up/down with > > the other carp ifs. > > Maybe. I haven't tried anything like that myself. > > -Adam > > -- > > Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: Firewall cluster.
The sysctl for carp.preempt controls if they should all fail at the same time. Den 6 jul 2014 10:12 skrev "Adam Thompson" : > On July 6, 2014 2:51:03 AM CDT, Mxher wrote: > >Le 06/07/2014 04:34, Giancarlo Razzolini a écrit : > >> Em 05-07-2014 16:20, Mxher escreveu: > >>> 1) Can I group multiple virtuals ips to make them switch all at the > >same > >>> time using CARP ? > >> AFAIK, no. But you can use ifstated. > >I have to admit that I didn't knew about ifstated; I will test it. > > > >>> 2) About modems interfaces, I can't have them UP on both firewalls > >at > >>> the same time. > >>> How would you managed that? > >> You're dialing to your modems using pppoe? If so, them no, you > >probably > >> can't have both them up, even with carp. If you could change your > >> configuration for routing instead, you could use carp on your > >external > >> interface to talk with your modems. > >Yes, unfortunately I have to use pppoe on two (of the five) modems. > > > >> > >> Cheers, > >> > > > >Thanks for your answer! > > I recall someone pointing out that interface groups of carp interfaces > will all transition simultaneously. I find ifconfig(8) inconclusive; run > your own tests and if that works, you have a built-in solution for keeping > all the carp interfaces in sync. > Then, use ifstated to manage the pppoe interfaces depending on ifstate of > the relevant wan interface? You could set up a carp interface with no IP > address bound, set it into the common if group and it would go up/down with > the other carp ifs. > Maybe. I haven't tried anything like that myself. > -Adam > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: Firewall cluster.
On July 6, 2014 2:51:03 AM CDT, Mxher wrote: >Le 06/07/2014 04:34, Giancarlo Razzolini a écrit : >> Em 05-07-2014 16:20, Mxher escreveu: >>> 1) Can I group multiple virtuals ips to make them switch all at the >same >>> time using CARP ? >> AFAIK, no. But you can use ifstated. >I have to admit that I didn't knew about ifstated; I will test it. > >>> 2) About modems interfaces, I can't have them UP on both firewalls >at >>> the same time. >>> How would you managed that? >> You're dialing to your modems using pppoe? If so, them no, you >probably >> can't have both them up, even with carp. If you could change your >> configuration for routing instead, you could use carp on your >external >> interface to talk with your modems. >Yes, unfortunately I have to use pppoe on two (of the five) modems. > >> >> Cheers, >> > >Thanks for your answer! I recall someone pointing out that interface groups of carp interfaces will all transition simultaneously. I find ifconfig(8) inconclusive; run your own tests and if that works, you have a built-in solution for keeping all the carp interfaces in sync. Then, use ifstated to manage the pppoe interfaces depending on ifstate of the relevant wan interface? You could set up a carp interface with no IP address bound, set it into the common if group and it would go up/down with the other carp ifs. Maybe. I haven't tried anything like that myself. -Adam -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: Firewall cluster.
Le 06/07/2014 04:34, Giancarlo Razzolini a écrit : > Em 05-07-2014 16:20, Mxher escreveu: >> 1) Can I group multiple virtuals ips to make them switch all at the same >> time using CARP ? > AFAIK, no. But you can use ifstated. I have to admit that I didn't knew about ifstated; I will test it. >> 2) About modems interfaces, I can't have them UP on both firewalls at >> the same time. >> How would you managed that? > You're dialing to your modems using pppoe? If so, them no, you probably > can't have both them up, even with carp. If you could change your > configuration for routing instead, you could use carp on your external > interface to talk with your modems. Yes, unfortunately I have to use pppoe on two (of the five) modems. > > Cheers, > Thanks for your answer!
Re: Firewall cluster.
Le 05/07/2014 22:37, sven falempin a écrit : > > read the FAQ, dont forget to sync the states and use ifstated to change the > modem state when swithcing master fw. > > Actually I read it but I didn't notice ifstated; after a quick look it seems quite interesting. Thank you.
Re: Firewall cluster.
Em 05-07-2014 16:20, Mxher escreveu: > 1) Can I group multiple virtuals ips to make them switch all at the same > time using CARP ? AFAIK, no. But you can use ifstated. > 2) About modems interfaces, I can't have them UP on both firewalls at > the same time. > How would you managed that? You're dialing to your modems using pppoe? If so, them no, you probably can't have both them up, even with carp. If you could change your configuration for routing instead, you could use carp on your external interface to talk with your modems. Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC
Re: Firewall cluster.
On Sat, Jul 5, 2014 at 3:20 PM, Mxher wrote: > Hello everyone, > > At work we are using a firewall cluster of two Linux servers but I'm > trying to change this; especially to replace iptables/netfilter by pf > (mostly for performances and 'easy to maintain' reasons). > > Here is the thing: right now if the active node is seen dead, all > resources will switch on the other node (via pacemaker/heartbeat); here > is the resources managed: > - virtuals ips, > - firewall's configuration, > - routes, > - ADSL modems (in bridge mode) interfaces. > > So here is my issues: > 1) Can I group multiple virtuals ips to make them switch all at the same > time using CARP ? > > 2) About modems interfaces, I can't have them UP on both firewalls at > the same time. > How would you managed that? > > > Currently, I'm thinking about making CARP listen on a dedicated > interface (directly connected between the two servers) and manage > everything by the up/down scripts. > But with that kind of solution there will be no failover if another > interface goes down on the active node. > > > Maybe I'm missing something obvious here, in that case please don't hit > me too hard ;) > > > Thanks! > > read the FAQ, dont forget to sync the states and use ifstated to change the modem state when swithcing master fw. -- - () ascii ribbon campaign - against html e-mail /\
Firewall cluster.
Hello everyone, At work we are using a firewall cluster of two Linux servers but I'm trying to change this; especially to replace iptables/netfilter by pf (mostly for performances and 'easy to maintain' reasons). Here is the thing: right now if the active node is seen dead, all resources will switch on the other node (via pacemaker/heartbeat); here is the resources managed: - virtuals ips, - firewall's configuration, - routes, - ADSL modems (in bridge mode) interfaces. So here is my issues: 1) Can I group multiple virtuals ips to make them switch all at the same time using CARP ? 2) About modems interfaces, I can't have them UP on both firewalls at the same time. How would you managed that? Currently, I'm thinking about making CARP listen on a dedicated interface (directly connected between the two servers) and manage everything by the up/down scripts. But with that kind of solution there will be no failover if another interface goes down on the active node. Maybe I'm missing something obvious here, in that case please don't hit me too hard ;) Thanks!
