..when I unCheck 'use sticky connections' both WANs are used and the transfer is about 50/50… so it is good, but i have to use 'sticky connections to not let to drop https connections /or  is there any other way ?

Try not using proxy and see the difference

If you have a fresh install, you will not be able to access the WebGUI from the WAN. You need to create a rule to do so. If you are, then the LAN is possibly not setup correctly. I am not sure about the vpxnet3 support in freebsd. Consider switching them to the e1000. I don't even see in my ESX 5.5 where you got it to support AMD Lance devices anyway. Did you choose FreeBSD 6 or earlier? pfsense 2.1 is based on FreeBSD8.3 and 2.0 is based on 8.1. The new 2.2 will be based on FreeBSD10.

The default rule on WAN will block everything. You will need to add a rules to allow port 80/443 to WAN address if you are going to want to access the webgui from WAN. *** This is not recommended! *** This is a huge security problem if not in a lab or test environment. If you want to manage the FW from a remote locale, consider using VPN.

@jimp: Your IPv4 case only works by accident. It's not supported to use them in that way. Two interfaces in the same DHCP scope may pull multiple addresses but the routing will be a mess in reality. You can't count on the same broken scenario to work in IPv6 because it just happens to work in IPv4. The documented/supported behavior (and by consequence, limitations) are the same in this case. But… but everything works in this broken scenario just fine. :'( The gateway in the rules for some workstations is set to either one of the WANn_DHCP gateways. -> working as expected: Workstations will just use the gateway I want them to use. The gateway in the default catch all IPv4 rule is set to the load balancing gateway group I created from the WANn_DHCP gateways. -> working as expected: All other workstations will use the WAN0_DHCP gateway unless an alarm has been triggered. When downloading multiple files or a single file in multiple chunks the bandwidth is being aggregated. How does one see if the routing is indeed a mess, when there's no problems? Traceroutes don't show anything unusual.

Thank u so much! I had a knot in my brain!  :o As i read "asymmetric routing" i get a red head! ;) What a novice error, i realy feel  feel ashamed.. The Solution was:  of course builing a separate transport-network between Cisco-Stack and Pfsense, 172.30.29.0 /26 thanks again, and regards oli

I would find this useful too.  All of the systems I use have a single gateway.  WAN redundancy is handled upstream.  I leave gateway monitoring enabled for the RRD graphs which are very useful for ISP issues. I currently have the System: Advanced: Miscellaneous / Gateway Monitoring 'State Killing on Gateway Failure' checked which means it disables state killing on gateway down. What else happens when the gateway goes down?  I have seen the interface go down and up quickly and have assumed that was a switch  issue but I am not sure if the interface actually went down or if something in the gateway monitoring is doing that when it can't reach the gateway.

The list above is not perfect. those are some common sites that we know needed US IP to browse or stream properly no sniffing needed. hulu seems it checks your ip by huluim (not so sure about this) as some sites appearing in the lower right when Firefox tried to open the site.

Is your WAN switch managable? If so you could setup a couple vlans on your WAN NIC, and proceed to setup the switch to handle the "multiple" type of setup.

Yeah, although booting seems to reset the manual setting, so not a good solution.

Hi All, responding to my own post,sorry. After doing some more digging,,I am almost positive it is the ip phone companies router/switch that may have either shot craps,or the config dropped,,,some how..I have no way of getting into this devcie,so,I will not know anything for sure until Tuesday of next week. Long sory short their router has some static routes to our pfSense router to get out to the inernet. Just wanted to post this,to give a thumbs up to pfSense being stable,main reason. This particular router had an uptime of 512 days! until I rebooted it today. Thanks, Barry

You already got an answer in your "other" post https://forum.pfsense.org/index.php/topic,72634.msg396239.html Please don't open multiple threads asking the same question ;)

@phil.davis: Sounds like you will have asymmetric routing - an ordinary LAN client to LON packet goes: LAN client->relpfSense->vpfSense->London a reply packet goes: London->vpfSense->LAN client on the reply, the vpfSense is on LAN so can deliver the packet directly. realpfSense does not see the replies, and so the state dies after some seconds. Try: a) System: Advanced: Firewall and NAT - Bypass firewall rules for traffic on the same interface or b) Switch to Manual Outbound NAT and add NAT rule/s on LAN to NAT traffic with source LAN destination LON+NY to the LAN IP - then vpfSense will see realpfSense LAN IP as the source address of the packets and send the replies back there, to be unNATed and delivered back to the LAN client, removing the asymmetric routing. Phil - this seems to be spot on! I've just added the NAT rule to my physical pfsense and so far no RDP drop out! To say I am chuffed is an understatement. I've been putting up with RDP drops for months, if not a year. Thank you so much for your help! t.

Basically inter-LAN and inter-vLAN routing is done automatically. You only need to create rules to allow traffic. If you want those to go to the internet, then you need to make sure that outbound nat is working correctly also.

That cron entry starting "1 1" runs at 01:01 each day - only once per day. For every minute you want: */1  *  *  *  *  root /usr/bin/nice -n20 /etc/rc.dyndns.update

even if you do, somehow, manage to get this working - it'll be a nightmare; if not now, then later. bite the bitter pill and go to a sane subnetting scheme my 2 cents

Diagnostics->Packet Capture on the OpenVPN tunnel interface, looking for port 53 (and/or the IP address of the external DNS server it is supposed to be using) should show the traffic from DNS Forwarder doing the lookups. DNS Forwarder does caching, so on the client do "nslookup" of various different *.uk sites so DNS Forwarder has to go externally to look them up.