Firewall rules ignored or overridden?
-
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?
-
Sorry for the delay.
The issue where I could not telnet to port 993 was caused by a Floating Pass rule allowing outbound traffic to TCP 993 in an attempt to solve the original issue. It is counter intuitive that a pass rule would cause traffic to get blocked however it looks like the floating rule prevented the TCP session which was originally allowed by the LAN rule passing TCP 993.
Although I can now telnet successfully to mailservers on port 993, the original issue still persists. See screenshot. I am trying to come up with an appropriate packet capture that I can provide to show this however I am having trouble sanitizing the capture to not reveal private information.
-
What is you want to pull out of the capture, or what do you want to change in like IP?
Normally best thing is to capture only want you want to share.. Changing the IP of is quiet easy with say https://www.tracewrangler.com/ or bit-twist.
As to your original issue.. All of those blocks you list are out of state.. FA, RA… To what your rules are doing? I don't see how a floating allow would prevent a lan allow? If you have floating and lan rules that do the same thing?? Its possible doing such a thing could lead you to a state of something being closed and then being seen on as out of state??
Really would need to fully understand your flow of traffic, making sure you don't have loops, and your firewall rules. If your PM to me was to say your sniff on the lan.. Then how were you seeing packets with wan address?? You got something clearly borked that is for sure..
A lan sniff should not show you wan traffic.. But in that sniff see SYN from public IP to your public dest.. Its like maybe you have some sort of issue where your running your wan over your lan layer 2? But yeah if pfsense sense is seeing a FIN to close the state, and then sees another FIN to close the state it already closed then it would be out of state and listed as a block..
This seems like what is happening. Your sniff if that was on the LAN of pfsense or some other device or port on your LAN.. It should be impossible to see your public IPs.. But they were in there along with rfc1918 address of 192.168.1.40??
