Dual wan and failover with dynamic ip address
-
Hold on, didn't read the second page. Looks like we want to split the server side load balancing and outbound load balancing.
I'll have a look at this tomorrow.
-
GotzBoost. I tried your page but it doesn't work yet. It does not appear to set the correct interface name via javascript into the poolbox.
Are those 2 files in the pfsense.rar really the only edited files?
-
No, my files are an addition to sbyoon's modification. So apply his mod first, and then mine.
-
Well, it worked fine after refreshing everything. I think the javascript got cached. Because it worked for others the first time.
I have up-to-date patches available on my site. http://iserv.nl/files/pfsense/slbd/
The code is already committed into CVS. Releng_1 is under discussion.
-
What is Releng_1? At the moment the drop down for ping/gateway IP get's set to what ever the IP is at that point in time. It doesn't get updated when ever the WAN/OPTx gets a new IP. I was going to look at how sbyoon modified the code to update the IP upon a DHCP renew and make it allow to do the same for the ping/gateway IP.
Even though it's preferrably to find a hard coded IP out in the space to ping, as in some gateways don't allow you to ping them. As it was in my case.
Or here's another better idea, don't ping somthing to see if the net is up or down. Rather do a trace route with a max hop of ~3(let this be configurable), if it comes back with ~3 hops at least, then the interface is up. That will do one of two thing, make sure that you can actually get to the net and not just your ISP, and also cut down on unwanted/needed ping traffic.
Case in point, Time Warner had a router go out >:( (for about 48 hours :o), I could get to any of TW sites, but not the net. So, half of my traffic that was going out my cable modem was failing and the other half that was going out my DSL was OK. If the trace route was in use, then my cable modem would have been automaticly set to down, and fail over to my DSL.
-
That's a slbd issue and currently not feasible to implement. The slbd checks need to be fast and light, and traceroute is neither. Furthermore I have seen far more routers block traceroute then I have them seen ping.
I'll have to look at the gateway ping implementation. Although I think that is handled by the rc.newwanip code and the filter.inc fixes syboon already applied.
For all intents and purposes, a router should never block ICMP traffic is that is integral to the operation of the tcp/ip protocol.
We are currently testing multi interface dhcp with the new dhcp clients but at this point in time it is not working just yet.
-
Ok, let me rephrase that. The router blocked ICMP traffic to itself, not all ICMP traffic going through it. And yes they do this quite often for security precautions. In some of the CCNA classes I've been in they've even tought that as a rule of thumb. "The only thing a public router needs to do is route, don't let it waste's it's time on anything else. And the last thing you want is a router that crashed from a flaw overlooked in some TCP stack from a ping."
Security: Rule of thumb, block everything, then only open what's needed.
What are you testing with multi interface dhcp? I have it now, with this fix, and it's working perfectly.
-
multi dhcp specifically in the later snapshots > 20-12-2006.
1.0.1 should work fine in that respect.
-
I have put the modified version of the files on my site so other people can easily test them.
http://iserv.nl/files/pfsense/slbd/those correspond to the files.
/etc/rc.newwanip
/etc/inc/filter.inc
/etc/inc/vslb.inc
/usr/local/www/pool.js
/usr/local/www/load_balancer_pool_edit.php (use load_balancer_pool_edit2.txt )Cheers
-
Is there anything diff about them then what is already up? Or just a combination of all the patches stuck together?
-
A combination thereof but, uptodate with current snapshots.
-
It's been merged into RELENG_1 and should show up in a snapshot soon. Whenever soon is.