@cpthk:

The request first arrives at the LAN interface, but shouldn't LAN interface pass the request to WAN ? (just like any other website you go to, those requests get past to WAN and to ISP) So the WAN should also get the request. Is this not true?

What request?
1. Suppose an access to the IP address of the DMZ server. That will go out the DMZ interface.
2. Suppose an access to the IP address of the hardware interface that is the pfSense WAN interface. That addresses the pfSense box itself so goes no further - it does not go out the WAN interface in the hope that the upstream router will loop it back and hence it is not received (seen by the receive input) by the hardware interface that is the pfSense WAN interface.

Does that answer the question?

Pretty much what I said above then.  ;)
Glad to know I wasn't wrong.

Steve

Very interesting comments.

wallabybob, I don't think that iperf is the bottleneck. We did several tests running iperf as both the client and the server on machines and were able to get performance that was very high. I don't have the numbers handy from the workstations that we were testing on, but I was just able to get 2.43Gbps running both the iperf server and client on an old Atom 230 server that I have handy. We also did the test with the workstations on the same sub-net/VLAN, taking the routing performance of the pfSense box out of the equation, and were able to get much better numbers.

idmud, thanks for the suggestion. I'll give that a try when we have a spare moment.

cmb, I understand the issue with a single source-destination pair and LACP. In all cases we were using at least three pairs of machines, with several tests using eight pair. Your point about the switches is well-taken and probably spot-on. I may PM you regarding suggestions for better switches. (I have some money left in a budget for experimentation, only a month to make use of it, and switches had my attention anyway.)

I've used a similar 802.11n TP-Link wireless access point and it also had that.  They call it WDS in the configuration, but others prefer to call it 4 address frame mode to distinguish it from what is typically called WDS.  It transmits an additional MAC address in the packets that allows bridging to work, but the access point on the other end must support it (and accept it).  The great thing about this mode is that it works with WPA/WPA2 and I think anything else that exists or will exist, since it is simply a normal connection with additional data in the packet headers (or something like that).  This particular mode is a Linux implementation and is compatible with any Linux-based device that uses it (I've used this mode to make a bridge with a TP-Link TL-WA901ND and another AP running OpenWrt, for example).  FreeBSD has a similar mode, but I've heard it is incompatible with the Linux implementation, unfortunately (so if pfSense eventually supports it, it will only work with other FreeBSD-based devices and not Linux-based devices).

There was a whole big debate/thread on that on the mailing list - feel free to peruse the archive for the results.

Ok, here: http://forum.pfsense.org/index.php/topic,51264.msg278165.html
;D

@jimp:

As I said above, it probably will not work for PPTP.

First, because those interfaces are not selectable for/by UPnP, and second, UPnP works with broadcast/multicast and that traffic doesn't carry over PPTP, if I recall correctly.

You are correct, broadcast/multicast is not carried over PPTP :(

Thanks, I'll try that as soon as I can.

OK, so ive just tried to bridge LAN to WAN (by bridging the interfaces) and I am unable to ping out on a device that has a WAN IP set static. Im guessing its not as easy as just bridging the interfaces? any links on what to do or how to bridge them would be appreciated.

I think part of the problem was that my ubuntu session was a VM and had virtual box at the end of my computer name.  I figured out how to change that, added a new user on the webconfigurator, generated a new key pair, pasted the public key into the box, and everything worked great!

Thanks for the suggestions everyone, the key is now working perfectly.  Now if I could just figure out how to fix my one server where the pfsense update to 2.0.1 didn't work correctly.  :(

Two cores/CPUs is about the most that gets you significant benefit today. In a year or two, that'll be different.

If you have access to a machine with a matched or faster connection than yours outside of your lan, you could try iperf.

thank you for your infomation.

It won't block it because the server has probably shifted the connection to a different port.

You will need to install an IP block that blocks her access to the Internet for probably 5-10 minutes at 5pm, long enough for the server to timeout and kill the connection.

I would set up an infinite (reserved) DHCP lease so that her system always gets the same IP address.

@luke240778:

On Status > Gateways, the new one says online.. BUT computers on my LAN can ping 8.8.8.8 and so on, but can't open any www. sites, which to me means DNS problem.

Unfortunately humans often translate a browser error message to "can't open site zzz" with significant information loss. The browser error report is almost always more informative than "can't open …"

The problem could be upstream congestion, no access to the name server, broken upstream link between you and the hosts you attempted to access, ... The browser error report will likely give a clue to help identify a specific cause.

@luke240778:

A second attempt and different results.. Gateway status says Online, but not even pfSense can ping it via IP or ping anything else on the www.

As above, giving the ping command and its response is almost always more informative than "can't ping".

Well after some search i saw that using mikrotik and sending some attributes to mikrotik as mikrotik-rate-limit works well for users..i want to use pfsense though..maybe some attributes can solve my problem?

Your last point was correct. Some sites enforce an IP:login relationship. If you load balance HTTPS, then those sites will fail if any part of the connection goes across the "wrong" wan.

Use a failover group for HTTPS instead of load balancing, or perhaps try enabling sticky connections under System > Advanced on the Misc tab under Load Balancing.

You should not have the source port set to 443 in your timed https rule. Set it to '*'.

Steve