Firewall rules ignored or overridden?
-
No, only the client and server know why the connection is closed. All the firewall cares about is that the two parties on either side decided to close the connection.
pfSense is only logging the firewall exceptions because the client and server decided to close the connection then one of them decided to try to pass more traffic over the closed state.
Packet capture. Who is closing the connection?
-
" I see TCP 993 connections being opened and closed."
Post up this sniff.. As Derelict stated if client or server is sending fin?? Did the other ack with a fin as well.. Fin does not mean the connection has to be closed, it is just stating hey I am done, are you done too?
You really need to see the sniff of the conversation to figure out what is going on. If you have conversation being closed and then still trying to talk on it that is a problem. Because yes when the firewall see's that devices closed their conversation he will remove the state, and until his sees a new conversation with syn, those packets would be out of state and dropped.
-
Okay, I've made some progress but the issue is still not resolved.
From the pfsense terminal:
telnet imap.gmail.com 993; //Successful connection
telnet imap-mail.outlook.com 993; //Successful connection
telnet imap.mail.yahoo.com 993; //Successful connection
telent imap.comcast.net 993; //Successful connection
telnet imap.aol.com 993; //Successful connectionFrom any workstation:
telnet imap.gmail.com 993; //Successful connection
telnet imap-mail.outlook.com 993; //Connection fails
telnet imap.mail.yahoo.com 993; //Connection fails
telent imap.comcast.net 993; //Successful connection
telnet imap.aol.com 993; //Connection failsFor IMAP servers that fail, a packet capture on the LAN shows the following:
1. Initial Syn packet from the workstation
2. Followed by a tcp retransmission to the same IMAP server 1sec later
3. Every 1sec another retransmission occursIt looks like pfsense silently drops a packet so the connection never succeeds. The strange thing is that this doesn't occur for all IMAP servers.
-
What magical packages like pfblocker, snort, suricata, squid, and squidguard are you running?
-
So your saying the packet never goes out the wan? But you see it on the lan of pfsense..
-
No relevant packages installed. Just Status_Traffic_Totals for bandwidth stats.
I just performed a packet capture from the WAN interface and I am seeing tcp retransmissions from the IMAP server to m public IP. It looks like only the SYN packet makes it out. After that the SYN/ACK gets dropped so both sides keep retransmitting. The workstation sends SYNs and the IMAP server sends SYN/ACKs.
Also, pfsense logs the blocked packet sometimes. When it does, it is listed as:
The rule that triggered this action is:
@5(1000000103) block drop in log inet all label "Default deny rule IPv4"My LAN Firewall rule to pass IPv4+6 TCP out to port 993 should implicitly let this traffic back in. It is letting the SYN out but the implied pass for the SYN/ACK back in is not being respected.
-
Note that I did have packages installed in the past however I have since removed them and they reported that the removal was successful. So unless package removal is totally broken, then there should be no package filtering. This should be purely a pfsense filtering issue.
-
Get the IP address of the server and while all that is going on, what states do you have in Diagnostics > States?. You can filter on the IMAP server IP address there. That will catch both WAN and LAN states.
No, packages removed should be OK.
-
See image.
-
If pfsense does not see the syn,ack back the state would never go into established and would time out in by default 30 seconds. Then packets after that would be dropped by the default rule because there would be no state.
It could be less than 30 sec if you messed with the setting on the firewall..
"After that the SYN/ACK gets dropped so both sides keep retransmitting."
Gets dropped where? Your saying you see this syn,ack on your wan sniff??
-
Well, there are your firewall states.
All looks fine.I didn't look far enough over - you guys and your large screen captures… So what are the exact blocked packets you are seeing on WAN?This all just works. Not sure what you did to break it.
If you feel like it do a Diagnostics > Command Prompt and execute cat /tmp/rules.debug and paste the results in a PM.
-
I'm looking through rules.debug and near the top I see entries that concern me. Specifically the following:
#Snort tables
table <snort2c>table <virusprot>As I mentioned previously, I initially installed some ports but subsequently removed them and success was reported. Would successful removal of the relevant ports also remove these artifacts or are these inactive entries in the ruleset which have accumulated from the previous ports but which now have no effect?</virusprot></snort2c> -
Those are always there. I don't think that's it.
From the PM'd pcap it looks like IPv6 is working and IPv4 is broken. That is probably the difference between the different IMAP servers.
-
Yeah. the presence of AAAA records corresponds to the servers you report as working. The ones that fail do not have AAAA records.
So un-do whatever you did for IPv4 and make it look like IPv6 and you should be GTG. :)
-
Not so easy.
Floating Rules:
All rules here are pass or match and unrelated.WAN Rules:
All rules here are pass except for pfsense's block RFC1918 and block bogons.LAN Rules:
All rules here are pass except for NETBIOS on my network.
Also, the rule allowing traffic bound for 993 is an IPv4+6 rule so if it is passing v6 traffic then presumably it is passing v4 traffic as well.Unless there are some other hidden rules then that is everything.
-
Yeah looks like you have ipv6 working, but don't see the start of that conversation. But looks like all your ipv4 is borked..
Where exactly did you sniff this?? Looks like syn,ack is sent from public to a private.. But no answer??
-
Not sure what to tell you, man. You screwed the pooch somewhere along the way.
Send your /tmp/rules.debug
-
That is a microsoft IP.. Clearly its sending a syn,ack to private IP address. So that was on the LAN of pfsense?? Where was this sniff taken?
-
You don't have like LAN and WAN on the same dumb switch or something do you? Something's not right there. It's like that capture contains both pre-nat and post-nat replies.
-
So yeah this is odd.. Looks like wan sniff showing your public IP sending syn to the public IP. And you see the syn,ack back. And then you see the syn,ack sent on to the rfc1918 address?? But then you see a retrans of the syn back to the server from your public..
So the client never saw the syn,ack so its resending syn.. But if we are seeing the lan side of this - where was the syn from the client?
Need to understand where you sniff this at.. Something is not right here.. If we were seeing both wan and lan sides of the sniff.. Then we should of seen the incoming syn to to the pfsense lan, and then it going out the public, then the syn,ack coming back, and then it going out the lan, etc.. But where is the original syn from the 192.168.1.40 addess if that is the case??
You got some sort of asymmetrical issue going on?? Where the syn from the client is coming into pfsense, but its sending the traffic back to the client on wrong interface? But where exactly are you sniffing that seeing both wan and lan traffic?
