> On 4. Dec 2023, at 10:59, Stuart Henderson <stu.li...@spacehopper.org> wrote:
>
> On 2023-12-01, Christian Gut <cycl...@is-root.org> wrote:
>> Hi List,
>>
>> I just updated two carp/pfsync firewalls from 7.3 to 7.4. After updating the
>> second box I see a massive increase in traffic on the sync interface. I now
>> reproduced this with another pair of firewalls - same thing.
>>
>> Both firewall have three physical interfaces: external, internal and sync.
>> Sync interface is connected via ethernet cable directly. Syncinterface has
>> an ip address.
>>
>> Configuration of hostname.pfsync0:
>> syncdev em2
>> up
>>
>> The way I updated these boxes, lets call them primary and secondary:
>>
>> 1. update secondary to 7.4, including the change in hostname.pfsync0
>> 2. change hostname.carp0 to promote to master - reboot
>> 3. secondary is now master
>> 4. update primary to 7.4
>> => traffic on syncif increases
>>
>> I tried so far - without any improvements:
>> - reboot both machines after another
>> - promote primary again
>> - ifconfig pfsync0 down; pfctl -F states; ifconfig pfsync0 up
>
> When you tried down/flush/up did you do it on both firewalls at the same
> time? (i.e. down pfsync on both, then flush on both, then up pfsync)?
I did this only on the slave, as doing it on the master firewall would affect
production.
>
>> I think they might see some kind of loop updating the states between each
>> other. Could someone point me to how I could diagnose further?
>
> pfsync was largely rewritten between 7.3 and 7.4, we found one problem
> like this but it was fixed before release.
>
> Best way to proceed is probably to capture traffic on the pfsync
> interface with tcpdump and see if it relates to any particular state/s
> and if there's anything special about them or the rules that generate
> them.
>
> bugs@ might be a better place than misc@ to continue this.
I will try to gather more input and send it to bugs@ - thanks.
