Bug #337

sticky connections do not work

Added by Wilson Tsui over 11 years ago. Updated almost 10 years ago.

Operating System
Target version:
Start date:
Due date:
% Done:


Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
Affected Architecture:


Enable sticky connection will cause kernel: arpresolve: can't allocate llinfo whenever using Gateway group.

pfsense 2.0 Beta1 updated to the latest 6th Feb 2010

Syslog.JPG (69.2 KB) Syslog.JPG Log Wilson Tsui, 02/06/2010 08:47 AM
FirewallRules.JPG (28.4 KB) FirewallRules.JPG Firewall rules Wilson Tsui, 02/06/2010 08:47 AM
Gateway.JPG (42.1 KB) Gateway.JPG Gateway Wilson Tsui, 02/06/2010 08:47 AM
GatewayGroup.JPG (17.3 KB) GatewayGroup.JPG Gateway group Wilson Tsui, 02/06/2010 08:47 AM
Sticky.JPG (34.4 KB) Sticky.JPG Sticky Connection Wilson Tsui, 02/06/2010 08:47 AM (2.2 KB) Scott Ullrich, 07/14/2010 10:51 PM

Associated revisions

Revision 47a5384d (diff)
Added by Scott Ullrich almost 11 years ago

Allow sticky-connections to work again. Ticket #337

Revision 1e7fff5a (diff)
Added by Chris Buechler almost 11 years ago

correctly use sticky and round-robin. Ticket #337


#1 Updated by Ermal Luçi over 11 years ago

  • Status changed from New to Feedback

Please detail more your setup.
Do this gateways reside on the LAN of the interfaces ?

#2 Updated by Chris Buechler over 11 years ago

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.

#3 Updated by Wilson Tsui over 11 years ago

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.

#4 Updated by Chris Buechler about 11 years ago

  • Subject changed from sticky connection on pfsense 2.0 to sticky connections do not work
  • Category set to Operating System
  • Status changed from Feedback to New

sticky definitely still doesn't work right (with multi-WAN at least), though I don't know it's related to the "can't allocate llinfo" log. Need to gather more info on this.

#5 Updated by Chris Buechler about 11 years ago

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

#6 Updated by Ermal Luçi about 11 years ago

  • Status changed from New to Feedback

I tried this and it works as expected.

For Port forwarding possibly it needs to be handled properly in backend since there is no code at all and i do not think that advanced checkbox is doing what is expected in that case!

#7 Updated by Chris Buechler about 11 years ago

  • Status changed from Feedback to New

sticky isn't added to the ruleset at all anymore, nor is round-robin (though it functions as such with two gateways at least). line 595 in never evals to true.

#8 Updated by Scott Ullrich almost 11 years ago

Please try the attached patch.

#9 Updated by Scott Ullrich almost 11 years ago

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

$route .= " round-robin ";

#10 Updated by Chris Buechler almost 11 years ago

  • Status changed from New to Resolved

fixed, and sticky with multi-WAN has no apparent problems, I've been load balancing all my HTTP with sticky for weeks and it works as it should.

#11 Updated by Mark Huijgen over 10 years ago

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 ) ( em1_vlan12 ) ( em1_vlan13 ) } 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.

#12 Updated by Mark Huijgen over 10 years ago

Could this freebsd kernel issue be related?

#13 Updated by Siddharth Patil almost 10 years ago

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.

#14 Updated by Ermal Luçi almost 10 years ago

Can you please test with tomorrows snapshot?

#15 Updated by Mark Huijgen almost 10 years ago

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


#16 Updated by I K almost 10 years ago

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.

Also available in: Atom PDF