Samba share access problem from behind pfSense latest builds
-
Hi
I have problem with samba share access from behind pfSense. Old old beta0 (from Sep 15 17:04:57 EDT 2012) works perfectly, after upgrade to the latest builds, Windows clients behind pfSense can't access this share (timeout). I have no clue how to troubleshot this problem, pings are OK, what else should I check, any ideas? I appreciate any hints.Best Regards
Marcin
-
The easiest / quickest way would be to go to webGUI Status -> System Logs -> Firewall and check if any traffic is blocked.
-
I always turn logging on for my "allow rules" when Im trying to diagnose. Even if the server behind pfSense does not accept the connection, pfSense will log it as a "pass" if things are good.
-
Two VMs with exactly the same configuration. Old September snapshot passing traffic on LAN to 10.8.6.1 where samba share is located:
But new snapshots blocks this traffic!
Why is that ? Is it a bug?
Best Regards
Marcin
-
What are the firewall rules on your LAN interface?
-
I can't publish all rules here , but I can assure rules are fine. For troubleshooting purposes I've even created additional rule passing and logging all traffic to 10.6.8.1 which is on the top. So… IMHO it is most likely some kind of bug.
-
I don't see any other lans in your setup, So are you natting between lan and wan(s)?
SMB/CIF across Nats not a great idea.
As to what your seeing in the log, not sure what :REQUEST is a flag - but those clearly are packets out of state so yeah they would be blocked.
See in your first posting where they worked, yeah they are SYN packets - those are let through without state already established.
So are you natting or not?
-
Correct 10.6.xx.xx is on WAN1, WAN 2 has public address, only 1 LAN subnet is defined behind NAT. I know NAT is not a good idea for SMB but there is no other choice in this case and it used to work for months without any problems before upgrade to the latest builds.
-
What do you mean there is no other choice? Why is your network connected to wan1 on a wan interface, its a public IP - I would think that should just be another lan interface.
-
What do you mean there is no other choice? Why is your network connected to wan1 on a wan interface, its a public IP - I would think that should just be another lan interface.
This is totally irrelevant . I want new builds working correctly in scenario I chosen like old ones. I don't want to change configuration because there is a bug in recent snapshot, I'd rather stay with old build until bug will be fixed.
-
Who says there is a bug.. firewall is going to block out of state traffic - this is how they operate, not a bug.
I don't think I have ever seen REQUEST as flag? or acket?? but yes your going to see traffic that does not math a state blocked.
You notice in your first post that the allows from your lan are Syn packets - so they would be allowed yes. But traffic your seeing block on your second image has those odd flags.. Which point to out of state traffic which = blocked.
Not sure why you would want to NAT traffic between your own 2 private networks? Do you have a gateway off your WAN1 that you use for internet traffic? If no then its not a WAN interface ;)
If you want to let devices on your 10 and 192.168 networks talk to each other - why would you want to nat between these networks? You would have to create NAT rules for anything on the 10 to initiate traffic to something on the 192.168 (lan)
-
Not sure why you would want to NAT traffic between your own 2 private networks?
This is probably not relevant to the particular problem, but NAT can save setting up static routes (because the traffic appears to come from a system on the "local" network and hence a route to a non-default gateway is not required). "Make it work but you aren't allowed to do anything to the server!"
-
True - hiding a network behind a different one would be reason for NAT.. But he still shows out of state traffic being blocked, not syn traffic being blocked.. So I don't see anything wrong in what he posted as a bug. Blocking out of state traffic is not a bug, its designed that way.
-
I wonder if there are multiple paths such that the TCP syn sometimes takes the "wrong" path.
-
Look at the raw filter log (clog /var/log/filter.log from Diag > Command or a shell prompt)
It may be getting blocked going 'out' LAN in which case you should be looking at the floating rules tab.
