Wow, the 520. I haven't seen one of those for years. Those were made from pretty standard components. If it were me, I'd try and load it with pfSense just for the retro feel.

Depends on the "shop" software.  The inbound load balancing will track session state but if a customer sits idle for long enough the session will expire.  You could set very long session timeouts but there might be some functional limitations to that depending on how much traffic is being handled. 
  However, if the backend was designed to be in a web farm then it should already have functionality for replicating sessions across the various servers, (usually done through a separate central database that all can access directly).  And if it can't, well, find the developer and ask them why the heck not!  :)

Could also set up an extra VM with Apache configured as a relay.  Not the "cleanest" solution but it's not bad and the added latency is minimal.

Having a similar issue but only with DNS traffic.  NAT reflection is working fine for other ports (TCP) that are NAT'd into the DMZ, just not UDP port 53.  Have set rules to allow traffic in all directions internally and can ping in all directions against all interfaces of the FW, clients and hosts.
  Assuming it's either a UDP-specific issue or relating to DNS settings.  All DNS forwarders etc are disabled, only DNS services of any kind are on the servers in the DMZ and they're working if the LAN connects directly to the DMZ IP and also if connecting from the outside via regular port NAT.  Only the NAT reflection isn't working.
  (Split DNS unfortunately isn't really an option for various other reasons.)
  Anybody have DNS working via NAT reflection?

Thanks for the tip! :)  I will try that

MultiWAN failover works fine but you have to be very careful about your monitoring IPs.  See the "If a connection is red (down) for no apparent reason" section of this page in the wiki:
  http://doc.pfsense.org/index.php/Troubleshoot_Outbound_Load_Balancing_Issues
…it applies to your issue as well.

Might help http://pfsense.site88.net/multiwan.html

Second messr Gruen, you MUST use different monitor IPs for each WAN link or you will have weird results along the lines of what you're describing.  (Not that I'd know from experience or anything :).
  Also, as a crucial sanity check, use the diagnostics ping test to the monitor IP with the respective interface selected.  You'll see notes saying that the ping test doesn't work reliably in multi-WAN and this is sort of true, but the key here is that the monitoring system is simply doing a ping as well! 
  Have seen some very illogical pseudo-failure modes that were resolved by using the diag ping to figure out which monitoring IP was "appropriate", (i.e. worked at all), for each WAN link.  There was no rhyme or reason to what did or didn't work but they were at least consistent and the system is rock solid once you've sussed out the right combination.  And having gone through the process on quite a few of these now I can safely say that it is necessary!  (At least as of v1.2.2).
  Also a tip - don't use the gateway as your monitor IP on any of them.  Too easy for the ISP to be having routing issues and you can't past their core so the link is functionally down even though you can reach the gateway.  So for each WAN link be sure to pick a (diag-pingable) IP which is outside of your ISPs network.

It will cost you much more in time trying to get the load balancing "even", (not to mention potential multi-NAT and routing annoyances), than to just buy some dual or quad port NICs. 
  Not to mention if you're needing so much bandwidth one can assume you're running something fairly important and you really need a redundant failover solution anyway. 
  So rather than trying to daisy-chain your pfSense servers, instead set them up as a CARP cluster using qty-4 quad-port NICs, (2 for each server).  I.e. pull out all but one of the single-port NICs in both servers, so you have qty-9 ports total per server.  Then configure them as a standard CARP failover, (the 9th port is used for CARP sync).  Et voila', "normal" load balancing plus redundancy and no headaches. 
  Actually could/should justify qty-3 quad-port per server so you some spare ports for future use, DMZ, etc.

Nope, I gave up and am just running it over my primary WAN  :(

-M@

Naturally it isn't this easy.. I made changes to the GATEWAYS file in the /etc directory and once I enable RIPv2 on the pfsense firewall, it overwrites the GATEWAYS file I had just modified undoing the changes I made to the file.. Am I not modifying the rip commands in the correct place?

@Burken:

So if my VLAN 10 sends DHCP broadcast the Switch will TAG the broadcast packets as VLAN 10?

Not quite, pfSense tags the frame, and that tells the switch which ports should 'see' it. Once it knows what port the frame will be sent out, it checks if it should be sent tagged or untagged (this is the 'egress' option). Since your ISP port was untagged in my example, the tag would be stripped at this point. Your ISP never sees the VLAN information, and when the ISP DHCP server replies, the reply is not tagged. When an untagged frame arrives at a port, the switch assigns that frame to the VLAN you set in PVID for that port. This is the problem with my example - even though you have separate VLANs for traffic leaving pfSense, the return traffic from your ISP will all go to one VLAN.

So GruensFroeschli comes in with some good thinking to solve it. The extra switch and cables in his example gives you a way to receive the replies from your ISP through separate VLAN-switch ports, so you can assign them the proper PVID. Obviously it wastes some ports and you need a cheap switch, but I think it should work. However be careful when you're configuring this, with the switch<=>switch links you could easily end up with MAC addresses appearing on multiple ports which will confuse the heck out of the 'dumb' switch and could also result in switching loops and other oddness. Each VLAN switch port should be assigned a VLAN, that should be its PVID and it should be the only VLAN it is a member of, with untagged egress. Though really, given the number of switch ports this solution eats, it's easier and maybe cheaper to just add physical interfaces, unless you have half a dozen free ports on your VLAN switch.

Oh, sorry.. I thought you had two wan interfaces as you poseted this message in this Forum. ProxyARP should work in your case.
can you show you rules ot OPT1 interface and NAT page?

@Eugene:

Why don't you ask the person who told you this advice? especially it's interesting to hear his/her answer to bonus question. -)

he were using that script…

If i run the whole script it works 50%.. sometimes kills my load balancer.. but i get the virtual nics in pfsense. and sometimes i even get them dhcp ips... but it seems to buggy... so i went to ebay and buyed intel pro 1000 mt. :)

I did add the DNS rule as shown at site88. It did not allow for resolution of DNS until after the static route was established. I also have a rule at the top of the OPT Lan ruleset explicitly defining the Lan default gateway, but to no avail. What puzzles me is that I can bounce a ping out to the next hop up the line (the provider's router in our building, as defined in the OPT Wan interface), but no further without an explicitly defined static route. This goes for IP addresses or hostnames.