EasyRule Adds Rule to Wrong Interface
Diagnosing a VLAN issue here and came across some really strange behavior with PFSense. I'll provide photos below which should make it pretty self explanatory. Basically, when adding an easyRule from Firewall logs, it doesn't actually put that rule on the right interface.
I click the plus on the destination to make the EasyRule and then this happens.
So far so good right?
Then I click confirm and this happens.
The rule ends up on an entirely different interface, and I'm thinking something might be wrong with my install here or something. As I've had some other odd behavior happen with this WANUPLINKS interface (which to be clear is just a LAN interface which I've named that as I double NAT some test firewalls behind this install).
Note: just FYI I changed the TrueNAS IP to the .50 you see here instead of the .100, wanted to see if an IP change/refresh on the TrueNAS would help.
Additionally it seems my firewall rules for my TrueNAS in specific aren't being respected, whenever accessing the TrueNAS on my management interface VLAN (from the LAN) it constantly refreshes (but does connect) and I get a massive log pile of the below despite there being a pass rule for this traffic:
This indicates to me that despite this IP allow passing of all traffic from my LAN PC to the management IP of TrueNAS, it's blocking it anyway.
Also the previous issue in this post seems to be related to that being my original default LAN interface that I renamed later, is that just how EasyRules work? Do they not dynamically updated with the correct interface?
What its blocking is out of state traffic..
Your blocks are Acks.. notice the FPA, FA and PA..
You have states resetting? Or your asymmetrical?
@johnpoz Right, this makes sense. I'm not sure what would be resetting the states so frequently though as there are pass rules that should have states open for a while right?
I can't help but think something else is going on here but just not sure what it is. The thing is, no other HTTP/S traffic is having the states reset like this, and since it's all using the same rule with Alias's I can't help but think something's not right.
You could be having a state reset via a RST from one end, and firewall closing the state. While the other one is sending FIN.
Are you saying the connection never works? Or you just see blocks in your firewall? Could be old session that never got closed because the client trying to resuse old, or when switching from different network - do you have multiple wifi networks?
You should sniff the whole conversation to figure out what is actually going on. But if you see blocks with A (acks) then its out of state traffic blocking them.. Normal blocks would be via the SYN (S), where pfsense says NO not going to open what your trying to go to..
If you see SA blocks (syn,ack) then that screams asymmetrical where pfsense never saw the syn to open the state. Other things with A like FA or RA - point to for whatever reason state is not there.. being closed from one end, reset by the firewall.. This can happen with a wan going offline and setting to reset states when that happens??
You would need to investigate deeper.. But setting a firewall rule is not going to get rid of out of state blocks.
@johnpoz I can still connect to the web interface on the TrueNAS here, it just resets periodically. So I'll be using it to adjust something and it will just disconnect and refresh the page, but it's not happening when I access it on the same VLAN which does indicate something is happening with the firewall.
I do have multiple wifi networks but all clients here are on ethernet.
Appreciate the info here, I will do some more sniffing to see if I can figure out exactly what is going on here, it's definitely a bit odd behavior though. I get that firewall rules won't get rid of out of state blocks, but at the same time, shouldn't adding the firewall rule allow the state to be established in the first place?
state to be established in the first place?
You would never have gotten connected ever if state wasn't created - and you would see a block on Syn only..
If your saying works, and then resets - points to either say the server closing the connection with Fin or RST and state being closed, until client reopens with SYN.. Or states resetting if pfsense was resetting all the states - then you would see such blocks for every connection..
Sniffing is your friend in trying to figure out what is going on.. when you create the connection and page first loads - you can check for yourself there is a state.
When on same vlan - then no states, no having to recreate a session if one side sends fin and other end doesn't want to close the session yet.
Sniffing will show you exactly what is going on.. Also watch states via pfsense state table, etc.
when I access it on the same VLAN
Your client that accesses the nas is not multihomed is it? Where one leg in the nas leg and another leg not in that vlan?
@johnpoz Thanks for the help here, I will dig into this more after work today to see if I can figure it out and report back in case others see the same behavior. It would seem this could come down to an issue with the TrueNAS since the initial connection is being made so the state should be created.
I didn't even think about the fact that the same VLAN doesn't require states, which would prevent me from noticing the issue even if TrueNAS was doing it, thanks for that, just didn't click in my head for some reason!
Really appreciate the help and thoughts here!
Well there is no firewall states that could or allow or not allow traffic. There is still typical handshakes to open and close the tcp session.. But if your not seeing the stated closed because oneside sends a fin and the other doesn't want to answer the fin, etc.
So depending on what your actually seeing in the browser - can you tell when this happens in the browser or connection to the nas, or are you just noticing it in the firewall log?
@johnpoz I can also tell when it's happening in the browser, the entire management GUI refreshes and reconnects every 10-15 seconds when accessing it across VLANs.
and what your connecting from is only in the 1 network, its not multihomed where it could have a connection to the nas via multiple paths. Or the nas its not multihomed? Where you could have some asymmetrical flow?
@johnpoz The NAS is multi homed, however it's default connection is the management network, so I don't think that would be the cause either.
I haven't had time to do some packet captures yet but I will give that a shot soon.
so I don't think that would be the cause either.
Multihome devices with legs in multiple networks are quite often a source of asymmetrical traffic flow.
If you talk to it from 192.168.X.X network to its 192.168.Y.Y address and has an interface in 192.168.X it will answer back from that interface.. almost always!