No, that would be a separate issue and doesn't belong in this thread.

If you have that many proxy ARP VIPs, just define them as a "subnet" and proxy arp will make that many of them in a chunk. If they are CARP, you couldn't have that many anyhow (vhid limit of 255), if they are IP alias or a combination of CARP+IP Alias it may work but I'd epxect some sluggishness from having that many IPs bound at once if your hardware is slower. If they are "Other" type VIPs, then you might consider upgrading to 2.1 where the subnet trick works for Other type VIPs like it does for proxy arp.

got it working now…in case anyone would like to block facebook apps and games.. put the ip below in 1 alias and firewall rules reject them apps.facebook.com SOA server: glb1.facebook.com email: dns@facebook.com serial: 2011072035 refresh: 10800 retry: 3600 expire: 604800 minimum ttl: 86400 555s apps.facebook.com NS glb2.facebook.com 86400s apps.facebook.com NS glb1.facebook.com 86400s apps.facebook.com A 69.171.242.30 0s apps.facebook.com A 69.171.242.47 0s apps.facebook.com A 69.171.242.48 0s apps.facebook.com A 66.220.146.52 0s apps.facebook.com A 66.220.146.53 0s apps.facebook.com A 66.220.146.54 0s apps.facebook.com A 66.220.146.55 0s apps.facebook.com A 66.220.149.53 0s apps.facebook.com A 66.220.153.27 0s apps.facebook.com A 66.220.153.28 0s apps.facebook.com A 66.220.153.29 0s apps.facebook.com A 66.220.153.30 0s apps.facebook.com A 66.220.156.43 0s apps.facebook.com A 66.220.156.44 0s apps.facebook.com A 66.220.156.45 0s apps.facebook.com A 66.220.156.46 0s apps.facebook.com A 66.220.158.43 0s apps.facebook.com A 66.220.158.44 0s apps.facebook.com A 66.220.158.45 0s apps.facebook.com A 66.220.158.46 0s apps.facebook.com A 69.63.189.59 0s apps.facebook.com A 69.63.189.60 0s apps.facebook.com A 69.63.189.61 0s apps.facebook.com A 69.63.189.62 0s apps.facebook.com A 66.220.156.44 0s apps.facebook.com A 66.220.156.45 0s apps.facebook.com A 66.220.156.46 0s apps.facebook.com A 66.220.158.43 0s apps.facebook.com A 66.220.158.44 0s apps.facebook.com A 66.220.158.45 0s apps.facebook.com A 66.220.158.46 0s apps.facebook.com A 69.63.189.59 0s apps.facebook.com A 69.63.189.60 0s apps.facebook.com A 69.63.189.61 0s apps.facebook.com A 69.63.189.62 0s apps.facebook.com A 69.63.189.63 0s apps.facebook.com A 69.63.189.64 0s apps.facebook.com A 69.63.190.26 0s apps.facebook.com A 69.63.190.27 0s apps.facebook.com A 69.63.190.28 0s apps.facebook.com A 69.63.190.29 0s apps.facebook.com A 69.171.224.27 0s apps.facebook.com A 69.171.224.28 0s apps.facebook.com A 69.171.224.29 0s apps.facebook.com A 69.171.224.30 0s apps.facebook.com A 69.171.224.55 0s apps.facebook.com A 69.171.224.56 0s apps.facebook.com A 69.171.224.57 0s

Thanks for the concise answer stephen :) *currently looking into the PFcenter thing.

Interesting. 5-6dB seems low for a 10Mb connection to me. Generally speaking you should be able to get a high connection speed at lower margins but at a payoff with stability. The rate adaptation should take care of that but it can be reset manually if it goes awry for whatever reason. However I don't think it's the cause of the disconnects, you would see that in the system logs and the modem uptime. It looks to me as though something at your ISP is sending the disconnect commands at the ppp layer, as JimP suggested in the other thread. Maybe you can capture those and present them as evidence to your ISP? I've never tried. @stilez: 24 mbit line I see! :) Yes. My connection here at home has always been very good. It should be, I can see the exchange from the window!  :) Although I have a 24Mb line speed I only get 20Mb because Plusnet is not an LLU provider. As an aside there is a lot more information available from Draytek modems via the telnet interface. See: http://forum.pfsense.org/index.php/topic,52091.0.html Steve

Updated AC power consumption figures: Cisco SF100D-05 5-port 100Mb mini ethernet switch:   with 0 devices connected: 0.8W   with 2 devices connected: 1.1W Alix 2D13 5.5W TP-Link TD-W8901G ADSL WiFi+Router 5.9W Fit-PC3 with AMD G-T56N CPU and 500GB disk:   Startup (5 seconds spinning up the disk): 20W   CPU running stuff (e.g. Windows Server Startup): 15.5W   Idling: 12.3W Lenovo S10-3s Netbook:   On built-in display: 15.0W   On external display: 12.5W   (thus 10" built-in screen uses about 2.5W) Items 1, 2 and 4 take 12V DC direct, with a reasonable variation, so can be connected to a 12V solar/battery system. I won't be at our test site to get real DC figures for a few weeks - will post again then.

You mean pfSense 2.1? 1.2 is very old. What modem are you using? Steve

Got this from my companies Dell rep. Apparently Dell encompases Fortinet, who Bought out Woven, and the FortiSwitch-100 is the same thing as the Woven Switch. So here's the link to the manual. Just click on the FortiSwitch-100 http://docs.fortinet.com/fsw40.html Hope this helps everyone out.

I upgraded a pfsense box from 1.2.3 to 2.0 and ran into this error when I tried to update some legacy static leases that used "subdomain.domain" notation.  I resolved it by commenting out the PHP code that generates this error. To disable the offending PHP code: Enable SSH (System->Advanced->Enable Secure Shell) SSH into your pfsense box. Backup the php file: (cp /usr/local/www/services_dhcp_edit.php /usr/local/www/services_dhcp_edit.php.orig) Open the php file: (vi /usr/local/www/services_dhcp_edit.php) Locate lines 122-126: } else { if (strpos($_POST['hostname'],'.')) { $input_errors[] = gettext("A valid hostname is specified, but the domain name part should be omitted"); } } Comment them out like this: } /* else { if (strpos($_POST['hostname'],'.')) { $input_errors[] = gettext("A valid hostname is specified, but the domain name part should be omitted"); } }*/ Save the file. Make sure that you do not comment out the entire line 122–the very first brace on that line closes the block of code above it.  Also, test your change by adding a static DHCP lease from the web interface before you close your ssh session.

@Lenny: Do you think that it is safe to use 2.1 BETA or better to use 2.0.1? Every production system we run internally (3 colo datacenters, office, all of our boxes at home) are on 2.1. The biggest risk is that which is inherent in any nightly snapshot builds of anything, upgrading. If everything works on the particular snapshot you're on, it's not going to break. Unless you follow development very closely, there's always risk in upgrading to snapshot builds. Though when you're running a pair you can mitigate that, upgrade the secondary, disable CARP on the primary, after verifying the secondary is good, upgrade the primary. Or if possible, just don't upgrade at all until a RC or release comes out, since those are QAed and automatic snapshot builds aren't.

I think I found the root cause of the issue. As I said before, I had to set a static interface in order to connect to WAN via PPPOE. My ISP requires constant mac address for the pppoe connection and I realize that pfsense actually can not spoof the MAC on PPPOE. Here is the tickect that I found. http://redmine.pfsense.org/issues/2641 Therefore, when I set a static interface and spoof my MAC via that inteface everything works fine. Now I am awaiting a fix for the issue. There are lots of issues about PPPOE on pfSense http://redmine.pfsense.org/projects/pfsense/roadmap

Thats awesome, thanks I will have to update and give it a go.

As I understand it TR-069 would not really be much use in pfSense since it is a protocol designed for communicating between CPE and ISPs in general. You could class a pfSense box as CPE but you would need to be in control of equipment at an ISP in order to use it. I guess I could see a use for it if you have multiple leased lines with direct ethernet connections to your various remote sites.  :-\ There is a product in the works for centralised management of multiple pfSense installs which will be more appropriate. CMB recently commented on it: http://forum.pfsense.org/index.php/topic,54202.msg289997.html#msg289997 Search for pfcenter to see some other comments on it. Unfortunately, from my point of view, it looks like it won't be an OSS product. I can understand that since it's obviously taken a large investment in time and money to produce and is targeted at large scale, and hence high value, installations. However I do not have enough pfSense boxes deployed to justify it so it's unlikely I'll get to sample it's delights. I guess it will depend on the licence model. Clearly I'll have to deploy more boxes!  :) Steve

Oh, wait.  ESXi, itself, from the console, won't be able to ping that network.  Pinging from the ESX(i) console only pings through the management interface(s), as that ping is really just there to test management connectivity.  In fact, I'm not sure how you assigned that physical nic an IP address at all.  You shouldn't. That "VLAN-100" network would only be able to communicate with things on that network, and your VMkernel Port for your management isn't on it.  Don't just put a VMkernel Port on it just to test it, though, you could lose access to it.  To test it, connect a physical machine with its NIC configured to receive DHCP, that should work (assuming your switch and other machine are otherwise operating ok.)

What is this log the result of? What evidence do you have that the ISP supplied router is using VLAN tagging? I think this could be an incorrect assumption. Try using the Windows PPPoE client from your laptop directly. What speed do you see? Steve

@bilbo: Could tell me how to setup the cron job, I have got the overide working now, sweet. Hopefully no more accidents when the kids are searching on google! Thought you might be interested in something I figured out this weekend… The override for "encrypted.google.com" does not work if someone browses to "https://encrypted.google.com". Not 100% sure of all the reasons why but I was able to figure out two options for solving the problem... 1.) You can block outbound access on port 443 to the IP addresses that encrypted.google.com resolves to. Unfortunately, this is a pretty long list so it's better to use an alias in your firewall rule. 2.) You can use the dns override and forward encrypted.google.com to a different ip address. It doesn't really block encrypted.google.com, but it sends the user to another site you trust - for example the address of opendns.com To block using option #1, I ended up using the url table feature of the alias. It will read a text file at a URL and block all the IP addresses or networks that are listed. The nice thing is that there is a built-in cron job that re-reads the text file daily and updates the table in your firewall rules. In order to make sure the addresses were up to date in the text file, I wrote another little shell script the does an nslookup of whatever names you want (in this case encrypted.google.com) and writes their resolved ip addresses to a text file. I place the text file in my /usr/local/www directory so that it can be referenced by url in the alias.  I just run my script 5 minutes before the built-in url update job runs. This got me going on another track though... It seems that there are several encrypted search engines available that also provide image search capabilities. The ones I found were duckduckgo.com, ixquick.com and startpage.com. Unfortunately, these sites presented challenges with block option #1 because (for whatever reason) nslookup only returns one address for them - but it doesn't always return the same address! For example, you can do an nslookup multiple times in a 10 minute period and get multiple addresses back for ixquick.com! Because of that issue, I used option #2 to prevent access to these sites. Option #2 isn't perfect though - it would not stop someone if they were able to figure out one of the ip addresses of the site and browse there directly (via the ip address).

Some of the more obscure timezones have updated names - e.g. the old spelling of "Katmandu" is now corrected to "Kathmandu" - so if you have something like that selected, then you certainly have to use the pfSense GUI and select the new correct timezone name.

You can do that. Each mifi will have to have a unique private IP subnet on it, other than that no special considerations. Just like any other multi-WAN setup.