Anybody who installed PanOS 8.1 on his Palo Alto firewall – we use the PA 220 in quite some numbers, may have experienced quite some strange behaviour if through IPSEC tunnels connected file shares user SMB. So did I.
With the latest firmware upgrade, no write or read jobs through any of these VPN tunnels succeded. The mapped drives lit up in the file explorer. in some cases even browsing directories may have succeded … perhaps even two or three levels down. Then the explorer started to hang, crashed, even some systems blue screened. Copied files showed perhaps up in the destination with a filename aka. directory entry but never any content showed up.
Since we updated the Microsoft world on top, the assumption some backward compatibility stack or group policy setting may have caused the headache. Many different validation procedures performed in the particular environment pointed in that direction. Nevertheless it had been the firewalls simbly corrupting the SMB- protocoll on traversing traffic. If you told me before, I wouldn’t have believed.
One indicator of the issue being in place is, in the traffic pane of the tab, showing SMB traffic terminated by ressource not available for the majority of SMB communicathion threads.
The good news is, there is a workarround, besides the cumbersome and risk prone procedure of downgrade. Basically it is two steps:
After giving the object a name and the proper categories select the advanced tab. There you add the actual port you want to intercept and make sure you provide the proper protocol with it TCP/445 in this case.
Step 2: where you actually definde an application intercept policy. Since it is a policy you find it under the Policies tab, underneath the more common security or the occasionally used NAT policies. Within Application Override you select the add- button to open the creation wizzard.
Under the General tab you presumably give it a speaking name as “smb_override” in the given case. The next two tabs allow you to define source and destination zones. Since this policy addresses a general error I recommend any / any at this place. The most important part is to define here again the “to be exchanged” port which is again TCP/445.
This should result in an application override policy looking like this: Commit now and the solution should be effective immediately.
So what did we do? We map an override tcp/445 to tcp/445 which results in effctively no change in terms of network communication. But by applying the custom label “smb_override” we removed the application tag, that triggers the bogus trafic traverse.
My understanding goes not beyond that point, but the resolution of the issue was a big stress relief and so far it works great.
P.s.: Thanks to Jojo, pointing for me in the right direction!