Project

General

Profile

Actions

Bug #337

closed

sticky connections do not work

Added by Wilson Tsui about 14 years ago. Updated over 12 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
Operating System
Target version:
Start date:
02/06/2010
Due date:
% Done:

0%

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

Description

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


Files

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
filter.inc.diff (2.2 KB) filter.inc.diff Scott Ullrich, 07/14/2010 10:51 PM
Actions #1

Updated by Ermal Luçi about 14 years ago

  • Status changed from New to Feedback

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

Actions #2

Updated by Chris Buechler about 14 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.

Actions #3

Updated by Wilson Tsui about 14 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.

Actions #4

Updated by Chris Buechler almost 14 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.

Actions #5

Updated by Chris Buechler almost 14 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.

Actions #6

Updated by Ermal Luçi almost 14 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!

Actions #7

Updated by Chris Buechler almost 14 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 filter.inc never evals to true.

Actions #8

Updated by Scott Ullrich over 13 years ago

Please try the attached patch.

Actions #9

Updated by Scott Ullrich over 13 years ago

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

$route .= " round-robin ";
Actions #10

Updated by Chris Buechler over 13 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.

Actions #11

Updated by Mark Huijgen about 13 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 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.

Actions #12

Updated by Mark Huijgen about 13 years ago

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

Actions #13

Updated by Siddharth Patil over 12 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.

Actions #14

Updated by Ermal Luçi over 12 years ago

Can you please test with tomorrows snapshot?

Actions #15

Updated by Mark Huijgen over 12 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).

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

Actions #16

Updated by I K over 12 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.

Actions

Also available in: Atom PDF