Within a Poc with a PAN Firewall we ran into the following issue:
A terminal server (with TSA) in network a ist connected to a PAN Firewall. Fileserver in network b is also connected to the PAN Firewall.
Everything is configured properly and first testing are successfully done. (icmp, http). I were able to reach the Fileserver from the terminal server (both Windows Server 2012 R2). I could see in the logs the zones and the MS AD Users. Everything worked fine. But when I tried to open a smb share on the Fileserver it didn't work. (Windows Explorer: \\ip-address\c$) In the logs of the PAN I could see, that the traffic arrived on the Firewall, but no user was displayed. It seems that the TSA on the terminal server isn't mapping the user to ip (and port number). but only with this protocol.
does anybody know anything about this issue and how to fix it?
Thanks in advance!
Mapped drives/fileshares run in a system context on windows server whereas http etc run in a user context. The operating system will only allow TSAgent to change source ports for services that run in a user context
thanks for your answer.
just for clarification: There is no way to make TSA map those source ports as the service doesn't run in user context? So it's a problem for Microsoft to solve? It's hard to believe that this issue wasn't noticed before. SMB is a standard and I think many companies are using fileshares...
It's a pitty, but in this case the PAN Firewall would be completely useless for the customer, because removing the user filter from the policy will not be an option!
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!