thanks guys yes you were both right I was using free download manager.  Clicked cancel and then the xml config file popped right back up, its a life saver and now I can try and mess about with the other settings to get my other ports working knowing I can restore at will :)

Details needed:

What hardware? What pfSense version? What type of install? (LiveCD, memstick, nanoBSD…) Post the console output so we can see what is missing that prevents you from being able to give valid answers for WAN/LAN devices.

Well its been a record 24hrs without a single loss of the lan side, so I am tempted to call this issue resolved.

At the end of all of it, I think we can conclude the errors were due to a flaky sk1 (original LAN) port on the pfsense box.  Perhaps there would have been a quicker way to reach that conclusion, though as part of the "adventure" I certainly have a far better understanding of pfsense than I did when I dropped it in as the gatekeeper of my network.

Thanks all for the help in troubleshooting!  I am going to go ahead and mark this thread as solved for now.  I can always change it back if I am wrong and the error comes back…. but it has survived 24hrs and a stress test without kicking out a single error... so I am going to go with it! :)

Hy,

are there any news about - I've a similar problem in a lab-environment.

Want to create "restricted cp admins" but they cant see nothing expect a browser "can't load page" …

In the Logs I see the following line:

php: /getstats.php: testadmin@1.1.1.1 attempted to access /getstats.php but does not have access to that page. Redirecting to services_captiveportal.php.

BR
n3ro

tnx dear stephenw10 and muswellhillbilly, :)
unfortunately i have to do that, run a separate server

If you only add one interface you should be able to get to the webgui on that. There will be a default firewall rule that allows it when you have it setup in 'appliance mode'. However as soon as you add another interface it will go back to being a firewall and blocking everything on WAN so make sure you've set your own rules before that.
If you've already added and removed another interface I'm not sure what will happen. You can always disable the firewall using:

pfctl -d

At the command line.
After you added a rule to allow yourself to connect re-enable it with:

pfctl -e

Router on a stick usually refers to VLANs:
http://en.wikipedia.org/wiki/One-armed_router

Steve

That whole screen is for the WAN settings. At the top it says "On this screen we will configure the Wide Area Network information".
For 99.9% of installs MAC Address, MTU and MSS are left blank - you should leave them blank unless you have some really special reason to need a magic value.
For now, if you are leaving your front-end router/modem in its modem+routing mode, then you can leave Selected Type as "DHCP". It will be given a private address and default gateway from the front-end device that is in "front-end LAN =  pfSense WAN" and use that to get out to the internet. It will be just as if the whole pfSense box, and the "pfSense LAN" behind it are 1 client on the front-end LAN. In this configuration the pfSense LAN will NAT onto front-end LAN, then front-end LAN is NATed out to the real internet.
At a later stage you can put your modem/router into bridge mode (so it stops doing "router") and passes the real public IP through to pfSense WAN.

thank you very much!

Thank you very much!

Wow, that was negative fun…. however this morning I watched it boot then saw the full pfsense menu come up via the console.

Noticed the option to restore to a previous configuration - did that, and I am at least back to where I was.

I have a couple of inbound NAT rules pointing to other systems on the subnet.  But other than that there is nothing else.  It appears that removing this tick from the VPN connection properties has fixed the issue.  I have had no other negative feedback from our support agents so I have to assume that this change has fixed the issue.

Still getting to grips with the system.. :)

Drac

Updating to the most recent Github 2.1 release branch has solved the problems for me all together.

Your screenshots are not the way it was intended to be done. Maybe 2.0 allowed this and somehow it worked, I don't know, it has been so long since I used 2.0. I assume in this example:
a) The local LAN is not really "/8" - maybe the local LAN subnet is just "10.2.1.254/24"
b) There are other subnets available behind the router at 10.2.1.2 - that router might be a VLAN switch with L3 routing software also and lots of VLANs, or an ordinary router with lots of NICs or… The router hardware/firmware does not matter.

For 2.1 (and it should work like this in 2.0 also):

Change the "Gateway" setting on Interfaces->LAN to none. Leave LANGW defined in System->Routing (and make sure that WANGW is marked as the default) Add Static Routes to the networks behind 10.2.1.2, with gateway=LANGW.

Make sure that Firewall-Rules-LAN has rules to permit traffic from (source) the subnets behind 10.2.1.2.

If you get it working like this on 2.0 then it should upgrade to 2.1 with no trouble.

Fresh install, reload config…. the screeny shows no significant difference when switching from dashboard to RRD (just after going from RRD to dashboard).

fresh_install_2_1.jpg
fresh_install_2_1.jpg_thumb

Had the same issue…. The version dns error was resolved by flipping the following option:

On the general settings page...

Check the box that says to not use the dns forwarder for pfsense.

@stephenw10:

On an Atom box is that?

Steve

Sorry, that would have been useful information…  It's a DN2800MT w/ 4GB of RAM and a quad-port i350.