States ARE synced. IPs are not the same on node1 and node2 for external. The you initiated connection to ftp.fr, you done it via node1 with its external IP. On node2 those packets will be DROPPED as those do not belong to external NIC on node2 (IP)
On 3 jul 2013, at 17:16, Loïc Blot <loic.b...@unix-experience.fr> wrote: > I don't understand why they can't be synced because if i have this > scheme: > > server 1 - | Router 1 + Router 2 | remote > > server 1 contact remote, outgoing by Router 1 and the return traffic > comes from Router 2. > > The state may have "server 1 port A to remote port B", then the virtual > IP is useless in this configuration, no ? > -- > Best regards, > > Loïc BLOT, Engineering > UNIX Systems, Security and Networks > http://www.unix-experience.fr > > > Le mercredi 03 juillet 2013 à 09:36 -0500, Mark Felder a écrit : >> On Wed, 03 Jul 2013 09:24:54 -0500, Loïc Blot >> <loic.b...@unix-experience.fr> wrote: >> >>> For me pf table is (sorry for the missing precisions) the pf state >>> stable for stateful operations >> >> First of all, the states of node 1 being synced to node 2 and vice versa >> is worthless because they have different IP addresses; the states wont >> match anything. >> >> Secondly, you'll probably end up dealing with the nodes fighting each >> other as they sync back and forth. If a state from node1 is synced to >> node2 and node2 decides to expire that session because it hasn't been used >> it will tell node1 to remove that session as well. Now your session that >> was working on node1 has stopped functioning. This is probably the >> hanging/stalling behavior you were experiencing before. I've never even >> attempted to set this up in a lab and I know nothing of the pfsync/pf >> code, but I assume this is what is happening to you. I'm actually quite >> surprised it will even accept any changes to states for IPs that don't >> exist on the server, but I suppose it doesn't seem worthwhile to put such >> strict validation on it.
