Bug #337
closedsticky connections do not work
Added by Wilson Tsui over 14 years ago. Updated almost 13 years ago.
0%
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 |
Updated by Ermal Luçi over 14 years ago
- Status changed from New to Feedback
Please detail more your setup.
Do this gateways reside on the LAN of the interfaces ?
Updated by Chris Buechler over 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.
Updated by Wilson Tsui over 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.
Updated by Chris Buechler over 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.
Updated by Chris Buechler over 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.
Updated by Ermal Luçi over 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!
Updated by Chris Buechler about 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.
Updated by Scott Ullrich about 14 years ago
- File filter.inc.diff filter.inc.diff added
Please try the attached patch.
Updated by Scott Ullrich about 14 years ago
Although I suspect we can use the above patch and even axe
$route .= " round-robin ";
Updated by Chris Buechler about 14 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.
Updated by Mark Huijgen over 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.
Updated by Mark Huijgen over 13 years ago
Could this freebsd kernel issue be related?
http://www.freebsd.org/cgi/query-pr.cgi?pr=148290
Updated by Siddharth Patil almost 13 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.
Updated by Ermal Luçi almost 13 years ago
Can you please test with tomorrows snapshot?
Updated by Mark Huijgen almost 13 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
Updated by I K almost 13 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.