Multi WAN seems to be poorly implemented
-
Can I check if srctrack is really set properly?
You can check if there is a rule. From shell prompt run:
pfctl -sr | fgrep src.track
-
Also check:
pfctl -stTo see the current timer values.
-
-
The fun thing about git is each commit is a patch. If you have the commit id, you have the patch. If you do
git show 4573641589d50718b544b778cea864cfd725078aThen you get something usable as a patch file.
commit 4573641589d50718b544b778cea864cfd725078a Author: jim-p <jimp@pfsense.org>Date: Tue Nov 15 16:28:45 2011 -0500 Add a gui field to set the source tracking timeout for sticky connections. diff --git a/etc/inc/filter.inc b/etc/inc/filter.inc index 29864df..fdd43b7 100644 --- a/etc/inc/filter.inc +++ b/etc/inc/filter.inc @@ -280,6 +280,8 @@ function filter_configure_sync($delete_states_if_needed = true) { /* User defined maximum table entries in Advanced menu. */ $rules .= "set limit table-entries {$config['system']['maximumtableentries']}\n"; } + if (isset($config['system']['lb_use_sticky']) && is_numeric($config['system']['srctrack']) && ($config['system']['srctrack'] > 0)) + $rules .= "set timeout src.track {$config['system']['srctrack']}\n"; // Configure flowtable support if enabled. flowtable_configure(); diff --git a/usr/local/www/system_advanced_misc.php b/usr/local/www/system_advanced_misc.php index d25c96d..e1da772 100644 --- a/usr/local/www/system_advanced_misc.php +++ b/usr/local/www/system_advanced_misc.php @@ -56,6 +56,7 @@ $pconfig['proxyuser'] = $config['system']['proxyuser']; $pconfig['proxypass'] = $config['system']['proxypass']; $pconfig['harddiskstandby'] = $config['system']['harddiskstandby']; $pconfig['lb_use_sticky'] = isset($config['system']['lb_use_sticky']); +$pconfig['srctrack'] = $config['system']['srctrack']; $pconfig['gw_switch_default'] = isset($config['system']['gw_switch_default']); $pconfig['preferoldsa_enable'] = isset($config['ipsec']['preferoldsa']); $pconfig['racoondebug_enable'] = isset($config['ipsec']['racoondebug']); @@ -102,9 +103,10 @@ if ($_POST) { else unset($config['system']['proxypass']); - if($_POST['lb_use_sticky'] == "yes") + if($_POST['lb_use_sticky'] == "yes") { $config['system']['lb_use_sticky'] = true; - else + $config['system']['srctrack'] = $_POST['srctrack']; + } else unset($config['system']['lb_use_sticky']); if($_POST['gw_switch_default'] == "yes") @@ -190,6 +192,12 @@ include("head.inc"); print_info_box($savemsg); ?></jimp@pfsense.org> -
Should there really be any output for
pfctl -sr | grep src.track ???
And what would this output be?
I can't find anything wrong with my /etc/inc/filter.inc nor the /usr/local/www/system_advanced_misc.phpReplacing "/usr/local/www/system_advanced_misc.php" with the 2.10 version doesn't make a difference….
Did you apply the patch?
I really thought it was working in my 2.0 setup.
-
If pftctl -st shows anything except 0s for src.track, then it's working. 0s (zero seconds) is the default value of src.track.
pfctl -sr wouldn't show it, but it would be in /tmp/rules.debug
-
I currently have a situation in which I'm sure that I'm not having a continuing output over the same interface…
This has been proven by doing a tcpdump on the target server...
A new connection to that same server should go over the same interface.....That's the behaviour one needs in a multi-WAN setup (I believe it should be that way always).
If not, you'll get kicked....I don't understand how one can live with a multi-WAN if all of a sudden it suddenly decides to talk using a different interface....
This is asking for trouble and will result in people getting constantly kicked...
I therefore don't understand why this subject is treated with such a low priority....Unless I'm totally wrong, of course...
But no-one has said that thus far either.... -
I don't quite get how sticky works. If I analyzed correctly, with sticky enabled multi-thread http downloading or usenet downloading won't be lOad balanced at all?
-
It's because you only look at it from your point of view.
If you want multiple connections to the same server, this isn't for you….I'm using pfsense in multi-LAN, multi-WAN environment....
traffic will then be equally spread over the different intranet/Internet connections, but once a source address is using a certain target, I don't want it to switch suddenly.Many targets don't like this and you will get kicked constantly from websites because you're all of a sudden coming from somewhere else....
-
kevindd992002,
When you have sessions(many sites nowadays has) stick must be working to do not get random access erros.
-
But about the stickyness….
Is the SRC/DST relation only on IP-level or is it SRC:port/DST:port?
If the port is included as well it's not really a solution for this problem....
If a SRC-IP/DST-IP relation is established I want it to follow the same route from then on...The WAN-IP's should be considered as endpoints... once the traffic is on the Internet it may of course follow different routes.
-
I don't understand how one can live with a multi-WAN if all of a sudden it suddenly decides to talk using a different interface….
This is asking for trouble and will result in people getting constantly kicked...
I therefore don't understand why this subject is treated with such a low priority....Most sites are smart enough to handle this, through some combination of session tracking/cookie tracking and whatnot. Only certain sites will freak out of the IP changes during a session.
Note that a session is different than a connection. A specific connection will always stay on a certain WAN, as long as the browser/client holds it open. If the browser closes a connection and/or opens a new one, then that one could go across another WAN.
Switching IPs in the middle of a connection isn't that uncommon, consider a client on 3G/Wifi/Wired that could switch between connections automatically in some cases, or if someone roams between two different APs connected to two different WANs.
-
But about the stickyness….
Is the SRC/DST relation only on IP-level or is it SRC:port/DST:port?
If the port is included as well it's not really a solution for this problem....
If a SRC-IP/DST-IP relation is established I want it to follow the same route from then on...The WAN-IP's should be considered as endpoints... once the traffic is on the Internet it may of course follow different routes.
The "stickyness" is between the client IP and a gateway. It has nothing to do with the destination.
So if ClientA makes a connection over WAN2, then everything it does (until its states all expire) will go over WAN2, it will not load balance.
If ClientB makes a connection over WAN1, then it will use WAN1 for everything (until its states all expire). -
Alright, so as long as sticky is enabled I don't need to make a firewall rule that will route HTTPS traffic through my failover route?
I know basic networking but don't understand most of the things you guys mentioned. I use multi-WAN right now by simply making a "route" to have two tiers and directing LAN traffic (except HTTPs) though that route, at least that's what I know how to config in pfsense 2.0.1. When I download through HTTP, say a driver from Nvidia's website, I use Internet Download Manager and it will start multi-thread downloading which will maximized the speed available to me given by my two modems. What will I get if I enable sticky?
-
Alright, so as long as sticky is enabled I don't need to make a firewall rule that will route HTTPS traffic through my failover route?
True.
I know basic networking but don't understand most of the things you guys mentioned. I use multi-WAN right now by simply making a "route" to have two tiers and directing LAN traffic (except HTTPs) though that route, at least that's what I know how to config in pfsense 2.0.1. When I download through HTTP, say a driver from Nvidia's website, I use Internet Download Manager and it will start multi-thread downloading which will maximized the speed available to me given by my two modems. What will I get if I enable sticky?
That wouldn't do what it does now. All those connections from that single client would go over a single WAN. It wouldn't load balance.
-
Alright, so as long as sticky is enabled I don't need to make a firewall rule that will route HTTPS traffic through my failover route?
True.
I know basic networking but don't understand most of the things you guys mentioned. I use multi-WAN right now by simply making a "route" to have two tiers and directing LAN traffic (except HTTPs) though that route, at least that's what I know how to config in pfsense 2.0.1. When I download through HTTP, say a driver from Nvidia's website, I use Internet Download Manager and it will start multi-thread downloading which will maximized the speed available to me given by my two modems. What will I get if I enable sticky?
Thanks for that info. So in essence, multi-thread downloading does not work while sticky is enabled? Is this true for all cases?
That wouldn't do what it does now. All those connections from that single client would go over a single WAN. It wouldn't load balance. -
Thanks for that info. So in essence, multi-thread downloading does not work while sticky is enabled? Is this true for all cases?
That wouldn't do what it does now. All those connections from that single client would go over a single WAN. It wouldn't load balance.A multi-threaded download would still function, but it would not use multiple WANs, so it that really depends on what you mean by "not work".
What sticky does is quite simple: All connections from a client get associated with a single gateway so long as any states exist for the client.
-
Thanks for that info. So in essence, multi-thread downloading does not work while sticky is enabled? Is this true for all cases?
That wouldn't do what it does now. All those connections from that single client would go over a single WAN. It wouldn't load balance.A multi-threaded download would still function, but it would not use multiple WANs, so it that really depends on what you mean by "not work".
What sticky does is quite simple: All connections from a client get associated with a single gateway so long as any states exist for the client.
Oh shoot! Yeah, I get you know. For some reason, I assocciated multi-threaded with multi-WAN.
-
At first I thought that the sticky connections were a bit more advanced. I thought that source/destination relationships determined the gateway it will take from then on, but it turned out all traffic will keep going over the same gateway within that pool…..
According to the text given with the patch it DOES say there's a source/destination relationship that determines this stickyness....
Setting this timeout higher will cause the source/destination relationship to persist for longer periods of time.
Can someone authorative on this matter clarify this?
A bit less advanced, but it should solve the problem I'm having even better…
But ever since going from 2.0 to 2.01 things have worsened...
I now made a rule that https traffic (nothing fancy, just port based) should go over 1 specific gateway.
Ever since I made that rule we're not getting kicked from shopping sites and our own hosting server....But no-one reacted on the test I made, using tcpdump on our hosting server running Plesk 10.4....
I'm making some changes on that server and after applying them I get kicked to the home screen....
I checked the tcpdump and it shows me I'm coming all of a sudden from a different IP.
I checked the system log to see if that interface went down, but it didn't....
pfsense suddenly decided to let trafffic go over another gateway....That shouldn't even happen without that patch....
I'm taking this "tcpdump test" as proof that it "sticky" isn't working in 2.01
I didn't do enough tests in 2.0 to say for sure it was working, but I had a feeling it did.....So, does it stick or not?
-
2.0 and 2.0.1 kernels are identical, would not be any difference between them.