This is a vpn for Disater Recovery sites, so it is not necessary to have a seamless failover, strictly speaking. Encryption instead is mandatory. Testing we found that on Keepalived failover remote Tinc take few seconds to reset the connection and correctly re-connect to the new active firewall (probably new firewall resetting the connection + PingTimeout + some seconds to reconnect). This is acceptable as replication mechanisms know about e WAN connection so all of that work well with such little connection interruption.
The problem is that to avoid to tie together Keepalived and Tinc, ie: put in Keepalived primary-backup.sh state change script commands to stop Tinc on Passive node and to start on active node, we try to leave Tinc acrtive always on all firewalls (also those are passive for keepalived - no VIP active) and use the VIP as Tinc tun virtual interface. Naturally when one node is active it has the Keepalived managed VIP active and Tinc Virtual Interface using tun has as IP the same as Keepalived VIP with different netmask (this seems ok as Guus tell me, until one uses 2 different netmask - routing systems works fine, in effect it is so). The Passive node has no Keepalived VIP assigned, but has Tinc active qith identical configuration of the other nodes (we take nodes in sync with rsync, for Tinc and for many other configuration). The problem is that having Tinc and so tun based virtual interface used by Tinc always active on all 2 firewall can pose conflict for the address, at least this would be so with Physical Network Interface. Not knowing a lot tun/tap technology I thought that a Virtual Network Interface TUN based could not have conflict, not sending it ARP announce or other ARP messages on the real (physical) network. Instead in my test I get some communication problems for internal users (that using Firewall VIP as default gateway), so probably my assumption about Tinc Tun Virtual Interface was not so good ! Do all of this sound logic for you ? I done a wrong assumption on Tun/Virtual Interface behavior ? Thank you Roberto -----Original Message----- From: tinc [mailto:[email protected]] On Behalf Of Saverio Proto Sent: mercoledì 27 gennaio 2016 09.53 To: tinc <[email protected]> Subject: Re: HA firewall with tinc Hello Roberto, you are trying to have two identical machines with active/passive failover behavior. This practice is well known in the industry, and most firewall vendors propose their proprietary solutions. However, those solution implies that the two chassis will sync their state, so when the active device fails, the secondary device takes over. Remote nodes will not notice that the actual device changed, because the state is preserved and the failover is seamless. What you are trying to do here with Keepalived cannot be the same. The running tinc on the active node has a state, and this is not synced to the backup device. This means that if the active node fails, the tinc process staring on the standby node starts from state 0, and this requires a setup time. Moreover, remote nodes will probably experience a state change in the remote peer, causing a reset of their state as well. I dont know if tinc is the right tool for your scenario. To seamless failover with keepalived, if encryption is not a must, you can think of GRE tunnels that are stateless. Active/passive seamless failover for firewall cluster, requires state syncronization among the two chassis. I hope this email helps you to better approach what you are trying to do. Cheers Saverio 2016-01-27 8:31 GMT+01:00 mlist <[email protected]>: > I think it should work at least for TUN virtual interface as TUn works at IP > level. > > This is a sample configuration. > > > > firewall1 lan = 172.16.1.11/19 (ALWAYS ACTIVE) - > "Physical Network Interface" – system config as ifcfg-… > > 172.16.1.10/19 (VIP Keepalived Make active) - > Active/Passive configuration with firewall2 > > firewall1 vpndr1 = 172.16.1.10/8 (ALWAYS ACTIVE) - "Virtual > Network Interface" – tinc config as tinc-up started as service > > > > > > > > firewall2 lan = 172.16.1.12/19 (ALWAYS ACTIVE) - "Physical > Network Interface" – system config as ifcfg-… > > 172.16.1.10/19 (VIP Keepalived Make active) - > Active/Passive configuration with firewall1 > > firewall2 vpndr1 = 172.16.1.10/8 (ALWAYS ACTIVE) - "Virtual > Network Interface" – tinc config as tinc-up started as service > > > > I tested this config and seem to work fine. When failover happen from one > node do other after some seconds remote tinc see connection reset by peer > (previous active node – eg: firewall1) and re-connect with ne new active > node (eg: firewall2). No network conflict was seen as now. > > > > Can you tell me if I’m doing wrong assumptions ? if some not optimal > behavior can be hidden ? > > > > Thank you > > Best Regards > > > > Roberto > > > > > > > > From: mlist > Sent: mercoledì 27 gennaio 2016 02.32 > To: '[email protected]' <[email protected]> > Subject: HA firewall with tinc > > > > I have 2 firewall in HA with keepalived. Can I use active the same tinc > configuration on 2 firewalls ? using tun Interface with same ip on all 2 > nodes is a problem ? tun device advertise itself on the network having an > IP/MAC pairs (ARP) or the IP is only used by the system internally for > routing so using the same configuration is right ? so one firewall be > active, the other is passive. With this configuration I can avoid > starting/stopping tinc with keepalived active passive node. Keepalived is > sometimes problematic with Virtual Machine backup (snapshot stun time), > transitioning from Master to Slave and vice versa at stun time, so we can > avoid probability that keepalived will starting up and shutting down tinc > erroneously. > > > > Thank you > > > > > > Roberto > > > > > > > > > > > _______________________________________________ > tinc mailing list > [email protected] > http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc > _______________________________________________ tinc mailing list [email protected] http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc -- Il messaggio e' stato analizzato alla ricerca di virus o contenuti pericolosi da MailScanner, ed e' risultato non infetto. _______________________________________________ tinc mailing list [email protected] http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
