A rather strange development with regards to this issue. We had another site go onto Fibre this year and when it went online all 3 of it's Ipsec tunnels were online and well. I compared it side by side with another site that only had 2/3 tunnels up and as far as I could tell they were identical apart from the fact that one of it's redundant Ipsec tunnels (were used for failover in the past but are since redundant) that is disabled had SHA1 and MD5 as authentication methods as well as on the recieving end of the Ipsec the exchange was set to Automatic. I tried replicating that since on the 2/3 firewall but still the same result. Now, even stranger. After about a week or 2 of those 3 tunnels being up it has now only got 2/3 tunnels up itself! Anybody got any suggestions on this strangeness? Oh and I have tried this on 2.1-RELEASE (i386) as well as 2.0-BETA5 (i386

The configuration needs to be managed from the webGUI so that the config is correctly save and applied. Some basic configuration is done from the console menu, to get a system installed to get get yourself out of a hole if you are locked out of the webGUI or… When you login over SSH, you can start the console menu with: /etc/rc.initial The command line is just a FreeBSD TCSH prompt. There is nothing to manage there, but you can monitor FreeBSD, the packet filter state etc if you want to use command line rather than webGUI. It is sometimes useful when tracking down real bugs - but there aren't any of those left in pfSense  ;) The FreeBSD variant of Unix is documented at http://www.freebsd.org/docs.html WARNING: Do not mess around at the command line - you will soon break your system if you don't know what you are doing.

In case you didn't realize the pfSense packages that you load up through the webgui are different to the FreeBSD packages loaded via pkg_add. Loading FreeBSD packages is not really recommended. Mostly they work, especially small stand-alone stuff, but it's also possible to completely break pfSense by accidentally overwriting some component due to a dependency. The command line shell in pfSense, TCSH, is basically a complete FreeBSD shell. Unlike many other *BSD or Linux based firewalls there is no restricted environment with limited ability. This also means there is no easy to work with set of custom commands, though there are some. As such start reading the FreeBSD user guide!  ;) http://www.freebsd.org/doc/en/articles/new-users/index.html Others have made some lists of useful CLI commands in pfSense, for example: https://www.linuxnet.ch/pfsense-important-cli-commands/ I don't recommend using viconfig as listed there unless you're already familiar with vi and it's weirdness!  ;) The ee editor in included for mortals. You can download things directly from the CLI using the fetch command. E.g. fetch -o /tmp http://www.someurl.com/somefile.txt Downloads the file somefile.txt to the /tmp directory. I don't think that's going to help you though. Steve

You may find some stuff in the SNMP forum. https://forum.pfsense.org/index.php/board,25.0.html

Yes this is a known issue unfortunately and I've not seen anybody work around it in any useful way. I have a GPS device attached to a pfSense box here which I guess may help though that usually takes a few minutes to produce enough data that ntpd decides to use it. Maybe that wouldn't be the case if it's only time source. I'm guessing that after a long and tiresome struggle yesterday your quoted delay of 30mins might have been an exaggeration!  ;) If not then you really have an issue, I've never seen a delay of more than a few minutes. Steve

I have found that following these instructions https://doc.pfsense.org/index.php/Why_can't_I_query_SNMP,_use_syslog,_NTP,_or_other_services_initiated_by_the_firewall_itself_over_IPsec_VPN%3F click System > Routing. On the Gateways, tab, click + and add a gateway using your LAN IP address (check the box to disable monitoring). Save/Apply,         then go to the Static Routes tab, click +, enter the remote VPN network in the "Destination Network" box, select the LAN IP gateway that was created before, and add a description         if you want, then Save/Apply. Once i removed the manual route, rebooted pfSense. My ubuntu machine was able to communicate thru the tunnel. Why this stopped working all of a sudden is a mystery. Also, I am directing the pfSense Syslogs thru the tunnel to a remote syslog server and since removing the manual route, it is not working. Any suggestions would be appreciated.

wan does not need to be connected to access the gui. on first install accept defaults and make sure you are using the right nic for lan. sometimes pc's are stubborn in getting a ip address through dhcp if going to another router setup, on pc getting an ip address from pfsense make sure dhcp is enabled and/or reset its config, if that fails set your pc nic  manually for  ip address(eg. 192.168.1.10) and subnet 255.255.255.0, gateway & dns 192.168.1.1. make sure you clear your browser history, certificates if previous router/firewall was also setup on 192.168.1.1

Thanks a lot. I can't use VLAN because one subnet is for telephony and all switches have at least 2 subnet on it. Temporary we put all the subnet in the same network and in the future we go to change switches for VLAN capable.

As PTT said it's not a ISO. Though now I look at it the new website does list it as 'Live CD with Installer (on USB memstick)' which is potentially confusing. Another useful utility for writing raw images is Win32 Disk Imager: http://sourceforge.net/projects/win32diskimager/ Steve

Glad to be part of this world we call pfSense!!

???? .JPG) .JPG_thumb)

While your fixing this I would also setup your reverse zone for your rfc1918 address so you don't get this for your dns server Server:  UnKnown Address:  192.168.0.11 if you have PTR for your network you would get something like this the IP of your dns server C:>nslookup Default Server:  pfsense.local.lan Address:  192.168.1.253

another… [image: Untitled2.png] [image: Untitled2.png_thumb]

@stephenw10: I would go separate NICs if I had a choice. Be aware that when you start adding a lot of NICs to a box you might encounter some issues that don't arise otherwise. Like this: https://forum.pfsense.org/index.php/topic,69486.msg379897.html#msg379897 Steve Heh, that box completely imploded when I added some 10Gbe ports on Friday.  Even with queuing disabled in the igb and ix drivers I had to limit the box to 2 cores to get it to boot. My 2.1.1 box (backup in CARP pair) works without any tweaks.

@Damned: I have tried rebooting. It doesn't help very much (/at all) If it's a problem that can be solved by tuning the NIC options then I would expect that rebooting the machine would at least temporarily resolve it (until it runs out of resources again). If the WAN does not come back up after rebooting then I might suspect something at the ISP end objecting to your torrenting. Steve

Not sure where helper got the idea that manual rules have to be empty in the first place?  When you switch back to automatic, the manual rules are not even looked at. You can verify that for yourself with a simple look see with  pfctl -s nat So in manual mode you will notice very specific rules pfctl -s nat no nat proto carp all nat-anchor "natearly/" all nat-anchor "natrules/" all nat on em1 inet from 192.168.1.0/24 to any port = isakmp -> 24.13.xx.xx static-port nat on em1 inet from 192.168.1.0/24 to any -> 24.13.xx.xx port 1024:65535 nat on em1 inet from 192.168.2.0/24 to any port = isakmp -> 24.13.xx.xx static-port nat on em1 inet from 192.168.2.0/24 to any -> 24.13.xx.xx port 1024:65535 snipped the rest xx out part of my wan address. Now look at same rules while in automatic mode pfctl -s nat no nat proto carp all nat-anchor "natearly/" all nat-anchor "natrules/" all nat on em1 inet from <tonatsubnets>port = isakmp to any port = isakmp -> 24.13.xx.xx port 500 nat on em1 inet from <tonatsubnets>to any -> 24.13.xx.xx port 1024:65535 no rdr proto carp all I assure you my manual nats are still there and what do you no the nat rules changed to generic rules using <tonatsubnets>So what I suggest you do is take a direct look at what your nat rules are via  pfctl -s nat when you switch between manual and automatic. [image: manualruleslistedwhileautomatic.png] [image: manualruleslistedwhileautomatic.png_thumb]</tonatsubnets></tonatsubnets></tonatsubnets>