LAN to WAN port 443 blocked by rule that can't be found
-
@eds89 said in LAN to WAN port 443 blocked by rule that can't be found:
routed via WAN gateway
Your forcing this? Please post up your rules.
Depends if you can ignore.. Sounds like from this something isn't working
It seems that even if the packets are bogus, the hosted app expects those packets.
You say you swapped to a hotspot? So you have some sort of wireless setup that you didn't mention?
You can see out of state packets when say a phone switches from cell to wireless.. Or a device has been offline for a long time and then reconnects and trying to reuse the same old sessions. So do you have some wifi AP connected, a wifi router involved?
Do you have anything coming inbound through your vpn client connection to some host behind? Are you running vpn connections on the clients themselves vs just on pfsense? Lets see your rules on how your doing policy routing... And then what was that traffic you were seeing blocked. Looks like 2 sessions from your 10 client talking to google IPs.. Did that client switch over from using vpn client on it, or did you start policy routing it? Did you reset your states on pfsense... This will also cause a flood of out of state blocks.
-
Just to be clear, you are mixing what I and lohphat have been saying.
I am the OP, and posted my setup above. I was not the one that mentioned wireless, and I am not the one with apps actually facing issues.
But yes, I have a rule for a specific host forcing traffic via the OpenVPN gateway, and then a rule below that forcing everything else out via the WAN gateway.
Here are my LAN rules:
https://1drv.ms/u/s!AkX0yYmTeiFtiexLiwSVAZokQ3u4kwFirst three are set to ensure that traffic for web interfaces goes out over WAN, determined by port number.
Fourth rule forces everything else for that host out via the OpenVPN.
Fifth rule says any other LAN device should use WAN gateway not VPN.Hope that helps?
Eds -
I hate it when people chime into threads like that with no mention of hey I am seeing same sort of thing, etc. etc Thanks for pointing that out and sorry for the confusion.
Your going to see out of state now and then.. Not anything to worry about unless your seeing a flood of it all the time and having some sort of issues.
Ie the link states why you might see those.
-
No problem at all!
I don't think I've ever seen LAN packets blocked in the past, and only noticed since I setup my OpenVPN connection, although I don't think it's setup in a way that would cause asymmetric routing.
Most of the packets seem to be port 443 from my Amazon Echo devices to Amazon servers.
They all seem to be working without issue, so suspect it's going to be safe to ignore.Thanks.
-
Well your echo devices are wireless - that I am sure of, since I have a few.. So yeah wireless devices can cause those sorts of out of state.. Even without anything odd going on..
Packets could get retransmitted... once the firewall sees fin it will close the state. So if it sees a dupe packet after it has closed the state then it would be logged as blocked..
So yes its going to be normal to see such traffic now and then... My son's phone use to do it all the time.. If your really bothering you, you could turn off the default logging and just log syn packets that are blocked or don't even log blocks on your lan interfaces, etc..
And just turn it on if your troubleshooting something and wondering if something is being blocked, etc.
-
@johnpoz I'm working on the problem from the ground up by restarting from an initial install. The app is working again after starting over.
So far it's not the base config or IPv6 or restricting DNS to just the f/w.
I'll layer on pfblockerNG and then snort to see who the culprit is. I'm not doing a lot of custom tweaking just using base block lists and default settings.
When I get to the root cause I'll report back. I need to get my hands dirty with this anyway.
UPDATE:
Found it! It was pfblockerNG with the first list I confiured: Steven Black's List. It was "api.gameanalytics.com" and once I whitelisted that, the application worked.
What was frustrating is how it manifested itself as a login protocol error. I was checking the f/w logs and snort logs but didn't think about DNS as a cause. Duh.
I has a smart nao.
-
Next time start your own thread vs jumping into something clearly not related to your shoot your self in your foot scenario with pfblocker and snort.
-
@johnpoz My apologies. I thought it was related by the initial data. Sorry for my learning curve.
It would have been easier if I could have filtered the suspect IP in the pfsenseNG logs but that has its own limitation of only filtering displayed log entries, not the entire history, so I missed that diagnostic route and the only thing left were the entries similar to these in this thread.
-
bump your history up if you want to be able to see more. I have my gui set to 2000 past entries. You can also bump up the size of the circular logs and view them with clog.
Best if you want "history" is to offload the logging to your own syslog.. Then you can parse that with all kinds of fancy tools.
-
@johnpoz The DNSBL settings for displayed log entries is capped at 1000 in the UI.
I know I could offload logs but I'm trying to keep it self-contained. I'm shooting for less complexity, not more.
Thanks for your patience.