@divsys: "Config History" section … While it won't document what you did in your bulk change file ... Sure it does. Choose two config files and hit the "diff" button. Displays the difference(s) between the two selected files.

@Derelict: Add the client and the secret to the RADIUS server and it will work. Did you restart the RADIUS server after making the changes? If it's based on FreeRADIUS shut it down and run it with the -X flag. That will show what it's doing in the foreground. Run a test using Diagnostics > Authentication and post the results. I restarted the radius and it did work :) , Thanks to muswellhillbilly and Derelict

Ok thanks for all the advice. I will see how it goes and post my progress or lack of. Lots of fun anyway.

Misconfigured switch (duplexity), bad cabling.

I just got notification as the system was rebooting on upgrade from 2.3 to 2.3.1 And just did a test from 2.3.1, and that worked.  Also after the upgrade I got an email from service watchdog that it restarted freerad, which was after the upgrade.  It uses the same notifications settings, etc. Now what would be slick, maybe 2.4??  Would be the ability to list what generates notifications and to pick and choose what you get and maybe even add things.. [image: notificatoins.png] [image: notificatoins.png_thumb]

@vbentley: @dotdash: Padlock is pretty legacy these days, there are much better alternatives available. There is a reason it is not in FreeBSD anymore, it is widely believed that it is compromised. See Snowden, etc. There are much better alternatives IF you have the funding to obtain them. If not, and you already have Padlock equipped devices then all is not lost. I got that VIA based router (https://www.google.de/search?q=lex+3v700d&source=lnms&tbm=isch) off of ebay for 15,- Euro including shipping. I had to add a CF card and RAM from spare parts. The proposed ALIX based solution would have cost us about 200,- Euro. But with Padlock running out of support i will have to look for something different for future purchases.

@covex: i can see pfsense in the azure marketplace now! gonna test it is it 2.2.5? Yes, because thats how long ago we started this process, and updating the image would have derailed things even more. It will update to 2.3.1 soon. here are a few hints on how to get started: https://forum.pfsense.org/index.php?topic=112072.0;topicseen

@bsu3338: I found the problem. The permission User - Config: Deny Config Write was added during upgrade to my group It wasn't added, that didn't change. It's now being obeyed in some cases where it should have been but wasn't previously.

A clean install followed by a restore of all except packages seems to have worked a charm.  Luckily I don't use more than two or three packages.  Thanks again for the assistance!

https://forum.pfsense.org/index.php?topic=111140.0

Oh 12 is out wow.. Missed that. Dude put your management interface in the host only network..  What interface are you sending the logs too in ossim??  If it was in host only network pfsense would not be able to talk to the management interface IP As for ossim to see traffic, did you create the monitor/sniffing interface.. Did you put that vmnet in promiscuous mode?

Hello, I also see states have more "NO_TRAFFIC:SINGLE" and "SINGLE:NO_TRAFFIC". This only zero packets and bytes.Is it normal status. In the 2.3 version.I unusual see these two states.

I'm not sure if this is much help to you, but in case someone digs into this, these might be pointers to someone, so I'd like to weigh in: When I evaluated pfSense as a captive portal for us, I noticed this too. I was running 2.3 at the time, inside an ESXi. What I did find: Opening the same site / connecting to same IP automatically after login then before login takes a long time. Meanwhile, traffic to other servers on same client flows normally. Steps to reproduce: 1. Open website on server 1.2.3.4 2. get redirected to captive portal 3. log in successfully on CP 4. pfSense redirects you to 1.2.3.4, page takes long time to load 5. meanwhile, open page to 9.8.7.6 in parallel tab, opens instantly I did see some dropped packets in the firewall log that would explain this, but not why they were dropped. They matched the default drop, so they had to be out of state. My guess (and this is not an educated guess, just specultation) is that the client reused the connection from the first contact (which got redirected to CP), but pfSense already closed that one. Packets are out of state, get dropped, until the client timeouts the connection and builds a new one. New connections (in parallel tab) go through normally. Since I use "After authentication Redirection URL" anyway and this is not a site that a user would normally open before auth, I did not investigate this further to drill down if this is an issue from client or pfSense, or even if my assumptions are correct. But this might help someone investigating.

Only thing I do recall is it was working both locally and externally when I would type movies.mydomain.com into a browser. It would auto redirect… now it seems my DNS entries are overriding the external DNS. Which is great for pinging / accessing that IP address but I think I have figured it out and know how I can get it to work.