Port 3128 has been block in LAN…what happen?
-
google that port 3128, what is the answer?
-
Your firewall rule 'Pass from Proxy' is not doing anything that isn't already covered by the default LAN to any rule.
The real question is: why is traffic on the same subnet even going through the firewall at all?
Note that all the blocked traffic is TCP:FA. Perhaps this is the reason:
http://forum.pfsense.org/index.php?topic=35400.0What are the devices that are in the firewall logs? Clients? Servers?
Steve
-
Your firewall rule 'Pass from Proxy' is not doing anything that isn't already covered by the default LAN to any rule.
The real question is: why is traffic on the same subnet even going through the firewall at all?
Note that all the blocked traffic is TCP:FA. Perhaps this is the reason:
http://forum.pfsense.org/index.php?topic=35400.0What are the devices that are in the firewall logs? Clients? Servers?
Steve
i don't really understand the answer from the link…
-
You have a routing problem. Somehow your traffic is being routed through pfSense even though it should be going directly. Traffic cannot be routed in and out of the same interface, it causes problems such as you are seeing.
Without knowing more about your setup it's impossible to say what's going on.
Are you using Squid on port 3128? Is it in your pfSense machine?
Why have you removed the last octet of the destination IP in your firewall log? It's a local IP. Are they all the same?
One thing that may possibly cause this is if your lan DHCP server is giving out the wrong subnet, e.g. /32.
In this case your clients can only 'see' the gateway and not other local IPs. Hence all traffic is sent via the gateway.Steve
-
Thanks Steve
The problems solved after i upgrade the box to 2.0-RC3 (i386) built on Fri Aug 12 16:23:11 EDT 2011 version ;D
Yes…the last octet the i removed is the PfSense server private IP...and the port 3128 is the default proxy port in my box.
-
Hmm, a bit of a mystery then. Well, at least it's fixed. ;)
Steve
-
I think this has nothing to do with routing problems.
I have these log, too just with port 80 (tranparent proxy).Jim-p posted in other threads that this a behaviour of SPI (Stateful Packet Inspection) firewalls. The firewall only allows packets/traffic if there is an active state in the firewall table. If there isn't any traffic for a firewall state the the firewall reset this state. if then the website is answering to this "old" connection then the firewall is blocking this because there is no active state in the firewall anymore.
Perhaps this will help you:
http://en.wikipedia.org/wiki/Stateful_firewall -
I think this has nothing to do with routing problems.
I have these log, too just with port 80 (tranparent proxy).Jim-p posted in other threads that this a behaviour of SPI (Stateful Packet Inspection) firewalls. The firewall only allows packets/traffic if there is an active state in the firewall table. If there isn't any traffic for a firewall state the the firewall reset this state. if then the website is answering to this "old" connection then the firewall is blocking this because there is no active state in the firewall anymore.
Perhaps this will help you:
http://en.wikipedia.org/wiki/Stateful_firewallNice one….so this happens when user open a browser/80 port traffic, then he/she leave it idle for long time? is that what it mean? Thanks
-
I think this has nothing to do with routing problems.
I have these log, too just with port 80 (tranparent proxy).Jim-p posted in other threads that this a behaviour of SPI (Stateful Packet Inspection) firewalls. The firewall only allows packets/traffic if there is an active state in the firewall table. If there isn't any traffic for a firewall state the the firewall reset this state. if then the website is answering to this "old" connection then the firewall is blocking this because there is no active state in the firewall anymore.
Perhaps this will help you:
http://en.wikipedia.org/wiki/Stateful_firewallNice one….so this happens when user open a browser/80 port traffic, then he/she leave it idle for long time? is that what it mean? Thanks
Yes, this is how I understad it from the text and from reading in the forum.
And port 3128 is squid because squid opend the connection for the user. -
This can also be caused by asymmetric routing as JimP said in the post I linked to.
If, for instance, you have outgoing http requests going via Squid but incoming replies going directly to the client then pfSense will see those replies unrequested, no state exists for them, and will block them.
This should never happen if you have Squid configured correctly.Steve
-
This can also be caused by asymmetric routing as JimP said in the post I linked to.
If, for instance, you have outgoing http requests going via Squid but incoming replies going directly to the client then pfSense will see those replies unrequested, no state exists for them, and will block them.
This should never happen if you have Squid configured correctly.Steve
Of yourse you are right! But I think this would mean that the client cannot browse the web (correctly).
But browsing the web works - as far as I understand him. -
I agree. I can't see how this would happen, I can't even think of a way to do it deliberately! ::)
However since it seems to be related to Squid it probably shouldn't be ruled out completely.Steve
Edit: Perhaps with multiwan, do you have more than one WAN?
-
I agree. I can't see how this would happen, I can't even think of a way to do it deliberately! ::)
However since it seems to be related to Squid it probably shouldn't be ruled out completely.Steve
Edit: Perhaps with multiwan, do you have more than one WAN?
The firewall rules are showing just the default gateway ( * ) and no gateway group.
-
The firewall rules are showing just the default gateway ( * ) and no gateway group.
Good point!
Well if it's not a multiwan with squid setup, which seems to be a common source of problems then I would suggest:
Squid setup incorrectly?
Bad web application?
Something really obscure!Steve
-
Take a look at this thread and the first few posts of "cmb"
-
Useful post.
It doesn't answer the original question though.
The firewall is blocking FIN ACK packets, perhaps legitemately. Why?
It looks like the clients are sending FIN ACK packets to Squid expecting an ACK packet in return but are being blocked.
Since this is only used for gracefully finishing a TCP session the clients are still able to see webpages.
Odd that more Squid users aren't complaining. :-\Steve
-
Squid may be closing the connections early, and pf may be removing the states due to that. The blocks you are seeing are just traffic that arrives after the state has already been removed. Not really necessary for normal operation, people wouldn't even notice that in most cases.
