LAN Allow Rule Overridden by Default Deny
-
Yeah there is a bunch of retrans because your not getting any answers.. And then the 10.x box finally says F off with the RST..
its a pcap of encrypted traffic.. Post it here or post it somewhere.. We can always just delete the pcap you post here after I have it downloaded..
-
This post is deleted! -
there is some sort of communication problem that happens.. the flurry of retrans is client trying to get an answer.. Which he finally gives up and sends RST.. End this conversation..
Your prob missing part of the conversation maybe because your only seeing tcp.. RDP will switch to udp..
-
Here is a normal rdp session.. Which not seeing your hellos
And then once auth is does, you will switch over to udp.. Or it normally would if connection is good.
But I see nothing there that point to anything wrong with pfsense.. Are you loosing your state? And this why traffic isn't getting through? I don't think so because all of the retrans Would all show block in the firewall log if the state was gone..
-
This post is deleted! -
You need to see why your seeing all those retrans.. Why does the client not answer..
But what your seeing in the log is normal.. Not pfsense blocking anything that shouldn't be blocked.
-
This post is deleted! -
Sniff on the other side do you see the packet get to the client.. Why no answer? And its exactly same seq and ack numbers in 2nd pcap..
1026 and 5504
You have something going on in your RDP connection that seems unlikely to be network related if you get failure at the exact same point in the stream.
Problem with encrypted traffic - its difficult to troubleshoot.. Do you get some errors in the event log for the rdp session?
-
This post is deleted! -
Why did you delete all your posts?
-
@johnpoz Thank you for your help with this.
For anyone looking in the future: the pfSense firewall showed a block entry in the firewall log for what we think was an out of state packet meaning the data was being sent at a time that it should not have been.
In our case, the block entry in the log was confusing because pfSense was not actually blocking the RDP connection itself. Rather, the thin client was misconfigured in a unique way that would only work if directly connected to our main network. The thin client's RDP connection would fail (and pfSense would show the block) only when the thin client was connected to the bespoke hardware pfSense router and it was connected back to us over IPSEC VPN. (just in case it helps anyone else, our thin client had its own MTU setting which need to be set lower than that on the pfSense WAN but ours is a bit of a unique case)
In short, if you have a case where the "Default deny rule IPv4" seems to override your allow rules it probably means the device sending data is misconfigured. Exactly how it's wrong will depend on the device.
-
@johnpoz the forum wouldn't let me edit the original post to explain the resolution. The issue wasn't pfSense at all so the other posts would just be confusing to anyone coming across the same problem in the future.
Thank you for your help with this, I appreciate it!
-
Yeah told you right up front wasn't pfsense ;)
Glad you got it sorted.. Can just delete this whole thread if you want. But should leave something showing the R in the log, and how that is just pfsense blocking what is out of state traffic, etc.
Unless you see S on the log, it means the traffic is out of state for whatever reason.. And yeah that will be blocked by any stateful firewall ;)
