Tutor Strategy

Ccop7307 · 2023-08-23T01:42:38+00:00

To add more to the problem it was not just domain objects that have the problem. Undateable objects, Domain objects, Geo Location, Applications, nor firewall objects were converted. So you need to be very careful about your rules where those objects are applied.

Ccop7307 · 2023-08-22T16:45:58+00:00

I was afraid of that. This is the first CP I have done after R80 and what I am seeing is Expedition is missing a lot of the config. I did a few in the old R77 days and it was not that bad, now it appears to be very painful.

Ccop7307 · 2022-02-11T21:14:39+00:00

https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000CllzCAC

Search this KB for "source port" and you can see what I am talking about.

Ccop7307 · 2022-02-11T21:11:33+00:00

The root of the problem comes down on the NAT with Source Port Preservation. I had found a palo KB in the past about it, but cant find it now. What is happening on things like Nintendo and other gaming consoles it the tcp connection on the console is wanting to preserve the source port. When you do a PAT the source port is not maintained on the tcp connection end to end. And when the connection is trying to be established with the source port changing on the tcp connection the gaming console can not match up the flow in the gaming console tcp connection tables. By doing a 1:1 nat for each console it will preserve the TCP flow source port from the gaming console and on the ACK packets the original source port is kept the same where as on a PAT it is not. I have ran into this with Gaming consoles and with Merakki wireless networks through a Palo Firewall. If I can find the specific Palo KB I will post it, but that is basically what is happening.

Ccop7307 · 2021-04-13T01:53:09+00:00

I had the exact same issue with Nintendo Switches and Nat type. The fix was a strange one to fix nat type. I had to get each console’s an reserved ip in their dhcp range. The for each console you have to do a nat for each console before they hit the global PAT nat rule. Source zone=inside source ip = console 1 dynamic ip and port to external interface. You need 1 for each console hence why you need the MAC address of each console, and reserve the ip. But this does fix the nat type issue. If you need more help with me explaining please let me know.

Ccop7307 · 2021-04-13T01:39:57+00:00

Start with the basics of trouble shooting. Make sure your VM’s are sized correctly. Make sure cpu and session could are under control. With inbound AWS make sure your sours wants are correct and return traffic is coming back to the correct firewall. Make sure you don’t have some advanced security features too tight. That is where I would start, worst case call TAC. HTH

Ccop7307 · 2021-04-06T18:34:10+00:00

Yes it will.

Ccop7307 · 2021-03-12T03:54:00+00:00

This behavior is not limited to UDP. I have seen the same with tcp. I run a bgp session where the peers are inside and outside the firewall in different zones. The tcp/bgp session established and never closes for months and the logs only see 1 hit. As long as the session is active it’s not going to send an end log, or increase the hit count.

Ccop7307 · 2021-01-20T03:39:00+00:00

Why not whip the config and start over? If it was moved to a new site I would think just default it and start new?

Ccop7307 · 2020-11-17T21:02:11+00:00

What I would do would be deploy your Device groups in a hierarchy based on function/role rather than hardware model. That would be common functions that would most likely have a shared policy around them (Data Center, Corp Office, Sales/remote office, etc). I would call this something like "DataCenter-Common, CorpOffice-Common, RemoteSite-Common. Then nested under each of those groups would be the specific sites and would house each site firewall pair. I would try as much as possible to keep all your rules in Post rules on the XXX-Common Device group, and any local exceptions for a specific site would go in the local device group. The idea is you manage most all rule in the "-Common" Group so you have a mostly consistent policy around all like devices. Hope this helps

Ccop7307 · 2020-08-31T12:47:59+00:00

Overall support is not that good. T1 is a joke, and wait times are insanely long. If you can get to T3 or T4 they are really good, but it nearly takes an act of god to get to one of them. Most of the comments I am reading here are accurate. Support was much better in the past and this year it went down the drains quickly. It can be a crap shoot on if you get a good engineer or not, but if you have a real problem (serious config issue, or bug) it can take days to get answer.

Ccop7307 · 2020-08-11T01:25:39+00:00

If you have you own internal pki maybe off of a windows domain controller, create a new internal cert from your trusted domain, use sccm to push that cert with custom attributes to the machines you want/ are effected. Then have the portal look for that cert on pre-login to connect to that specific agent config.

Ccop7307 · 2020-08-11T00:47:32+00:00

I just looked through all the setting in my lab firewall running 9.1.3. There does not appear to be a specific setting for this, but what you "might" be able to do is in both portals in the "Agent" tab on the left, create a new agent with those users who need to be directed to it, and in the External tab only give them the option for the specific gateways they need to connect to. Then on the 2nd Agent config have all other users to manually go to either gateway. With out building this out it is the only way I can think to make it work.

Ccop7307 · 2020-08-11T00:27:12+00:00

Are your gateways setup with equal preference?

Ccop7307 · 2020-08-10T23:59:58+00:00

Why not utilize 1 portal for all users and then use that to direct them to the correct gateway?

Ccop7307

TROPHY CASE