Multi WAN seems to be poorly implemented
-
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.
-
@cmb:
2.0 and 2.0.1 kernels are identical, would not be any difference between them.
OK….
But could you comment on the tcpdump test I did?
Do you agree that it should not be able to happen if "sticky connections" was working and no interface went down? -
Hello,
I can confirm these issues myself. I had to route HTTPS traffic through onevWAN (and one failover), since we had issues with bank sites and Plesk.
The issue persist also in some webmails through port 80, so we ave instructed to access webmail through HTTPS.
For the update of having the timeout field we should wait for 2.1, or can we have it earlier, please?
Best regards
Kostas
-
Hello,
For the update of having the timeout field we should wait for 2.1, or can we have it earlier, please?
Best regards
Kostas
You can have it "now"
http://forum.pfsense.org/index.php/topic,43989.msg229133.html#msg229133
https://github.com/bsdperimeter/pfsense/commit/4573641589d50718b544b778cea864cfd725078a
-
@ptt:
Hello,
For the update of having the timeout field we should wait for 2.1, or can we have it earlier, please?
Best regards
Kostas
You can have it "now"
http://forum.pfsense.org/index.php/topic,43989.msg229133.html#msg229133
https://github.com/bsdperimeter/pfsense/commit/4573641589d50718b544b778cea864cfd725078a
I don't get it, where is 2.1 in that link?
-
It is not about get 2.1, it is about get "sticky connection source tracking time out" option just as it is in 2.1
http://forum.pfsense.org/index.php/topic,43989.msg229457.html#msg229457
-
@ptt:
It is not about get 2.1, it is about get "sticky connection source tracking time out" option just as it is in 2.1
http://forum.pfsense.org/index.php/topic,43989.msg229457.html#msg229457
Ok, I misunderstood.
