upgraded to pfsense 2.8.0, WiFi devices report intermittent 'no internet access'
-
When I looked into my predicament yesterday I came across "asymmetric traffic" from TCP:SA.
But, if a pfSense config works fine on 2.7.2, shouldn't the exact config work just as fine on 2.8.0? The config is what drives the firewall, no.Perhaps the AP update is the issue and not pfSense. I have to gather more information.
-
Done some testing.
My laptop was working fine all day. I put it to sleep when not used, but with Win11 the laptop never truly sleeps instead goes into low power state.
When I manually disconnected it from WiFi. Once reconnected none of the sites could connect except gab.com. When trying youtube.com, for instance, it would not load. After some time (2-4 minutes) it would load but thumbnails would be blank. I can click those thumbnails and the clip will play fine. When a clip plays, the suggestion list on the right has blank thumbnails.
Perhaps it is an issue with reconnecting to WiFi.
I can ping all websites (via names, not IPs) and that works. I even pinged a website I have not visited on this laptop and that worked.
When the problem shows up in the Firewall log there is crap load of TCP:SA entries. From what I saw they have '"direction is out" (right arrow) LAN' under Interface column, website (external) IP under Source column and laptop (local) IP under Destination column.
Could AP be issuing bad packets, like flipped website and local IPs, to pfSense?
If we talk about asymmetrical traffic, would that happen always and not just sometimes (perhaps just after reconnecting to WiFi)?
I'm going to run packet capture tomorrow, perhaps that will give me some further info.
Given that I have updated my AP, I'm leaning towards it being the issue. All wired clients work no problem. Cell phone still can't get internet connection after connecting to WiFi. The same TCP:SA entries show up for it in the pfSense Firewall log.
After connecting to Wifi my problem shows up but after about 15 mins it disappears. I just verified this twice in a row. Theoretically then, if I remain connected to WiFi websites should work fine. I will be testing this theory.
-
@skubany2 said in upgraded to pfsense 2.8.0, WiFi devices report intermittent 'no internet access':
The same TCP:SA entries show up for it in the pfSense Firewall log.
That doesn't really make a lot of sense to be honest, since a SA is an answer to something that sent a S to the device.. Your clients wouldn't send SA to pfsense unless it was trying to send an answer that sent it a syn, and how it thinks it should answer is to send to its gateway (pfsense)
A client would never send a SA trying to talk to a website that it initiated the connection too.
You could see this for example if you had a port forward to this device, from some other gateway, and this device that got the syn gateway is pfsense. You could see dupe Acks, or FA, etc.. being sent to pfsense when a client saiy woke up and tried to continue a conversation it had open before, when pfsense had closed the session due to timeout, etc. when the device was sleeping. But it wouldn't send SA. A client making a new connection to something would never send SA, SA are answers from a device trying to answer a connection request (syn) sent to it.
Windows is notorious for having problems when coming out of sleep.. But it would never send a SA trying to open a connection to something.
-
My ordeal has reminded me of a problem that my father is complaining about, which showed up a year or so ago.
He states that when he disconnects WiFi, he has to wait a few minutes (10-15) or turn off his computer for a few minutes before WiFi starts working.
His laptop has Ubuntu but the AP he uses is the same as mine, though I don't know which version the AP is on. He uses pfSense as well but on Netgate hardware. I built my own PC for pfSense.
-
2.8.0 saw the default firewall state policy switched from floating back to interface bound. The floating states could have allowed asymmetric internal traffic and it's now being (correctly) blocked.
You can test that by setting the policy back to floating:
https://docs.netgate.com/pfsense/en/latest/config/advanced-firewall-nat.html#config-advanced-firewall-state-policyIf that allows the traffic you should investigate what is causing the asymmetry and correct it.
-
@stephenw10 while agree with you if the traffic was internal.. Just at a loss to what sort of setup they could have that a client trying to open up say www.netgate.com would ever in a million years send an SA anywhere..
@skubany2 are you seeing these SA block on a wan interface of pfsense?? where client behind pfsense sends its syn to say www.netgate.com and the SA is coming back to pfsense on some other interface.. Not really sure how that could happen either - but has to be more possible than a client behind pfsense wanting to open a connection through pfsense and also sending SA..
But guess there could be an issue with the state being opened, and when the thing outside pfsense answers with its SA, pfsense doesn't have a state open so blocks it.
-
@stephenw10 said in upgraded to pfsense 2.8.0, WiFi devices report intermittent 'no internet access':
2.8.0 saw the default firewall state policy switched from floating back to interface bound.
That did it! Cell phone connected to WiFi now!
But you claim that is not the way to properly configure a router. I will have to look into this. With 'state policy' I will probably have to connect WiFi to pfSense differently than I have now (more rules/interfaces/etc).
If you, or someone else, has a helpful article to achieve that please share.
On my router WAN & LAN are on built in NICs (motherboard). And WiFi connects to a two port POE gig expansion card connected via PCI-E.
Edit: That kind of change is big. While I'll admit I don't really read change notes, this should have been made very clear, if wasn't.
Edit #2: pfSense at my parents house is on version 24.03-RELEASE (arm) and it has "Interface Bound States" set. I configure it just like I did mine and he has external AP exactly like mine, yet for him the internet seems to work fine, other than that ~15min outage after reconnect to WiFi that I mentioned. I was able to connect my phone to WiFi when I was there, thought I think he never could connect his old (some chinese model) cell phone to WiFi. I might check if he is getting TCP:SA when that ~15min outage happens and will ask if he can connect his current phone to WiFi, I'm not positive that he can.
Edit #3: In my parent's pfSense I see his cellphone hitting the TCP:SA issue I had, but doesn't appear as frequent as was with me. In my case it was hundreds of those entries. -
@johnpoz said in upgraded to pfsense 2.8.0, WiFi devices report intermittent 'no internet access':
@skubany2 are you seeing these SA block on a wan interface of pfsense??
Don't remember seeing them on WAN. All that I saw were on LAN. They look like this, the redacted IP is a local machine connected via WiFi:
-
Is there a way to mark my issue resolved pointing to the post which solves it?
So others can benefit from it in the future without reading everything that is in the thread. -
@skubany2 that is an OUTBOUND rule.. So you have some rule in floating..
That is the answer from server you were trying to talk to on port 80.. But you have an outbound rule in floating tab.. Why would you have such rules??
And what do you think hiding some rfc1918 address does you... Oh no your IP address is 192.168.1.42 - someone will hack you?? Like telling someone hey.. I am on the planet earth.. There is zero reason to hide rfc1918 space..
example;
$ ipconfig /all Windows IP Configuration Host Name . . . . . . . . . . . . : i9-win Primary Dns Suffix . . . . . . . : home.arpa Node Type . . . . . . . . . . . . : Broadcast IP Routing Enabled. . . . . . . . : No WINS Proxy Enabled. . . . . . . . : No DNS Suffix Search List. . . . . . : home.arpa Ethernet adapter Local: Connection-specific DNS Suffix . : Description . . . . . . . . . . . : Killer E2600 Gigabit Ethernet Controller Physical Address. . . . . . . . . : B0-4F-13-0B-FD-16 DHCP Enabled. . . . . . . . . . . : Yes Autoconfiguration Enabled . . . . : Yes IPv4 Address. . . . . . . . . . . : 192.168.9.100(Preferred) Subnet Mask . . . . . . . . . . . : 255.255.255.0 Lease Obtained. . . . . . . . . . : Wednesday, August 27, 2025 1:36:28 PM Lease Expires . . . . . . . . . . : Thursday, September 4, 2025 1:36:27 PM Default Gateway . . . . . . . . . : 192.168.9.253 DHCP Server . . . . . . . . . . . : 192.168.9.253 DNS Servers . . . . . . . . . . . : 192.168.3.10 NetBIOS over Tcpip. . . . . . . . : Enabled
That is info from my pc - what do you think anyone could possible do with the info that my machine is 192.168.9.100 on a /24 network whose gateway is 192.168.9.253, and my pihole (dns is on 192.168.3.10..
What do you think someone could do with such info?
-
"hiding some rfc1918 address", I think I saw you reply similarly to someone else or at least someone did as I remember seeing something like this two days ago when I was looking into my issue :)
Onto "Outbound rule". I have three Floating rules. One disabled, another enabled but applies to a specific client which does not play a role in my troubles with TCP:SA. I set those up to enable Tagging for a 'VPN client' I was configuring on my router a while back but not using (disabled) at this time.
I run packet capture on WiFi interface:
First my WiFi AP (using MAC, APs MAC) sends RRB packet.
Then my cell phone (using MAC) sends LLC packet to Broadcast.
Then my cell phone (using MAC) sends ARP packet to Boradcast asking "who has <my LAN IP>?"
Then my WiFi Interface (using MAC, expansion card's MAC) answers to my cell phone.
Then my cell phone (using IP) sends syn to external_host:80.
Then my firewall log shows that the acknowledgement on LAN interface is blocked when sent by external_host to my cell phone (using IP). Ports on request and response match."using MAC" means that entries in packet capture are showing destination/source addresses as MAC.
"using IP" means that entries in packet capture are showing destination/source addresses as IP.Any of that looks out of place?
I tried capturing packets on WAN and LAN but that didn't really show anything interesting.
-
@skubany2 The rule clearly shows it blocks outbound on your lan - the only way to have outbound rules is in your floating tab - show a screen shot of your floating tab..
How do you have a default deny outbound rule?? Post up all your rules.. There is clearly something borked with your setup.
This is a client wanting to talk to something out on the internet - it sends a S (syn) to pfsense gateway, I want to go to 1.2.3.4, pfsense nats this traffic to your wan IP, lets say its 5.6.7.8 and sends it out its wan.. This is allowed by your normal default any any lan rule inbound into your lan interface, this creates a state..
When 1.2.3.4 answers your syn with a SA (syn,ack) he sends it back to your IP 5.6.7.8 pfsense says hey that is to port X from 1.2.3.4:80 that state I have says send to 192.168.1.100 because that is who I allowed out and created the state for.. This would be outbound on your lan interface..
That firewall log you posted says hey block outbound on my lan..
There should never be a block outbound on your lan like that, and it sure shouldn't be a default deny rule..
Your AP for wireless has ZERO to do with pfsense logging a default deny outbound on the lan.. Please post up your rules if you want help.
-
You will see blocks like that with the default outbound rule if the SYN from the client didn't come into the LAN. Which is excatly what the floating state binding would allow.
So it appears that you have some other route into the firewall that wifi clients are using. That is creating asymmetry and that is causing the problem here and should be corrected.
To make that happen though you need to have some unusual network setup like bridged interfaces perhaps?
-
-
Yes, I do have a bridge and I expect that I will have to remove it and connect interfaces LAN & WiFi via rules.
-
You shouldn't have to you just need to make sure traffic is opening states on the correct interface.
Do you have bridge filtering set to the bridge members or the bridge itself?
Do you have the bridge assigned?
-
@stephenw10
I only have the bridge because when adding external AP the tutorials I looked at said I need it.
I don't have it assigned to anything. I don't filter on it. I don't explicitly use it for anything.In 'Floating' rules I had entries because under WiFi interface I have a rule that WiFi should not go out to 'LAN subnet'. I don't want WiFi devices to reach my LAN in general, unless explicitly allowed (via rules). Sometimes, the "WiFi Client" from the picture with Floating rules I posted reached my LAN and I wasn't sure why so I put a Floating rule to forbid it. The Floating rules are executed before any other in the firewall.
-
@skubany2 your last rule there where you say don't allow lan access is wrong.. That is a ! lan subnets - it would block everything that is NOT the lan subnets.
none of those rules show any hits..
-
I would guess that traffic from the clients is coming in the WIFI interface and going out the LAN because that's where the subnet is defined. The bridge allows that to work because everything uses the same subnet but pf sees that as asymmetric.
Unless you need to filter between the wired and wireless segments you should move filtering to the bridge, assign the bridge and add the subnet on the bridge directly with neither member having a subnet defined.
-
This is such a borked up config.. Why are you bridging? Why would you bridge if you don't want to allow wifi talk to lan?
I take it your again hiding your rfc1918 space where you put in wifi clients - so these are different networks - again why bridge?
What exactly are you trying to accomplish - there is almost never a good reason to bridge..
If you want to leverage a port on pfsense for your AP - then put it on its own network, and just allow what you want. If you want wifi on the same network as lan plug your AP into your switch.
If you want multiple networks on your AP via vlans and one of those is your lan network - then have a vlan capable switch and again plug your AP into your switch.