Just want to say something to the Squid Proxy point: It would be able to install a squid proxy on each tower and another one at the main office. Then you have to enter the proxy at the main office as the upstream proxy for the tower proxies. But I think this would only make sense if the bandwidth between the towers and the main office are to small.

Get all the easy stuff out of the way first: Test your memory with memtest Test your hard-drive with the manufacturer's utility Install pfSense 2.0 Release, it's been out for a while now (do your config from scratch for best results and do not install ANY packages) Make sure your hardware (especially your nic cards) are on the freebsd compatibility list You either will need to swap out your production machine for this, or do the work after hours. Once you have done everything above, come back and let us know how it goes.

Yeah I'm more or less wanting something that is done via the web interface or the ssh shell to do it for me.  Then keep that config going forward with out having to redo it every firmware upgrade.

PFSense can do this for you.  Look at the wiki for VPN instructions. http://doc.pfsense.org/index.php/VPN_Capability_IPsec http://doc.pfsense.org/index.php/VPN_Capability_Overview

@clarknova: Check the firewall rules on the interface that the laptop is connected to. If you have a Pass All rule then nothing will stop it from reaching hosts on other networks. If you want to prevent that then try creating a LOCAL alias for all your local networks and modify your Pall All rule to include the destination !LOCAL. Makes perfect sense.  I'll get that setup and retry.  Thanks!

squid + squidguard.  Read the packages forum.  This question gets asked a lot.

Search is your friend..

I also see this error once in a while, although it is not flooding the log. 2.0-RELEASE (i386) built on Tue Sep 13 17:28:43 EDT 2011 I am not using Unbound. Packages are only squid, squidguard, ligthsquid and imspector. Nov 22 09:02:11 apinger: Starting Alarm Pinger, apinger(11693) Nov 22 09:02:10 apinger: Exiting on signal 15. Nov 22 09:02:10 php: /system_gateways.php: Removing static route for monitor 208.67.220.220 and adding a new route through x.x.x.x Nov 22 09:02:10 php: /system_gateways.php: Removing static route for monitor 208.67.222.222 and adding a new route through x.x.x.x Nov 22 09:02:10 check_reload_status: Reloading filter Nov 22 09:02:10 php: /system_gateways.php: ROUTING: setting default route to x.x.x.x Nov 22 09:02:09 check_reload_status: Syncing firewall Nov 22 09:02:01 check_reload_status: Syncing firewall Nov 22 09:01:45 check_reload_status: Reloading filter Nov 22 09:01:45 php: /system.php: OpenNTPD is starting up. Nov 22 09:01:45 dnsmasq[52145]: read /etc/hosts - 396 addresses Nov 22 09:01:44 dnsmasq[52145]: read /etc/hosts - 396 addresses Nov 22 09:01:44 dhcpd: For info, please visit https://www.isc.org/software/dhcp/ Nov 22 09:01:44 dhcpd: All rights reserved. Nov 22 09:01:44 dhcpd: Copyright 2004-2011 Internet Systems Consortium. Nov 22 09:01:44 dhcpd: Internet Systems Consortium DHCP Server 4.2.1-P1 Nov 22 09:01:43 dnsmasq[52145]: read /etc/hosts - 396 addresses Nov 22 09:01:43 dnsmasq[52145]: ignoring nameserver 127.0.0.1 - local interface Nov 22 09:01:43 dnsmasq[52145]: ignoring nameserver 127.0.0.1 - local interface Nov 22 09:01:43 dnsmasq[52145]: using nameserver 208.67.220.220#53 Nov 22 09:01:43 dnsmasq[52145]: using nameserver 8.8.4.4#53 Nov 22 09:01:43 dnsmasq[52145]: using nameserver 208.67.222.222#53 Nov 22 09:01:43 dnsmasq[52145]: using nameserver x.x.x.x#53 Nov 22 09:01:43 dnsmasq[52145]: reading /etc/resolv.conf Nov 22 09:01:43 dnsmasq[52145]: compile time options: IPv6 GNU-getopt no-DBus I18N DHCP TFTP Nov 22 09:01:43 dnsmasq[52145]: started, version 2.55 cachesize 10000 Nov 22 09:01:43 dhcpleases: Could not deliver signal HUP to process because its pidfile does not exist, No such process. Nov 22 09:01:43 dhcpleases: Could not deliver signal HUP to process because its pidfile does not exist, No such process. Nov 22 09:01:42 dnsmasq[1092]: exiting on receipt of SIGTERM Nov 22 09:01:42 dnsmasq[1092]: read /etc/hosts - 396 addresses Nov 22 09:01:42 dnsmasq[1092]: read /etc/hosts - 396 addresses Nov 22 09:01:42 dhcpd: For info, please visit https://www.isc.org/software/dhcp/ Nov 22 09:01:42 dhcpd: All rights reserved. Nov 22 09:01:42 dhcpd: Copyright 2004-2011 Internet Systems Consortium. Nov 22 09:01:42 dhcpd: Internet Systems Consortium DHCP Server 4.2.1-P1 Nov 22 09:01:42 dnsmasq[1092]: ignoring nameserver 127.0.0.1 - local interface Nov 22 09:01:42 dnsmasq[1092]: ignoring nameserver 127.0.0.1 - local interface Nov 22 09:01:42 dnsmasq[1092]: using nameserver 208.67.220.220#53 Nov 22 09:01:42 dnsmasq[1092]: using nameserver 8.8.4.4#53 Nov 22 09:01:42 dnsmasq[1092]: using nameserver 208.67.222.222#53 Nov 22 09:01:42 dnsmasq[1092]: using nameserver x.x.x.x#53 Nov 22 09:01:42 dnsmasq[1092]: reading /etc/resolv.conf Nov 22 09:01:40 dnsmasq[1092]: read /etc/hosts - 396 addresses Nov 22 09:01:40 dnsmasq[1092]: read /etc/hosts - 396 addresses Nov 22 09:01:40 check_reload_status: Syncing firewall

@clarknova: @ccb056: port 22 forwarded to the pfSense box's local address. Except for the above line your configuration sounds correct to me. You don't need to forward port 22 anywhere from pfsense, you only need to allow that port in the firewall rules as appropriate for your connecting clients. Try killing the port forward rule and see what happens. winner winner chicken dinner removing the forward but keeping the rule fixed it thanks!

Actually, that is what I was thinking of. Few years ago, I did something like that. There was a parallel-port-based ISA card that we were able to access any of its 23 ports directly, turning them ON or OFF at will. I did a simple PCB with switching transistors that reset the modems and hung computers. Working with less than 12V, we didn't have to deal with complicated 120v regulation, certification, etc… May be it was sophisticated but it was a lot cheaper ;) I am currently serving few small customers who can't afford few hundred dollars just to rest the modems. I'll use a simple timer that power cycle the modem every morning for the one that is having troubles right now. I do not know how much difficult or simple it is to write a script that uses the router parallel (or serial) port as I do not have much experience programming under BSD.

Than you for the explanation, cmb! I had never expected saving/importing/exporting ONLY the RRD data can be so troublesome… The packages that I tested does not have this capability as well. A few years ago I wouldn't even care to look at the RRD Traffic graphs as it didn't affected me, I guess time has definitely changed.  But now with monthly CAPS imposed by many-to-most major ISPs around the world, who can afford NOT to ignore how much traffic one uses.  Overages can be quite expensive!

Yep, I agree. I don't think it was necessarily the DNS forwarder. Upon further investigation I 'think' that I needed to check the 'Do not use the DNS Forwarder as a DNS server for the firewall' in the General Setup. At least that is what I did and it seems to be working now. I didn't have any other items checked in the 'DNS Forwarder' other than the 'Enable DNS Forwarder'. So I don't know what is going on, but it certainly is/was a DNS cache issue

@jimp: It will be a while yet. It will most likely end up being a book for 2.1 since we intend to cover IPv6 there. We've been so busy we haven't had time to write much. There are a lot of areas that will need quite a bit of work to be updated for 2.0. All right. thank you for those informations! Regards,

Diag > Command will always show rw because it switches to rw to run your command. Only when viewed from the shell on the console/ssh will you see ro.

Just wanted to finalize this thread out by saying I ended up swapping out both the nics. Their chipset numbers are: 88E8001-LKJ1 AJ476A.2 0714 A4P TW Marvell of some kind. Hardware version: B2 Now everything works fine except dealing with havp and squid now :)

Yes you can do that. Though I would probably stay away from doing so, or at least be very careful not to mess up the VLANs on any of your switches or you could end up with a layer 2 loop much more easily than bridging scenarios without VLANs.

You're welcome :)

@bsmither: So, just to satisfy my curiosity, is it the ICMP protocol's job to determine if a reply can be sent without a route, or is it the networking part of the OS, or the ping.exe application? The way I see it, something has to be dumb enough to permit a reply based on knowing the IP address and/or the MAC address of the sender in the request packet. It's the IP stack of the OS. It has to be able to send back to the source IP of the request, whether it's locally reachable (so it just ARPs that IP), or is reachable via some router in its routing table (in which case it ARPs the router where that IP is reachable per its routing table).

You can turn on NXDOMAIN responses in OpenDNS. Or fix your DNS so it'll resolve local hostnames correctly, which is the better solution given that's what current Windows versions expect.

@stephenw10: @Cino: You just can't try a card in the box and expect it to be 100% stable without researching the wifi card and its driver for freebsd. I think that says it all. For many people that is a reason why pfSense sucks. For a M$ based solution (and increasingly Linux) you can just try a card and have a reasonable expectation that it will work well. As pfSense becomes more popular it is inevitable that more first time users are going to be disappointed. There are probably far more satisfied users but most of those don't complain.  ;) Yeah this entire thread can be summarized as FreeBSD's wireless drivers for some cards really suck, and on the rest the guy has no idea what he's doing, things like creating MAC address conflicts and wondering why the network breaks. But Linux has much the same issues with drivers, you really have to research your cards before you buy one especially since many of the bigger manufacturers (DLink, Linksys, etc.) will change the chipset used in their cards without changing the model # at all, so even finding a working model # on some cards is no assurance you're going to get the same card they used to sell under that model. It looks like the situation with wireless will be getting a lot better with FreeBSD 9. Adrian Chadd has done quite a bit of work in FreeBSD 9 for a commercial software company that uses FreeBSD in their appliances and relies heavily on wireless. I have hopes that will be a great step forward on wireless.