pfSense

CARP in general has always caused "arpresolve: can't allocate llinfo" logs under various circumstances. One of those, IIRC, is when the system issues an ARP request on its own CARP IPs. It's always been cosmetic only.

I have a single pfsense, a few LAN, 2 SDSL and 1 ADSL.
Office LAN required to use 2 SDSL while the LabA and LabB uses the ADSL.
I have create Gateway Group for Office LAN to use both SDSL.
However if I don't have sticky connection, access to certain website such as Rapidshare will be a problem.
Once sticky connection is turn on I would notice on the Sys log "arpresolve: can't allocate llinfo" and causes my Internet to be on and off.

Reportedly, for one user, all connections out the primary WAN with sticky enabled are fine, and all the ones out OPT1 WAN fail.

Although I suspect we can use the above patch and even axe

$route .= " round-robin ";

For me sticky connections works for like a minute or 2, then suddenly no connections are possible at all to any host. Also not to hosts never connected before (and not present in the state table).

In the kernel log are a lot of messages like
arpresolve: can't allocate llinfo for IP_OF_GATEWAY

With for IP_OF_GATEWAY the 3 ip's of the gateways the pfsense box is connected to.
They start to show up as soon as sticky connections are enabled, might be cosmetic as suggested earlier.
All 3 WAN interfaces are vlans on the same physical interface. LAN traffic is NATed and routed over a gatewaygroup of these 3 interfaces:
GWINET_GROUP = " route-to { ( em1_vlan11 192.168.101.1 ) ( em1_vlan12 192.168.102.1 ) ( em1_vlan13 192.168.103.1 ) } round-robin sticky-address "

If I untick sticky connections and save everything immediately works again.
If I enable sticky connections again, all outgoing traffic stops after some minutes. Connection to the webinterface/ssh of pfsense keeps working, only outgoing connections fail (no traffic can be seen on the on the outgoing interfaces either, apart from the gateway pings and replies pfsense does).

Wait a few minutes more and traffic suddenly works again, and a while later it breaks again. This continuously repeats itself as long as sticky connections are ticked.

Running 2.0-BETA5 (i386) built on Wed Dec 29 18:28:41 EST 2010, before today I was running the build from oct 14 which has the same issue.

Could this freebsd kernel issue be related?
http://www.freebsd.org/cgi/query-pr.cgi?pr=148290

I'm having the exact same behaviour as described by Mark Huijgen earlier. The only difference is that my two WAN interfaces are on separate physical networks. CARP and LAN are on the same physical network, but separated by VLANs.

I'm running 2.0-RC3 (i386) built on Tue Jun 21 18:21:10 EDT 2011.

Can you please test with tomorrows snapshot?

Updated to version 2.0-RC3 (i386) built on Thu Sep 1 18:11:23 EDT 2011

Unfortunately the behavior is still the same as described in reply #11

When the failure occurs the connections have entries similar to the one below in the state table (all failing connections are in these states).

tcp 193.33.214.79:80 <- 172.22.22.79:57276 CLOSED:SYN_SENT
tcp 172.22.22.79:57276 -> 192.168.101.2:54006 -> 193.33.214.79:80 SYN_SENT:CLOSED

Ermal, can you please check your last commit. I can confirm that sticky sessions work for me on snapshot 2.0-RC3 (i386) built on Aug 30 16:55 2011. Not working on any builds after your commit on 9/1 to fix the reported issues with the patch.