192.168.3.1.53: UDP, length 39

So that is your client at 192.168.3.3 asking for dns.. Pfsense does not answer - so no how would the client go to any website? if can not look it up.  So looks you do not have unbound running or forwarder working at all.

Or you don't have any firewall rules on this interface to allow access?  The lan interface would have a default any any rule on it.  Some new interface you created would not have any rules you would have to put either an any any or the rules you would like to allow.

Pfsense will create behind the scene firewall rules to allow for dhcp to work.. But I only see this
23:37:25.457114 IP 0.0.0.0.68 > 255.255.255.255.67: UDP, length 300
23:37:25.457435 IP 192.168.3.1.67 > 192.168.3.3.68: UDP, length 300

there should be more.. from what have to assume is the discover there to FF:67, the answer would be a offer - but you should then see a request and ack..

But clearly from this whatever .3 is sending traffic to .1 (pfsense)..  I take it .3 is a wifi client?  So where are the rules on this interface on pfsense?

After to clear the cache, the problem was solved.

Thanks.

It is always usefull to run a fsck on a system.
At best, it finds nothing to do. Your disk is marked clean again and the system will boot.
At worst, it will tell you it could repair things and you know you won a trip to the local "new disk store".

The situation is pretty identical to what we have been seen the last two decades with a non-clean shutdown of a Windows PC. It's CHKDSK time ;)

Hi,

Can you detail what method you have chosen for authentication ?

Try this:

Read https://doc.pfsense.org/index.php/Captive_Portal_Troubleshooting (this is the doc that explains everything - never leave home without it)

Access console and run

ipfw table all list

See that _auth_up tableand _auth_down table contains IP AND MAC of every authenticated device.

Disconnect all users.

Set soft time out on portal interface to 10 minutes.
Set hard time out on portal interface to 15 minutes.

Use a device (the PC, Smartphone, pad, whatever) to authenticate.
Run

ipfw table all list

again and see that your device is on the list - the two tables. Is this MAC and IP the IP and MAC of your device ??

Shut down wifi on your device.

After 10 minutes probably and 15 minutes sure the tables will be empty.
Run

ipfw table all list

every minute or so to to check.

Activate wifi on device and check that connection to the Internet is lost.

No.

Thanks Guys

actually got it to work :)

I have a same issue

I'm not saying more than one DHCP server is needed on a small network, but many people are of the opinion that you can't have more than one and that's nonsense.  As I mentioned, it is possible and is done for redundancy.  Incidentally, today I was working in the Bell Canada lab, and guess what I saw.  Lots of redundant everything, including DNS servers.  I didn't specifically see them for DHCP, but I wouldn't be surprised if they were there..

As I mentioned, one issue that may occur with DHCP servers is multiple servers handing out the same address.  These days, the trend is to Duplicate Address Detection, which avoids that problem.  While DAD is mandatory on IPv6 and commonly used on IPv4, you can't guarantee every IPv4 device uses it, so it's best to have different address ranges for each DHCPv4 server.

Thanks guys! =)

Start a new thread if you have a problem instead of digging up this zombie.

@pf$george how did you get all IPs of Facebook? Did you list down all IP ranges stated in the https://ipinfo.io/AS32934 website?

Thanks it was as easy as changing the Interface > Assignments to a new different port.

Those spurious retransmission and Dup ACK errors are going to hang your connection and cause the issues you are seeing.  Do you see those errors for any other communications, or just with this mail server?

Still no insights?

change the update settings to stay on the 2.3 branch

Thank you both. This was the "not an expert" qualification, although this seems pretty basic so I am embarrassed! It would appear that this traffic is simply between source and dest and pfSense isn't seeing anything.

I don't have a managed switch, though will be getting one soon to set up VLANs. Maybe I can try again then.