PA3020 E1/2-->E1/1 PA500 E1/2-->Internet.
In PA3020, we have configured the service route to paloaltoupdates through e1/2. Then traffic will reach pa500 e1/1 which will be routed to internet via e1/2. PAT configured on e1/2 which will be going to internet.I'm sure route, NAT,security policies are proper.
In PA3020, connection to paloalto update server is established. even anti-virus updates download also started. when we check the show session id xxx. its showing lots of bytes exchanged between C2S and S2C. but at last TCP-reset by client ( send by palo alto firewall ).
we are using staticupdates.paloaltonetworks.com which is working fine in PA500 but not working in PA3020.
Since the PA-3020 deployement, updates are working fine. there is no configuration changes made recently. but suddenly stops working and session end reason is tcp-rst-by-client.
we have created app-override on both firewalls to update server IP. but no luck. Please suggest how can we proceed further.
Are you running SSL decryption on edge firewall? If so having "Verify Update Server Identity" enabled (Device > Setup > Session > Session Settings) will cause the firewall to send a client reset if the update server certificate is not signed by a trusted certificate authority.
I would also capture tcp-rst-by-client in a pcap and verifyi the SSL Session end reason provided by the firewall when connecting to the update server.
Let's do a step back:
Is it software update or dynamic updates?
On the PA3020 when are you trying to check it manually with "check now" button", what can you see in the system logs? l expect the same as per below snip:
How PA500 sees this traffic?
I opened a case with support and after long troubleshooting while checking the ms.log they found one XML file is missing error and they assumed the router doesn't have a route to the internal DNS server. They added a static route and it started to work but my concern is why the DNS is required when I put only the IP address of the updates website not FQDN!
I think its a bug in PA-3020.
Deffenetly better to use FQDN, but in your case do you remember which ip addresses you were using before. Are they the same ip addresses if you trying to resolve an FQDN? If not then you were pointing to the wrong updates server ip address.
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!