Provided everything is correctly configured, your inter-VLAN traffic will go to your pfSense box where it will be routed between the VLANs unless blocked on entry to the box by a firewall rule.

ill keep windows update and symantic antivirus, ill see if better now. thank for the reply

@garyw: if I ping from another machine on the LAN to the OPT1 interface I get a reply. That is the expected behaviour. I assume you mean another machine on the OPT1 subnet but the same would be true for the OPT1 interface itself. There is a default firewall rule on LAN that allows all traffic to anywhere. 'anywhere' includes the OPT1 subnet so pings from a LAN client can reach an OPT1 client. The ping response is allowed back because the state has been opened already. If you tried to do the same in reverse, ping a LAN client from the OPT1 subnet, you'll find it is blocked. If you don't want that to hapen you have to modify the default LAN rules to be more restrictive. Steve

Hmm, yes I agree the text is confusing.

I don't know whether or not that adapter will work, but pfSense doesn't support 802.11n.

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: [image: XOEIoAL.jpg] 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: [image: MLvMrXM.jpg] 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: [image: WgWGiKP.jpg]

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.