The Gateway dashboard element shows the percentage of loss based on ICMP echo requests to your default gateway (by default).  You could try changing the IP address that you use for monitoring, under System -> Routing on the Gateways tab, you would edit your gateway to change this setting.

If I were in your shoes, I'd ping the ISP's default gateway and then show them the statistics from ping.  You can do this in pfSense under Diagnostics -> Ping.  Assuming that you allow ICMP echo requests on your WAN port, they should be able to ping you too and see the loss for themselves.

I'm not sure exactly what you are trying to do or what gear you have available, could you do a quick drawing of your hardware and connections and post it?

@chpalmer:

Is gitsync advisable at this point?

Hasn't broken my lab setup yet…  :D

Not advisable, but not known to be broken.

1. If you have good enough hardware, that should be fine
2. Squid package will do that
3. Captive Portal can handle that
4. Not possible. Network storage does not belong on a firewall.

Then get with the times already and upgrade :-)

It's not an unreasonable restriction these days. The function that script calls only exists on 2.1.

Sure it could be done on 2.0.x but it means copying a bunch of code and a lot of extra work.

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.