To the right of the graph, you will see the IP of the active user fade in/out as they generate network activity.

Yup, the default anti-lockout rule is disabled. Only specific subnet on a specific vlan can access my pfsense. But I rarely make changes, so this is perfect for me. @Amirkabir: Thanks, Have you disabled anti-lockout rule and defined a new firewall rule to restrict access?

Any movement on this?? Jimp???

@nothing: host: ns1-fmslick domain: zapto.org That worked 100% Thanks. lol http://prntscr.com/205ewf

The SQL server is in the same subnet as the clients or on a segregated network? Steve

Who is on your wifi network? How secure do you need the access to be? Are you using captive portal? Using a vpn internally seems completely reasonable if your wifi is pretty much public. I'm not sure you can use the same vpn as wan though. Hmm. Strve

I got your PM - if I recall this a nested vm sort of thing.  With wanting to hit the web gui from the wan side, etc. I had teamviewered in and got him going last time…  Sure just send me a PM, I should be able to find some time at work today..

Its working because your IPs are connected to the same network..  So does not matter what interface pfsense sends traffic from be its lan or its wan it can still talk to your actual physical gateway. So if you look at its routing table - what does its show as primary route to 172.16.1.1 which I assume is your actual physical gateway off your network.  What interface is it using? Here is your problem - a client connected to lan side of pfsense can directly talk to 172.16.1.1 - there is no reason for it to talk to pfsense IP - unless you tell it too.  Because your lan side is bridged to the same physical interface as your wan interface. Why in the world would you setup such a pointless setup?

Thank you very much it worked

There isn't much you could do for that short of tossing more CPU at it. The IPsec status code might need some optimization, it does have to go over and over the entire status output a few times to build things up, so as the number of tunnels increases, the GUI status will be slower. I'm not sure if there is a more efficient way to build the status output though, it's been a few years since I looked at that code.

It could be that the format of a config section changed, something may be converted to/from an array, settings could move, variable names could change, etc, etc. Lots of different reasons. There is a configuration upgrade process that makes changes to the config as needed. It only happens when necessary. The config format didn't change from 2.0 through 2.0.3, but it's already changed from 2.1 to 2.1.1.

@jimp: Do you have the WAN set to "none" or DHCP or some other type? If you have it set to "none" then the message is correct. If it's set to DHCP that should still allow you to configure it even if DHCP doesn't yet have an IP. If you don't want to set DHCP, just put a dummy IP on the interface and switch it before taking it live. Thanks for the input. It is set to DHCP and using only IPv4. IPv6 is set to None. Could that be causing all these issues? I don't think so because when I allow the router to obtain DHCP on IPv4 then the problem is gone. Please test on your end. This is most likely a bug.

No, I have never tried to setup something like that. I'm sure there are people here who have though. Steve