First thing to do here is upgrade to 2.4.3_1. This may have already been addressed.

If it doesn't then we would need to see logs covering the reconnection that results in no outbound traffic.

Steve

It depends how they 'discover'. But most use either mDNS which Avahi should cover or they using the SSDP component of UPnP which can be made to work using IGMP proxy. But it is by no means guaranteed. It's worth pointing out that the UPnP component in pfSense is only for Internet Gateway Device protocol and does not help at all with this. So don't enable it.
Unfortunately all these manufacturers cater only for a single flat layer 2. If you attempt to add some security to your network by separating devices into different subnets you're outside their target audience and on your own. They could easily allow this by just giving you a box to enter the server IP but..... IMO. 😉

Steve

Yes I agree, I seems unnatural to do that. 😉

However I guess that by doing that you can add new nodes to the mesh and as long as they are in that subnet the system routing table does not have to change to reach them. Only the internal routing in the daemon.

Steve

It's almost certainly Squid if you're running that. Either cache or logs.

Try running at the command line du -hs /*

Then drill down further to find what's using the space, e.g. du -hs /var/*

Clear the Squid cache from the package menu of you haven't already.

Steve

oh nice

Solution

System > Advanced > Miscellaneous

https://prnt.sc/kp9ek6

You are correct, that would appear to be a symptom of a failing disk

Hi !

I have already the same problem.

If you have this error :

10.50.3.1 | FAILED! => {
"changed": false,
"module_stderr": "/bin/sh: /usr/bin/python: not found\n",
"module_stdout": "",
"msg": "MODULE FAILURE",
"rc": 127
}

You can pass the interpreter /usr/local/bin/python2.7 in Ansible Variable !

In the /etc/ansible/hosts file you can put :

fqdn_server ansible_python_interpreter: /usr/local/bin/python2.7

After this modification it's work fine !

I have unchecked the option last night and made some changes where i knew before the connections will be dropped and all connections remained active! Thank god it was that simple.

I haven't checked the number of states before, i wouldn't risk the dropped connections for that anymore.
I don't have any packages installed.

Thank you for your help, this solved my case.

0_1535644393905_56505a32-dc30-4b9e-97a2-f2bb6a9981d5-image.png

I have a pfSense VM setup for just this. It's WAN is inside my usual lab network, but in its outbound NAT it translates anything that leaves (except its own WAN address). Then on the LAN side I have the rules allow any/any and I add VIPs to the LAN that mimic the "ISP" side of the statics I am testing.

If the VMs on the inside have VPNs or DynDNS I try to block those in the LAN rules before firing them up so they do not interfere.

There are some backwoods providers out there that give customers a /32 WAN IP Address with a gateway outside of what would otherwise be their subnet. It's ugly, but it happens.

As @Derelict said, no matter what we pick as the default it will be wrong more often than it is right. Using /32 as the default is less likely to break something than using /1 as the default, and any value in the middle is a wild guess.

You can open an issue on Redmine under https://redmine.pfsense.org/projects/pfsense-docs/issues

I went ahead and fixed that one though. It should show up shortly. Thanks!

@nogbadthebad said in pfsense android 5:

Does it work if you disable squid ?

No

This problem did not occur in Pfsense version 2.2.4;
I think it could be a problem of squid version 0.4.43_1 or squidGuard version 1.16.4

come on, talk to me

As a short-term fix disable Snort HA sync on the SYNC tab in Snort on the master firewall, and then reboot the slave firewall. That will stop the problem for now. That PHP file is created on the slave firewall by the master when "syncing" a Snort configuration from master to one or more slaves. That PHP file contains a series of commands for the slave to execute.

Instead of rebooting, you can also try killing all those php-cgi process IDs. They are all trying to execute the same PHP file and likely stepping all over and blocking each other.

It depends how you're filtering traffic. And whether that system is setup to filter on the interface your AP is connected to.

The tablet might be using a different DNS server for example if you're using pfBlocker.

Steve

Thanks @TheNarc

I think what I was seeing was actually a PC soft-phone trying to connect via the WAN (outside the VPN) because it must have been provisioned that way, not one of the phones. And since the soft-phone has the same extension as one of the desk-phones, it appeared to be that one phone.

@msf2000 Hmm, looks like my post wasn't as clear as I thought it was, never mind. The problem is not about user mixing up and lowercase, it's about the LDAP authentication that (seems) not handling casing correctly. Both 'SuperAdmin' and 'superadmin' authenticate correctly when using Diagnostics - Authentican. That diagnostic also returns group membership but only for 'SuperAdmin' and not for 'superadmin'.
.... but I should have searched a bit more: uid is not case sensitive by default but memberUID is (standard 389-DS schema) - odd but that's the way it is which explains the results I'm getting.

@grimson said in Higher pings from ethernet than wifi:

Just ping pfSense or your cable gateway, if the pings are normal your cables are OK.

Also, defective hardware, including cables, will produce errors which you can see in the ping results.