Default rule - fail
-
my guess is that your connections are not near as sticky as you would like to believe.
Yeah, bingo.
-
If they aren't sticky then the option in pfSense for sticky connections doesn't work correctly - this is supposed to be a 'stateful' firewall.
The ONLY place the stickiness can fail is outbound - it can't fail inbound because the remote session is utterly unaware of the 'other' IP - meaning the only place that's common is pfSense not applying 'states' correctly and ensuring that a session started on WAN stays on WAN and the load balancing should respect that 'state'.
I can't possibly start a bunch of outgoing NAT - makes a nonsense of load balancing to do so - besides I'd need different nat for different devices to either WAN or OPT1 - I might as well run two seperate pfSense boxes if that's the case. If states aren't being respected then that's a bug IMHO.
-
Anyone know how to log which packets are going via which 'network' - packet capture can only work on one at a time.
I checked the state tables and it isn't indicated 'which' network the state belongs to - merely that a state exists. - I take that back - it calls it router - :o
I can't see the incoming 'router' though only the outgoing …
Thinking about this it still doesn't explain WHY an attempt to reach GMail via port 443 from the LAN is being blocked - it should be permitted - there ARE no block rules in place outbound on LAN, WAN or OPT1 .... inbound yes but there are no user defined OUTBOUND blocks.
-
Can't see the NAT for port 443
-
This has nothing to do with NAT or Load Balancing. It is the normal blocking of the final session packets FIN ACK because the firewall has already closed the connection due to receiving a RST from the destination or has otherwise closed the session
http://doc.pfsense.org/index.php/Logs_show_%22blocked%22_for_traffic_from_a_legitimate_connection,_why%3F
http://forum.pfsense.org/index.php?topic=58827.0
-
Hmmmm - If thats the case, then am I to understand that there has been no actual call drops or offline states being cause? Only some log noise?
Everything on the network works fine then? -
BenKenobe, on the mobile device are you actually being blocked from accessing gmail, or is it that you just see these blocked packets in the logs?
If you are actually being blocked and you just happened to post the log snippet that only contains the blocked FIN ACK packets, then you probably have a real problem, otherwise you are likely seeing the session reset packets only being blocked.
In your syslog do you see any other packets blocked by this default rule with flags different than FA such as SYN, SYN/ACK, etc.?
-
Yeah - I have a log full of these:
127.0.0.1:3128 TCP:FA
I ignore them. Everything is working fine.
Wouldn't it be nice if we could enter in a setting some place things to not log?
Like TCP:FA, TCP:FPA etc, etc…. It would make the logs more meaningful. -
I never asked her and she doesn't complain, I asked and her response is that mostly it is OK, occasionally it times out but not all the time.
If these 'blocks' are normal behaviour (which I appreciate) why log them at all - as has been said it would be nice to be able to clean up what is and isn't reported.
I'm just a little perplexed why a stateful firewall would block ANY outgoing packets unless explicitly told to do so, incoming I can buy into but outgoing - just doesn't seem right - why would the other side of the connection close the session - surely that's the session initiators job ?
-
Yeah…. and... Did I mention...
I have a log full of these:
127.0.0.1:3128 TCP:FA
I ignore them. Everything is working fine.
Wouldn't it be nice if we could enter in a setting some place things to not log?
Like TCP:FA, TCP:FPA etc, etc.... It would make the logs more meaningful.Maybe a regular expression filter as a package? Devs? Anyone...
(I hear crickets chirping...)
