> After hours of thinking, reading manuals and googling I decided to
> send a mail to this list.
>
> We have two OpenBSD firewalls using CARP + PFSYNC to provide
> redundance. The problem is that long downloads stall randomly. For
> example, downloading a 700 MB ISO stalls at about 120 MB, although
> this figure may vary. For pfsync we are using dedicated interfaces on
> both firewalls. The harware and the configurations on both firewalls
> are identical. So is the interfaces naming.
>
> We also have checked that connections aren't kept when there's a CARP
> failover, so we deduce that pfsync is not working properly with our
> configuration.
>
> This problem doesn't happen when we disable pfsync. Here are the rules
> concerning pfsync on our firewalls:
> ------------
> pfsync_if="rl1"
>
> pass log-all quick on $pfsync_if proto pfsync keep state
> pass log-all quick on { $ext_if $int_if } proto carp keep state
> ------------
> Concerning the pass rule for pfsync we originally didn't write 'keep
> state', as the man page says it has to be. Adding 'keep state' doesn't
> make any difference, as the same problem appears.
>
> This is the content of /etc/hostname.rl1 (know the netmask is too large):
> inet 10.0.0.1 255.255.255.0 10.0.0.255
> ------------
> And this is for /etc/hostname.pfsync0:
> up syncpeer 10.0.0.2 syncdev rl1
>
> One thing that could be unusual is that we are using no IP addresses
> on the external interfaces facing Internet (all the public IPs we have
> are on CARP interface carp0), and we use one of this address to make
> NAT to allow LAN hosts to access Internet. Could this represent a
> conflict with pfsync.
>
> Any clue? Thanks in advance.I have had similar issues with stalled session after a lot of data already transferred. My problems occurred because I had net.inet.carp.preempt=1 and not all interfaces plugged in. There have been some fixes for failover stuff. My problems went away when I connected all interfaces. For example I had a DMZ5 that was not used at the moment and therefor not connected to a switch. When I plugged it in the problem went away. You will also eventually have race conditions during boot up if not all interfaces are connected (fixed with patches to stable). I could also see not wanted failovers when both firewalls had interfaces that was not connected (flip over and then back again). Another thing to check is the synproxy if you use that. It's broken in 3.8. But you have not specified any OS version. The problem is SACK which can lead to the problem you describe. > One thing that could be unusual is that we are using no IP addresses > on the external interfaces facing Internet (all the public IPs we have > are on CARP interface carp0), and we use one of this address to make > NAT to allow LAN hosts to access Internet. Could this represent a > conflict with pfsync. NO. But read my misc thread "ARP errors with IP less interfaces and many CARP interfaces." and my own reply to it regarding arp/mac issues with IP less interfaces.
