You should be able to use a domain override in that case, that rule doesn't apply to domain overrides. That's much safer than just disabling the DNS rebinding checks entirely, though you can do that under System>Advanced if you really want to.

Have I got this right? Just override all DNS queries to the problem domain to...some outside DNS server. I can give that a try in a hurry.

DNS rebinding! That's the term for it. I knew I'd read about it somewhere. Probably in The Book.

No, I'd rather employ the work-around than disabling DNS rebind checks. Thanks for the tip.

For silly reasons, I need to allow DNS queries for an "outside" domain to map to an internal IP address. For example, blah.bloo.com (which isn't ours) might come back as 192.168.1.7. It seems like the way pfSense configures dnsmasq doesn't allow those sorts of queries, which seems sensible from a security perspective.

Does dnsmasq do this sort of filtering? Anyone have a suggestion (other than "Don't do that!")?

By the way, we think the problem is just a cabling issue. I remember wanting a couple more inches of cable when I hooked it up...three weeks ago.

Yup. It is crude. The model of switch our ISP uses is one of the cheapest that Cisco offered at the time (but it's still Cisco, so it probably costs three times as much as our pfSense boxes). The switch isn't capable of acting reasonably (ie. using a small buffer and giving priority to packets that are more important from a protocol sense). The result is we get decent throughput right up until we trigger the policer, then everything falls off a cliff. With a small number of users, each TCP stack throttles itself somewhat reasonably. Unfortunately, at our sites with many clients, this isn't the case.

Doing traffic shaping properly is one of the big two reasons we looked into pfSense. Fortunately for us, our ISP increased our cap to the point that we haven't had to worry about the problem. As demand increases, we can expect it to return soon enough.

I definitely understand what you are suggesting, but it's not the outgoing traffic that's the problem. It's the incoming. However, I believe this is within pfSense's capabilities as well. Looking into this has been on my TODO list for about 18 months.

[...]
Really? That seems incredibly crude.
You could easily test this theory by using pfSenses traffic shaping features to limit the outgoing traffic to, say, 20Mbps. Pretty sure that does not just through packets away at random! 

Steve

Short story: In trying to troubleshoot a problem with a (very) remote pfSense router, I managed to do something to lock up the pfSense webConfigurator. Luckily, I was able to access the pfSense router via SSH, both as myself and root. Restarting the webConfigurator didn't help. Restarting the pfSense router worked (but man was that nerve-racking).

Long story: We noticed really bad downstream throughput at the site yesterday. Narrowed down the problem to something creating a significant draw locally (ie. a P2P client), a bad cable, failing NIC, or a failing port on the ISP's switch. To eliminate a local source of the downstream demand, I began shutting down local interfaces and using the firewall to block all traffic from the remaining local interface that wasn't from a test machine. (The symptoms of the problem persisted despite everything being down, so we are thinking this is a cabling issue.) This was all done very carefully as it is a 3 hour drive to the site and there was freezing rain between here and there. Some of the roads are currently closed.

All of a sudden, I couldn't access the web interface. This was at least a minute or two after I changed anything, which always make me look at DNS, but I really have no idea. After a short freak-out, I noticed that I could SSH to the single remaining interface on the local side. I restarted the webConfigurator but it did nothing. Restarting the pfSense router did the trick and I began

This is the first time the webConfigurator has locked up on me and I'm a bit shaken. I'm about to confirm that we can SSH into all of the pfSense routers across our WAN in case this happens again.

Just thought I'd share with the hope that it might help save someone else who puts all their faith in the webConfigurator.

Status -> Interfaces will give you error counters for your interfaces.
[...]

And there you have it:

   In/out errors: 12962098/0

I'm thinking we have a bad cable, a bad NIC on the pfSense box, or a bad port on our ISP's switch. Very interesting.

EDIT: Actually, I'm not sure that it's a bad cable, NIC, or port. I'm thinking that we are trying to draw in too much traffic and the policer is throwing away packets. Because of the way Cisco's policer works, throwing away packets indiscriminately, the amount of goodput drops well below what it would otherwise be.

Thanks Wally, that will be the first thing I look at when I get in.

Woke up early this morning mulling this problem over. If we didn't have freezing rain all the way between myself and the site, I'd already be making the (long) drive.

The ISP swears that we are running into their policer. Basically, if we try to draw (or push) more than a certain rate, the policer starts throwing away packets. That rate is 24Mb/s. The thing is, I'm only seeing a small fraction of that on my side. If the policer isn't smart about throwing away packets (ie. it throws away SYN packets), I guess it could be causing a huge loss of...goodput. But I'm at a loss as to how I would go about detecting this sort of thing. Hopefully the interface error counters will give me something useful to look at.

Luckily, the site is empty today, so I can mess around with little risk of annoyed users.

At each of six locations, we have the following setup: Our ISP has a Cisco Catalyst switch on our premises that we plug a pfSense router into. Except for one of our locations, this works great. At the problematic location, incoming traffic is only about 1/6th of what it should be (3 vs 24Mb/s). The ISP swears that the problem lies on our end of their switch and that they are seeing dropped packets. I'm trying to confirm that fact.

We plugged a workstation into their switch and found that incoming traffic tests went back to what we would expect (24Mb/s). So now, I'm scratching my head. From my end, looking at the pfSense traffic graphs and such all I see is 3 Mb/s getting through. I see no dropped packets. But I wouldn't know where to look for drops due to badly transmitted traffic.

The weird thing is that the upstream traffic is fine and outgoing traffic benchmarks at 24Mb/s, just like it should.

Any ideas? All I can think of is a bad cable, but I'm a three hour drive away and it just started snowing.

Except for this problem, pfSense has been working very well for us over the last 18 months.

By the way, we're running pfSense 2.0.2 on fairly decent Supermicro hardware with two built-in NICs plus an additional dual-port NIC. All the NICs are Intel. At least two of our locations are on identical hardware, but running pfSense 2.0.1 (2.0.2 is on my TODO list).

cmb nailed it...twice. In my case, I don't have an interface associated with the (VLANless) physical interface. That was what was confounding me. Although it irks me a bit to create an interface just to provide an interface to the physical settings underlying my WAN interface (which sits on a VLAN), I can live with that. I've added a WANPHYSICAL interface and configured nothing other than speed and duplex settings (100baseTX full-duplex in my case). Works like a charm.

Thanks!

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.)

The initial reason I started playing with pfSense is that our aging Cisco 2821 routers topped out at about 400Mbps between VLANs/sub-nets. So I slapped pfSense on a Supermicro Atom D525 server and started playing around. Quickly came to the conclusion that even if the performance were identical we would use it. My saga is documented here on the forums (1, 2).

So fast forward a few months and I have some time to test the inter-VLAN/subnet performance of pfSense on decent hardware. This is a rack-mount box running a fairly current (but inexpensive) E5506 Intel CPU. Four GigE Intel NICs (two built-in, two through an add-on card). With a 3xGigE LAGG we've been doing IPerfs between VLANs using multiple workstations. We've tried modern and older workstations, but either way we see about 1500Mbps (plus-or-minus 100Mbps) total throughput. I'm not expecting close to the theoretical throughput of 3Mbps, but am expecting a bit higher than 1.5Gbps.

The CPU doesn't seem to be the bottle-neck as top shows less than half of one of the four cores being utilised.

I'm also tempted to blame the D-Link DGS-1210-48 switches. Although they support LACP, I know that if their CPU is involved in any way, it will be the problem.

Are my expectations wonky? Has anyone else had experience using LAGG under pfSense and willing to share what sort of performance they saw?

It's been a while. Thought I would check on any replies to my past posts and then realised that I still have this problem.

So yes, the webconfigurator has an option for setting the speed and duplex settings on an interface. Unfortunately, my only choice is the default and autoselect. The interface makes me think that it is trying to sense what options are there, but it only comes up with autoselect.

Hey, thanks for trying FlashPan. We're all in this together.

So we're not using AD (yet). At the moment, it's just a separate box (a VM actually) running OpenLDAP. Since we now have about a dozen services that can use LDAP to authenticate, we're trying to go that route. pfSense is just one of these services.

The good news is that we figured out how to get this working with pfSense...kind of. By adding a 'manager' attribute to Person objects, setting a manager to point to a DN that starts with cn=SOMEGROUP, making sure that there is a pfSense group names SOMEGROUP, and finally setting pfSense's group member attribute to 'manager', it works.

The only issue we have is that using the manager attribute to store group membership is disgusting. I'm hoping that we learn something while setting up an AD service (through Samba4).

I guess what I'm asking is which schemas have a member attribute for the person objectClass that fits what pfSense is expecting?

From the PHP code, it looks like pfSense is expecting member (or whatever you set it to be) to contain a list of DNs. It iterates through the list and throws away everything except the CN. For the life of me, I can't find an attribute that is a list of DNs.

So I'm trying to set up LDAP authentication. Just LDAP, nothing with Radius. The actual authentication seems to work fine, but it isn't picking up users' groups.

I am just about the furthest one could be from an LDAP expert as it's been about a decade since I did anything serious in LDAP. Still this should be fairly simple. At the moment I'm reading through the pfSense PHP code trying to figure out how the groups are specified in LDAP, but surely they are done so in a standard way. I'm just not sure of the lingo I'm looking for.

All I'm trying to understand is how the LDAP should look for pfSense to use it for authentication.

Any ideas?