Multi WAN seems to be poorly implemented
-
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.
