I figured out the LZO compression problem I had with StrongVPN and OpenVPN. The correct command in the advanced configuration is comp-lzo yes;

comp-lzo; and comp-lzo adaptive; does not make it work with upload. The comp-lzo yes; is the only one that worked at speeding up upload now my upload is more than twice as fast as my isp's bandwidth limit of 5Mbs :) I'm getting around 11Mbs upload.

@dhatz:

PS: Btw iirc Unifi APs had certain peculiarities in their VLAN/SSID configuration (possibly fixed in newer firmware)

Mine work fine.

The problem was indeed the 12 character password. I have changed the password in to 9 characters (to be safe) and the problem was disappeared

Here are my relevant NAT entries:

With these rules, my wpad.dat is still hit (I just checked) but if anything tries to bypass wpad it is redirected to my proxy setup. My wpad does nothing currently, just redirects to the proxy the same as NAT. Some of the devices on my network aren't capable of auto-detect, so they are either pointed directly to the proxy or NAT handles it.

Here is an extract from my lighty-proxy-wpad.conf:

The server.bind line has my pfSense private IP between the double quotes. The mimetypes entry has all the other entries deleted to make the image smaller, but you can see that I added two lines for .dat and .da files. I also commented out all the 443 and SSL stuff. This file was originally a copy of the webgui's /var/etc/lighty-webConfigurator.conf. Then I have lighttpd running like this:

/usr/local/sbin/lighttpd -f /path/to/wpad/lighty-proxy-wpad.conf

This is my webserver for port 80 requests, that serves my wpad to client devices on my network. I use a service to start lighttpd up and monitor it, but you can use a entry in the config. Or another method.

I also have firewall rules to allow traffic on my interfaces to wpad, my proxy and other services:

If you had posted while having these problems, then we could have offered some suggestions about how to do troubleshooting, e.g.

pfctl -sa
netstat -s
etc

Now, after the fact, we can only speculate about the dozens of things that could have gone wrong.

Hmm, yes that seems fairly obvious. I wonder where I picked up that nugget.

Steve

2 things I can see here.

First your modem is one that starts handing out private IPs when it looses link upstream. This is helpful as it allows access to the modem diagnostics but it can cause problems. Some pfSense installs get stuck with the private IP afterwards. That doesn't seem to be happening to you but something to watchout for.

Second the DHCP server you're talking to is at a private IP address. Is that right?

However I agree with Wallabybob it looks like just the modem loosing sync and then coming back. Is this something that just started happening?

Steve

Yeah.  I use the initial LAN port as my management interface so the anti-lockout functions make sense.

I've been looking at this more since posting and have decided it is better to simply create a port alias with 80, 8443, and 22 and enter a reject rule that prevents each subnet from accessing those ports on their own interface.  I already have to have rules that reject traffic, for example, from OPT1 to Management and OPT2 anyway.

Way better than modifying 2.0.3, though the ability to bind admin services (webConfig/ssh) to a specific interface would be a welcome enhancement.

OK… Thanks to everyone.. it was my cable . Now it works ;D

It sounds like the WAN and LAN are connected together on one single layer-2 network. And that you have WAN and LAN subnets the same - 10.0.0.0/24. The LAN client is probably getting DHCP from the ADSL gateway, rather than pfSense.

Make your LAN subnet different from the WAN subnet. If you have 2 NICs in your pfSense hardware, then connect the ADSL gateway directly to 1 NIC and use that as WAN, completely separate from the VLAN stuff;
otherwise you have to configure the VLAN switch, and use a VLAN for WAN devices and separate VLAN for LAN devices, with pfSense trunk port between them. That way a DHCP request from pfSense WAN is only seen by the ADSL gateway, and a DHCP request from a LAN device is only seen by the pfSense virtual LAN interface.

I am confused by the description of your network configuration. Please provide
1 a network diagram including IP addresses and network masks of interaces, identifying particular hosts on that diagram that can't communicate;
2 output of pfSense shell commands```
/etc/rc.banner ; ifconfig

@jimp:

How did you "recreate" log logs?

They are supposed to have lots of null characters, they are binary circular log files, the are not plain text logs.

They are read with the clog command, such as "clog /var/log/system.log"

Usually that clog crash means that the logs were not created with a clog format.

Use the "clear log" button on a log tab to clean and re-create the log file properly.

Click Save on the Log Settings tab to restart the syslog process which usually will get logs going again.

Thanks very much. I'd actually worked this out at stupid o clock this morning - i.e. that i was being an idiot and assuming the logs were plain text, not binary. On the upside, I now know about clog and a lot more about pfsense, so 10 hours of banging my head against a brick wall wasn't entirely wasted!

Thanks again - the key point to other users if they are stupid like me, is to not manually kill and recreate the log file to clear it! Use the pfsense gui and manually check it's logging using 'clog [filename]' rather than vi.

When reading both the graphs and the bandwidth-by-IP table, always think of In/Out with respect to the interface or IP address reported. Then the In/Out makes sense.
e.g. when doing a big download:
WAN graph - In is high
WAN IP bandwidth table entry, In is high.
LAN graph - Out is high (traffic is going Out of LAN interface to the device receiving the download)
IP entry for device on LAN -In is high - the device receiving the download is getting a lot of traffic in.

(No comment on the OP about speed figures - I don't have a 2.0.3 system any more to do a real test)