Sorry for the delay in responding.  Basically, the load balancer in pfSense is a layer 4 load balancer (it only works on IP).  Pound is a layer-7 LB that is able to understand the contents of the packets and able to decrypt https traffic prior to LB'ing.

I just read your question. I think your problem is the same as my problem at http://forum.pfsense.org/index.php/topic,15910.0.html. And I'm still in searching for the solution.

It's about talks between two LANs, but one LAN (your case is wareless) its gateway is not OPT1 interface. I guess we may need some NAT settings, but I don't know how.

If you have solved your problem, please tell us your solution. Thanks.

@GruensFroeschli:

The loadbalancing is connectionbased and doesnt actually sum the bandwidth of your two lines.
Are you sure you've set up the loadbalancer correctly?
At least some of the time you should get 2mbit down.

i'm sure with my setup loadbalancing and failover is right. By my test, unplug the WAN 1 there is no stop connection in the LAN, and everything is running well. When WAN 1 and WAN 2 is online, i can see the speed increasing (in my download manager) is sum of two WAN for international connection, but for local connection between local ISP is going down??

regards

@Cry:

A bridge is for joining 2 physical networks together with the same IP range.  If you're using different IP address ranges then you don't want to bridge.

damn it.. I knew that.. sorry..

After you create your loadbalancing pool you will need to edit the firewall rule on LAN.
Set in the modified rule as gateway "name_of_your_pool".

If two of your WANs have the same gateway you will only be able to use one of them.

However this is about OUTGOING traffic.
Inbound traffic to servers does not need any loadbalancing.

Hi everyone,
Some new information. I made the test to disable all filtering rule (so i use pfSense as only a router) and all works fine… I was looking after the way to force packet filter to use the static rules instead of creating rules with the default gateway... I finally find where the rules are written (file /etc/inc/filter.inc, line 1545) and also know now why the routes are ignored :

/* do not process reply-to for gateway'd rules */ if(($rule['gateway'] == "") and ($ri != "") and ($rg != "")) {       $aline['reply'] = "reply-to (" . $ri . " " . $rg . ") "; }

So, as i can't specify the gateway i want in the rule creation form, i always am in this case : system routes are ignored (final rule contains a 'reply-to' instead of a 'route-to') Here's a solution (but certainly not the best one ;)) : comment those 3 lines makes pfSense to use system routes.
If anyone find a proper way to do this, it could be nice :)

edit : I make the changes on pfSense 1.2.2. I did not test with other versions…

jhowel,
Check your firewall settings. They should look something like the attached.
With those settings I am able to ping any host on the Wifi net from the LAN. Don't forget to enable ICMP pass though on the hosts to ensure the local firewall does not block ping.

EDIT: Attached is the GUI config of my Wifi so that I can 'talk' to LAN hosts.

lan_rules.jpg
lan_rules.jpg_thumb
wifi_rules.jpg
wifi_rules.jpg_thumb

Not a strict requirement, but they will be running software that will be licensed to the external IP, so it would make life a lot easier.

Try with a dns rule on top

Thanks! This is very useful.

The URL used for pkg_add -r is based off of the machine's FreeBSD version. Since the one you are using is based off of 7.0-RELEASE, that's the package set you can get.

As you've seen, you can override this by specifying the whole URL, but there may be some cases where that might not work properly. It's probably better to let this happen on a case-by-case basis than to always pull the new packages.

You are seeing it backwards.

You don't want to get internet to LAN but LAN to somewhere. Therefore you need to configure an access rule from LAN to '*' or whatever suits your needs on the LAN tab of rules.
Outbound NAT is done automatically unless explicitly done by hand.

If all this doesn't help you need to provide more infos on your setup.

I resolved the problem. It was a wrong static route on my desktop PC.

Regards & Thanks
Thomas

Anyone?

Another option might be GRE, unless
a) I don't understand GRE properly
b) my ISP filters that
c) there's no way to bypass for a gateway route the generic restriction that a GRE routing entry can't be more generic than the link it uses to be transported over (which of course in the case of a gateway rout, it would be).

Personally, I don't care WHAT I use. I can put a pfSense (or Vyatta, if it has to be) box on both sides of the link. Anything that's in my budget (i.e. free software and $150 nettop on each end) is an option as long as it can

route the class-C network through some sort of logical tunnel of sorts such that the gateway is logically at the colocation provider, while it's physically here in my home there's a possibility to have a guest LAN bypass all of that, and via NAT access the internet directly through the ISP without detour of the tunnel I can have a few additional private-LAN to private-LAN IPSec VPNs to clients and friends' LANs

Ideally, it would also allow
4) policy based routing, such that end-user web traffic, downloads, etc. use NAT and don't do the colocation routing detour
5) VoIP PBX (like FreeSwitch module in pfSense).

My problem is, the current setup works, sort of, but not trouble free, but it works (it hangs itself rather often, needs resetting on a regular basis, the box sometimes gets overloaded etc.).

I'm not in a position though to spend $300-$500 all said and done on hardware and equipment installation charges at the colocation provider, just to figure out that it won't work; the whole operation is only meaningful if it moves me from "sort of works" to "works" ;)

I wish there were someone who could answer a question like that…