HA firewall with tinc

Wed Jan 27 12:42:25 CET 2016

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:tinc-bounces a tinc-vpn.org] On Behalf Of Saverio Proto
Sent: mercoledì 27 gennaio 2016 11.58
To: tinc <tinc a tinc-vpn.org>
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 <mlist a apsystems.it<mailto:mlist a apsystems.it>>:

> 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:tinc-bounces a tinc-vpn.org] On Behalf Of Saverio Proto

> Sent: mercoledì 27 gennaio 2016 09.53

> To: tinc <tinc a tinc-vpn.org<mailto:tinc a tinc-vpn.org>>

> 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 <mlist a apsystems.it<mailto:mlist a apsystems.it>>:

>> 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: 'tinc a tinc-vpn.org' <tinc a tinc-vpn.org<mailto:tinc a tinc-vpn.org>>

>> 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

>> tinc a tinc-vpn.org<mailto:tinc a tinc-vpn.org>

>> http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc

>>

> _______________________________________________

> tinc mailing list

> tinc a tinc-vpn.org<mailto:tinc a tinc-vpn.org>

> 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

> tinc a tinc-vpn.org<mailto:tinc a tinc-vpn.org>

> http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc

_______________________________________________

tinc mailing list

tinc a tinc-vpn.org<mailto:tinc a tinc-vpn.org>

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.

-------------- parte successiva --------------
Un allegato HTML � stato rimosso...
URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20160127/b7c961d4/attachment-0001.html>