Everything works great! Thank you so much for all your help!

Sorry about the delay, I was away for a few days with only a tablet to write with. Ok, so you want to have an additional interface that will host a wireless access point. You want want clients on that interface to have access to the internet but not to any machines on the LAN interface. Do you want wireless clients to be able to access the pfSense webgui? I will assume you do not. Two ways of achieving this you can allow access to everything and then block access to what you don't want or you can allow only access to what you want. I choose the latter because it involves less rules (faster processing) and is more logical to me. So, by default pfSense will block all new connections coming into an interface so without adding any rules to OPT1 wireless clients will not be able to connect to anything. We need to add rules to allow only connections to the internet. I have an almost identical setup on my home box, the difference being I have a lot more internal interfaces. I first setup an alias that contains all my local subnets Firewall: Aliases:. My alias is called LOCAL and for simplicity it's set as 192.168.0.0/16. Now set a firewall rule on OPT1 Protocol: IPV4 Source: OPT1 net Port: * Destination: !LOCAL    (the ! indicates NOT here) Port: *                              (you could limit this further by using a limited range of ports here) Gateway: * Thus only connection to addresses outside your local subnets will be allowed. This works fine BUT if your using the pfSense DNS forwarder (which you probably are) then you need to also allow access to that. Add another rule to OPT1 Protocol: IPV4 Source: OPT1 net Port: * Destination: OPT1 address Port: 53    (DNS) Gateway: * And you should be good. If you test you will find that clients on OPT1 can still access the webgui on the WAN address because the web server listens on all interfaces. If you don't want that add a specific block rule at the top of the list to block it. Attached is a screen shot of the rules I have on my wifi interface. All the additional rules allow access to further services but only the two I described above are necessary for internet access. Steve Hmm still can't attach files so here's a linked image: [image: Wifi1%20Rules.jpg]

@stilez: I had stuff here that was causing similar issues a couple of years ago, with pfsense 2.0.x.  The advice above matches what I found in the end. Some more things to try: Check the system RRD graphs, especially quality. A big issue for me was that dropped packets rose from 0.2% to 35-40% under heavy load, if the config didn't allow enough resources.  Worth checking if that's part of your issue. I got frustrated with this and ended up turning the esxi box off (and pfsense along with it). I set it up about a month ago because I had an assignment for uni where I need to build a test domain environment. Anyway I got pfsense running again with clients all using pfsense. I still had the torrenting issue. But I noticed the ram usage was high, even though I gave it I think 4GB of RAM. I decided to turn RRD graphs off. Problem solved! For whatever reason, the RRD graphs were killing my browsing for clients, as well as killing the reverse proxy (squid would just stop, service would NOT restart). Hopefully this might help people in the future!

Done!…..  :D :D :D :D...... Thanks so much Pfsense friends!

The base system on its own would not use that much but if you have installed packages or if the other admin had made changes to something in the code or otherwise by hand, something else could have filled up the disk. First check for packages, especially squid. From the console or ssh, you can run : cd /; du -k -d 1 That will show you how much each directory under there uses, find the largest one(s), cd into them and repeat the du command until you find the culprit.

Something is connecting to the GUI and then getting cut off (or lots of somethings), could also be captive portal if you have it active. You can disable the lighttpd logging on the Settings tab of system logs.

@theMikeD: I'm running it on a mid-2010 mac mini, so the USB NIC is require for two. Since I posted this I've googled this and evidently the USB NIC support isn't great in BSD. Is this a system that sits on top of BSD and could therefore sit on top of Linux too? Or is it too tightly connected to BSD? pfSense isn't a package that can sit on top of any OS.  You could try a 2.2 snapshot (based on FreeBSD 10 rather than 8.3) and see if that works any better, but in truth, you really should just try and get rid of the USB NIC.  If your bandwidth needs aren't ridiculous then you can use VLANs and an appropriate switch and then you'd only need a single port.

You're probably looking at either bad ram or a compatibility issue.

I ended up formatting the CF Card and reinstalling 2.1.5 fresh and only restoring certain sets of the config that I absolutely needed (firewall rules, aliases and such) and then I reconfigured DHCP and Snort manually. It seems to be running smooth for the last couple days, but I may shut it down and dd the CF card for a good bare-metal backup and still order a new CF card (or made a HDD??? so many choices!!)

Perhaps you could create an OpenVPN connection to an external site, such as your home. A pfSense OpenVPN Client, configured to use your companies SOCKS proxy if they have one, that connects to an external pfSense OpenVPN Server, at say your home.

Hey, I really appreciate all of your feedbacks. So I believe the issue is the fact that the office network is behind a proxy so even if I let the DHCP assign a IP and gateway/DNS to the WAN, it wouldn't let me connect to the internet through the pfsense box. Is anyone aware of a way around if you are behind a proxy so that the WAN can access the internet? Thanks Regards Ehsan

Sadly i'm stuck with my cable providers "all-in-one" box that performs it's own NATing. The pfSense box is directly connected via Ethernet as a reserved DHCP client with address of "192.168.200.2", while my internal network (LAN side) has 192.168.2.1 [Internet]  <-> 64.233.xxx.xxx [Cable Box] 192.168.200.1 <-> 192.168.200.2 [pfSense] 192.168.2.1  <-> 192.168.2.46 [Workstation] Yup.  That's a pretty sad config.

I should have just stuck with my first guess…  haha

The PCs can see both ranges but the PC firewall is blocking inbound traffic from other than the local network.  You would have to tell the PC firewall that 192.168.2.0/24 and 192.168.3.0/24 are both to be considered local, trusted networks.  How to do that is outside the scope of pfSense.

@KOM: I think you need to be in Firewall - Aliases - URLs. I think I figured it out! The weird thing is that pfsense will throw me an error but it will add the IPs! so maybe this is a bug afterall. IP ranges to add from Microsoft - http://technet.microsoft.com/en-us/library/hh373144.aspx So I copy pasted this into pfsense (see screenshot) 65.54.54.128/25 65.55.121.128/27 65.55.127.0/24 111.221.17.128/27 111.221.22.64/26 111.221.76.96/27 111.221.76.128/25 111.221.77.0/26 134.170.0.0/25 157.55.40.128/25 157.55.46.0/27 157.55.46.64/26 157.55.104.96/27 157.55.229.128/27 157.55.232.128/26 157.55.238.0/25 207.46.5.0/24 207.46.7.128/27 207.46.57.0/25 23.96.208.238 23.97.64.252 23.97.68.113 23.97.70.147 23.97.72.158 23.97.72.161 23.97.72.165 23.97.98.128 23.97.99.4 23.97.99.164 23.97.100.76 23.97.100.92 23.97.100.105 23.97.100.152 23.97.102.90 23.97.148.36 23.97.148.228 23.98.66.168 23.98.69.116 23.98.70.90 23.99.129.26 23.99.129.173 23.99.194.77 23.99.196.232 23.99.226.167 23.99.227.124 23.102.64.16 23.102.64.255 23.102.65.171 23.102.65.203 23.102.65.221 65.52.64.61 65.52.64.230 65.52.136.224 65.52.144.125 65.52.148.27 65.52.184.75 65.52.196.64 65.52.228.75 65.52.228.100 65.52.236.160 65.52.244.66 65.54.54.32/27 65.54.55.201 65.54.74.0/23 65.54.80.0/20 65.54.165.0/25 65.55.86.0/23 65.55.233.0/27 65.55.239.168 70.37.56.152 70.37.97.234 70.37.128.0/23 70.37.142.0/23 70.37.159.0/24 70.37.160.72 70.37.160.202 94.245.68.0/22 94.245.82.0/23 94.245.84.0/24 94.245.86.0/24 94.245.88.223 94.245.88.194 94.245.117.53 94.245.108.85 111.221.16.0/21 111.221.24.0/21 111.221.70.0/25 111.221.71.0/25 111.221.111.196 111.221.127.112/28 132.245.0.0/16 134.170.0.0/16 137.135.47.6 137.135.47.4 137.135.47.28 137.116.32.43 137.116.32.61 137.116.48.66 137.116.48.69 137.116.64.162 137.116.129.62/32 137.117.99.175 137.117.103.21 137.135.41.12/32 137.135.42.195/32 137.135.43.100/32 137.135.44.5/32 137.135.44.73/32 137.135.48.128/32 138.91.17.43 138.91.17.108 138.91.18.52 138.91.2.208 138.91.2.210 138.91.2.212 157.55.59.128/25 157.55.80.175 157.55.80.182 157.55.84.13/32 157.55.84.19/32 157.55.84.80/32 157.55.84.237/32 157.55.130.0/25 157.55.145.0/25 157.55.155.0/25 157.55.168.18 157.55.176.63 157.55.185.100 157.55.194.46 157.55.208.198 157.55.227.192/26 157.55.252.101 157.56.0.0/16 168.61.33.178/32 168.61.35.252/32 168.61.36.121 168.61.37.63/32 168.61.38.105 168.61.39.14/32 168.61.82.81/32 168.61.83.48/32 168.61.85.180/32 168.61.85.193/32 168.61.144.76 168.61.208.197 168.62.4.28 168.62.11.24 168.62.11.117 168.62.16.112 168.62.16.140 168.62.16.149 168.62.24.104 168.62.24.114 168.62.24.150 168.62.41.25 168.62.42.89 168.62.52.198 168.62.52.203 168.62.60.71 168.62.60.80 168.62.104.146 168.62.176.34 168.62.179.4 168.62.180.151 168.63.16.66/32 168.63.16.112/32 168.63.16.114/32 168.63.16.141 168.63.17.221/32 168.63.25.227 168.63.27.2 168.63.166.200 168.63.165.67 168.63.164.177 168.63.208.73/32 168.63.213.203/32 168.63.214.35/32 168.63.216.117/32 168.63.250.173/32 168.63.252.39/32 168.63.252.71/32 191.233.32.111 191.233.32.201 191.234.6.0/24 191.235.135.139 191.235.135.222 191.236.192.179 191.237.128.159 191.238.80.160 191.238.81.69 191.238.83.220 207.46.57.128/25 207.46.70.0/24 207.46.73.250 207.46.198.0/25 207.46.206.0/23 207.46.216.54 213.199.128.58 213.199.128.91 213.199.148.0/23 213.199.182.128/25 I will report this bug  :) https://redmine.pfsense.org/issues/3890 [image: added-but-receive-error.png] [image: added-but-receive-error.png_thumb]

@P3R: I've read your thread several times but I still don't understand what your network looks like and what equipment you really have at each site. Perhaps the lack of answers comes from the fact that nobody understands the situation? Instead of only bumping you could try to provide more information. Like a network diagram and explain what exactly the unknown "routers" are. I can't promise an answer but I believe a better question would at least increase the odds of getting one. OK im still having this issue and Im going to try to explain this better/ more simplified 2 location scenario. I have a IPSEC VPN connections between 2 locations. Location 1 Has a pfsense router (10.0.1.254) with a dedicated Asterisk server (10.0.1.2) behind the routers LAN port. Location 2 is a pfSense Netgate router with Asterisk installed on the router (10.0.9.254) At location 2 anything behind the Netgate router LAN port (10.0.9.254) ipsec traffic travels to Location 1 (10.0.1.0/24) fine with out issues. But from inside the Netgate router (10.0.9.254) either via trying to ping in the GUI or ssh the Location 1's network (10.0.1.0/24)  no packetes travel down the VPN. So my issues is that I have short codes (ie *80) to dial the two locations but since Asterisk is not using the VPN tunnel on the Location 2 Netgate router (10.0.9.254) they time out. I need to find out how to get Asterisk from Location 2 to communicate down the VPN. Right now it simply does not even see the 10.0.1.0/24 network at location 1 from inside the router. Testing from Location 1's router and Asterisk Server I can ping Location 2's router. I cannot ping from inside Location 2's router or Asterisk CLI to Location 1's network (10.0.1.0/24) Ping output: PING 10.0.9.254 (10.0.9.254) from 10.0.1.254: 56 data bytes 64 bytes from 10.0.9.254: icmp_seq=0 ttl=64 time=22.600 ms 64 bytes from 10.0.9.254: icmp_seq=1 ttl=64 time=30.619 ms 64 bytes from 10.0.9.254: icmp_seq=2 ttl=64 time=21.115 ms --- 10.0.9.254 ping statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 21.115/24.778/30.619/4.174 ms PING 10.0.1.254 (10.0.1.254): 56 data bytes --- 10.0.1.254 ping statistics --- 3 packets transmitted, 0 packets received, 100.0% packet loss Pinging 10.0.1.254 from 10.0.9.13 with 32 bytes of data: Reply from 10.0.1.1: bytes=32 time=26ms TTL=126 Reply from 10.0.1.1: bytes=32 time=24ms TTL=126 Reply from 10.0.1.1: bytes=32 time=25ms TTL=126 Reply from 10.0.1.1: bytes=32 time=23ms TTL=126 Ping statistics for 10.0.1.254:     Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds:     Minimum = 23ms, Maximum = 26ms, Average = 24ms