Thanks for your reply.Do you know what that two input boxes are for?

@rikar: I'm a huge OpenVPN user and adding 2 factor would pretty much make my f_cking day!!! You can already do this with OpenVPN and basically every two-factor auth solution in existence, either via RADIUS or LDAP.

Does you ISP requires a constant MAC address for the NIC?  If so, you have to know that spoofing the MAC for PPPOE in pfSense does not work. http://redmine.pfsense.org/issues/2641 If this is the case then I may suggest you a workarround solution to spoof your MAC address.

" it has some kind of "remote management" (not Drac, but BMC? )" Normally those would be their OWN port on the box though, not part of the normal nic.  Remote management would be for outofband access normally and a different port than standard nic, even if built onboard and not a add on drac card, etc. R200 - will look into what I see about that model. edit:  Yup looks like you can do a shared lan method.  That has go to be it!  Try telnet to the IP and see what prompt you get. [image: sharedlan.jpg] [image: sharedlan.jpg_thumb]

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