Hi Saverio, I found conflict:
172.16.1.10 00:50:56:1b:ba:5e VMware, Inc. 172.16.1.10 00:50:56:2b:12:e6 VMware, Inc. (DUP: 2) 172.16.1.10 00:50:56:2b:12:e6 VMware, Inc. (DUP: 3) 172.16.1.10 00:50:56:2b:12:e6 VMware, Inc. (DUP: 4) 172.16.1.10 00:50:56:2b:12:e6 VMware, Inc. (DUP: 5) So my assumptions were wrong ! :D Probably Virtual network Interface does not send ARP, but Physical Network with the same IP address range advertise this address generating conflict with active firewall / tinc machine. I'm to tie Keepalived and Tinc no this HA Firewall configuration... Thank you Roberto -----Original Message----- From: tinc [mailto:[email protected]] On Behalf Of Saverio Proto Sent: mercoledì 27 gennaio 2016 11.58 To: tinc <[email protected]> Subject: Re: HA firewall with tinc Hello Roberto, if you think terms of ARP protocol, you might want to try to use tinc with DeviceType = tap instead of tun. the tap interface will have a Mac Address and frames will be sent with a complete L2 header. All standard L2 protocols such as ARP will work as expected as on a normal ethernet interface. Cheers Saverio 2016-01-27 10:32 GMT+01:00 mlist <[email protected]<mailto:[email protected]>>: > 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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[email protected]> >> http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc >> > _______________________________________________ > tinc mailing list > [email protected]<mailto:[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]<mailto:[email protected]> > http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc _______________________________________________ tinc mailing list [email protected]<mailto:[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
