The load balancing mechanism changes between 1.2.3 and 2.0 and since I have only used inbound load balancing in 1.2.3, I will restrict my answers to that. There is not a way within the load balancer to isolate specific connections to a specific server, connections are load balanced using a simple red robin setup.  The better way to solve this problem is to ensure that all your web servers are sharing their session state information.  There are a number of solutions for doing this which are off-the-shelf and fairly easy to configure depending on your needs.  I recommend spending some quality time with google to find the solution that best fits your needs. The load balancer will only work in a NAT'd solution.  You cannot use the load balancer in a bridged configuration.

@dreamslacker: @silvercat: Another issue is the public IP. Is having 200 users on a single public IP a problem? I don't think 1:1 will be possible from the ISP, but we might get a number of IPs available to us, is there a way to handle this intelligently? Not an issue with most games EXCEPT Battlenet games.  Blizzard has a lock on Bnet hosts for 6 hosts per IP.  Your gamers can game but hosting games are an issue.  Plus, you need to set different game ports and forward them for each game host. Using a Class B or Class A subnet would solve your problems with address space. With the right kind of money, ISPs can be very willing to offer help.  LOL..  Just last year, we had a Dreamhack over here where the ISP opened up a 40Gbps symmetric link direct to Sweden for us and provided all the network routers required so that we could have "LAN" games played between Sweden and Singapore. I doubt people are going to host games and expect their friends (those not in the LAN) to be able to connect - however I'm considering letting home users to be able to connect to the LAN from their homes using VPN, to be able to virtually participate! =) Ahh, the power of pfSense! @GruensFroeschli: We used pfSense for all the LAN parties i helped organise in the last 4~5 years. While we didn't use blacklisting / Proxying, we did use the Captive Portal. Generally we didn't allow any internet traffic except when someone needed it with a good reason. (eg update their antivirus software). For this we created a time-limited user (30 minutes). To solve the problem with people comming in, setting up their computer and just connect to the network, we used VLANs. We once had a problem with a samba virus infecting everyone. So we made it our policy to only allow people which have an up to date anti-virus and can show an active virus scan within the last 24 hours. We enforced this with VLANs. Every port on all switches were in their own VLAN. All ports in a public VLAN. The PVID is initially set to each ports private VLAN. On the pfSense we bridged all VLANs (as many VLANs as there are ports) and blocked all traffic on all VLANs with as destination something RFC1918 (but allow all destinations on the internet). After someone of the staff verified their computer and checked if they payed, the PVID of the port on the switch would be moved into the public VLAN. (For this we used a python script with pyCurl) This ensures that no communication with the local LAN (except the pfSense) is possible, but at the same time everyone gets an IP which will later actually be used and allows them to access the internet if they need to install/update their antivirus. Might be a bit overkill, but it ensured that we never had any virus problems again ^^" However if you're not familiar with VLANs i wouldn't suggest a setup like that to you. When is your party? I would suggest to set up a test network at least 3~4 weeks in advance with all your servers you're going to run and test everyting. Especially if you want to run the traffic shaper this will take some time to tweak until it runs the way you want. Otherwise, keep it as simple as you can. Since most people will come with their computer configured to get an IP via DHCP, you could set up a DHCP server to server the 172.16.0.0/16 subnet, but the actual network for the party will be 10.0.0.0/8. Assign the IPs to the people statically. Something like 10.Room.Row.Place/8 (eg, Room 1, Row 2, Place 7 would have 10.1.2.7/8) (This is actually the system we used before we used the pfSense). This has the advantage that you know out of the IP address the place where someone sits. For this we put on every place a small sticker with an explanation how to change their address, subnet, gateway, etc and what the IP of the current place is. I don't think we'll use such an extensive VLAN-setup for one. However I like the static IP idea. If you're too stupid to set up your IP manually, then chances are you're too stupid to keep your antivirus up to date, thus generate problems. We've decided to do this June 2nd, and the crew is planning to do a "bootcamp" prior to the event to test the equipment, setups, games, servers. Guess we'll be testing the new RC of pfSense 2 as well =)

The serial cable did the trick. Thanks a lot! /Hans

Thanks for all the answers. Also think I will be ok to live without setting up the cron job. My switch is clearly online if i am connected to my network.

@artgug: Assign a new "interface" to Pfsense with 192.168.1.1 which would "regulate" the traffic between 192.168.1.0 and 192.168.0.1 using the rules, so only specified traffic would be shared between both Ip spaces. FYI that will never work the way you want. Anyone could simply change their IP into the other subnet and bypass the rules. You also can't do DHCP for two subnets on one interface this way. To do this properly, and securely, you either need another NIC and another switch, or a proper switch that supports VLANs.

There is not a lot of traffic between the servers in the DMZ. If that were the case, I would suspect that having a single DMZ network connected to a switch would be the best approach. However, there is a lot of traffic between the LAN and the three servers. I have given myself a few weeks to get the new box online, and I might try both configurations. Might even try trunking a pair of interfaces (link aggregation) to both the DMZ switch and the LAN switch. I really like all the options that pfSense offers. Although, all the options might get me into trouble! Thanks again! Mark

I think you just need to allow multicast traffic to pass…. Me, I just leave the TV boxes connected direct to the 2wire box...

RE: questions at the end. Will Blackman of BSDTalk was nice enough to make audio recordings of each of the talks, so you may be able to get a better idea from there. (URL provided below.) Glad you enjoyed the video. http://www.nycbsdcon.org/2010/

I see. Cannot wait for 2.0 final release (aka stable) !

You should start by upgrading to 1.2.3 release, since there's no point in running a release candidate this long after the final version was released. Then try connecting a console and use that to reset the password. Then you'll also be able to see if there are any errors on the console that might explain your problem.

OpenVPN should be safe as well. The load balancer pools do not affect any traffic by themselves. And the gateway settings on the LAN rules won't affect your VPN traffic since it's not entering the firewall on the LAN interface.

The logs would also show problems with the WAN interface. It could be your ISP or your ISP connected device (cable/ADSL modem etc)  - what about other connections to the Internet?

@rooster: Thanks! Got a few more general questions if anyone has the time/answers. I will be reading the documentation, and hopefully have more challenging questions soon enough. What about load balancing by port? That is, does pfSense have the ability to designate a portion of bandwidth to say VPN connections, FTP, http? Inbound and outbound? What about outbound traffic from the DMZ going out as the same public IP as the actual server? That is, right now with my set-up of IPCop, all outbound traffic goes out under one IP address (Firewall IP address) rather than the “true” public address for that server. There is no real 'DMZ' in pfSense;  You simply need to do a 1:1 NAT for the server.  Alternatively, you simply use a firewall rule to force all traffic from the LAN client(s) IP(s) to the specific external IP you want to use.  Most of the 'features' you need are basically effected from Firewall rules. Even the traffic shaper rides on Firewall rules to assign traffic.  =) Get your firewall rules done right and your problems are all solved.

It was actually an issue with an internal ACL. Nothing to do with pfsense, sorry for wasting your time! :(