About drewdown

drewdown · ‎07-20-2020

I know this, what I was asking is why. Either way one my direct reports figured it out and it had to do with PBR and ISP failover. Once he added the VPN-S2S zone and the remote CIDR to that policy traffic started to flow.

drewdown · ‎07-17-2020

More details...I can ping the AZURE instance from the PAN but not from anything behind the PAN on the LAN: admin@fw3-3020(active)> ping source 10.100.2.5 host 10.113.129.4 PING 10.113.129.4 (10.113.129.4) from 10.195.2.5 : 56(84) bytes of data. 64 bytes from 10.113.129.4: icmp_seq=1 ttl=128 time=11.8 ms 64 bytes from 10.113.129.4: icmp_seq=2 ttl=128 time=11.1 ms 64 bytes from 10.113.129.4: icmp_seq=3 ttl=128 time=11.4 ms 64 bytes from 10.113.129.4: icmp_seq=4 ttl=128 time=11.3 ms

drewdown · ‎07-17-2020

So it looks to be matching the right policy from CLI but the GUI shows the wrong one when filtering by the destination IP within Azure. More importantly its not encrypting any packets towards AZURE and I can't figure that out. admin@fw3-3020(active)> show vpn flow tunnel-id 2 | match bytes encap bytes: 0 decap bytes: 95848 admin@fw3-3020(active)> test security-policy-match source 10.100.1.2 destination 10.113.129.4 protocol 80 "Allow-Azure-Ok; index: 2" { from trust; source 10.100.0.0/16; source-region none; to VPN-S2S; destination 10.113.128.0/20; destination-region none; user any; category any; application/service 0:any/any/any/app-default; action allow; icmp-unreachable: no terminal yes; }

drewdown · ‎07-17-2020

Recent new VPN tunnel is up with Azure. I can see traffic matching zone VPN-S2S > trust but anything from trust > VPN-S2S zone is not matching that specific policy. The oubound traffic is matching the blanket outbound policy and I can't figure out why. Can someone help me figure out what the deal is?

drewdown · ‎05-18-2020

I have zone protection but only on the untrust side but thinking now I need to do it on the trust as well.

drewdown · ‎05-16-2020

I lied ACC told me exactly what was causing it I was just too dumb to enact the right policy to drop that traffic. Two offending hosts sending a ton of sessions outbound bringing the FW to a crawl. Once I got the right policy to deny all traffic from the offending hosts everything returned to normal. Do PAs have something similar to ASA threat detection where it will shun/deny all traffic from a host if it sees x amount of traffic or sessions?

drewdown · ‎05-16-2020

ACC isn't really telling me all that much except for a couple of end hosts with a fair amount of sessions so I blocked those but still doesn't seem to have helped whatsoever. I tried restarting the data plane as well to no avail. Can someone help me figure out what is going on here? Resource monitoring sampling data (per second): CPU load sampling by group: flow_lookup : 100% flow_fastpath : 84% flow_slowpath : 100% flow_forwarding : 100% flow_mgmt : 20% flow_ctrl : 20% nac_result : 100% flow_np : 84% dfa_result : 100% module_internal : 100% aho_result : 100% zip_result : 100% pktlog_forwarding : 100% lwm : 0% flow_host : 80% CPU load (%) during last 60 seconds: core 0 1 2 3 4 5 * 20 100 100 100 100 * 19 100 100 100 100 * 20 100 100 100 100 * 22 100 100 100 100 * 22 100 100 100 100 * 22 100 100 100 100 * 19 100 100 100 100 * 18 81 80 80 81 * 19 91 91 91 92 * 18 99 99 99 99 * 17 100 100 100 100 * 17 100 100 100 100 * 19 100 100 100 100 * 22 100 100 100 100 * 22 100 100 100 100 * 22 100 100 100 100 * 24 100 100 100 100 * 22 98 98 98 98 * 17 88 88 88 88 * 15 88 87 87 88 * 14 84 84 84 84 * 14 81 81 82 82 * 12 65 65 66 66 * 14 77 77 77 77 * 18 92 92 92 92 * 19 87 87 87 87 * 18 88 88 88 88 * 18 98 98 98 98 * 17 100 100 100 100 * 17 100 100 100 100 * 18 100 100 100 100 * 19 100 100 100 100 * 19 100 100 100 100 * 21 100 100 100 100 * 22 100 100 100 100 * 23 100 100 100 100 * 21 100 100 100 100 * 19 99 99 99 99 * 12 58 58 58 58 * 19 88 88 88 88 * 26 100 100 100 100 * 24 100 100 100 100 * 22 100 100 100 100 * 21 100 100 100 100 * 19 100 100 100 100 * 17 100 100 100 100 * 15 100 100 100 100 * 15 100 100 100 100 * 15 100 100 100 100 * 16 98 98 98 98 * 16 94 94 94 94 * 15 84 84 84 84 * 13 71 71 71 71 * 15 75 75 75 75 * 12 68 69 69 69 * 17 81 81 81 81 * 23 97 97 97 97 * 25 100 100 100 100 * 26 100 100 100 100 * 24 100 100 100 100 Resource utilization (%) during last 60 seconds: session: 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 packet buffer: 81 91 91 91 85 70 47 18 36 79 93 93 93 63 46 36 26 10 5 3 3 2 2 2 2 4 3 73 93 93 93 91 91 90 90 74 59 35 8 58 86 90 90 89 90 89 90 93 93 67 20 3 2 2 2 2 30 70 82 87 packet descriptor: 20 23 23 23 21 18 12 5 1 18 23 24 24 16 12 9 7 3 2 1 1 1 1 1 1 1 1 19 24 24 24 23 23 23 23 19 15 9 2 15 22 23 23 23 23 23 23 23 24 17 5 1 1 1 1 1 8 18 21 22 packet descriptor (on-chip): 79 88 88 88 88 88 88 88 21 69 88 88 88 88 88 88 88 80 73 35 24 7 20 7 13 72 28 71 88 88 88 88 88 88 88 88 88 88 21 69 78 85 88 88 88 88 88 88 88 88 38 7 15 6 4 3 69 88 88 55 Resource monitoring sampling data (per minute): CPU load (%) during last 60 minutes: core 0 1 2 3 4 5 avg max avg max avg max avg max avg max avg max * * 19 30 95 100 95 100 95 100 95 100 * * 18 27 94 100 94 100 94 100 94 100 * * 19 25 97 100 97 100 97 100 97 100 * * 18 25 94 100 95 100 94 100 95 100 * * 18 25 93 100 93 100 93 100 93 100 * * 17 24 91 100 91 100 91 100 91 100 * * 19 31 94 100 94 100 94 100 94 100 * * 18 27 92 100 92 100 92 100 92 100 * * 18 24 94 100 94 100 94 100 94 100 * * 19 27 95 100 95 100 95 100 95 100 * * 18 26 95 100 95 100 95 100 95 100 * * 18 24 93 100 93 100 93 100 93 100 * * 19 29 94 100 94 100 94 100 94 100 * * 19 34 95 100 94 100 95 100 95 100 * * 18 31 93 100 93 100 93 100 93 100 * * 19 28 92 100 92 100 92 100 92 100 * * 19 28 94 100 94 100 94 100 94 100 * * 19 34 96 100 96 100 96 100 96 100 * * 18 25 90 100 90 100 90 100 91 100 * * 18 25 92 100 92 100 92 100 92 100 * * 17 24 85 100 85 100 85 100 85 100 * * 18 30 92 100 92 100 92 100 92 100 * * 19 35 89 100 89 100 89 100 89 100 * * 18 24 90 100 90 100 90 100 91 100 * * 18 23 92 100 92 100 92 100 92 100 * * 19 35 93 100 93 100 93 100 93 100 * * 21 41 87 100 87 100 87 100 87 100 * * 27 61 88 100 88 100 88 100 89 100 * * 32 54 87 100 87 100 88 100 88 100 * * 22 92 64 100 64 100 64 100 64 100 * * 2 9 1 9 1 9 1 9 1 9 * * 2 9 1 9 1 9 1 9 1 9 * * 2 9 1 11 1 11 1 11 1 11 * * 2 9 1 9 1 9 1 9 1 9 * * 2 9 1 9 1 10 1 9 1 9 * * 2 8 1 8 1 8 1 8 1 8 * * 2 9 1 9 1 10 1 9 1 10 * * 2 8 1 8 1 8 1 8 1 8 * * 2 8 1 8 1 8 1 8 1 8 * * 2 8 1 9 1 9 1 9 1 9 * * 2 10 1 11 1 11 1 11 1 11 * * 2 8 1 8 1 8 1 8 1 8 * * 2 11 1 11 1 12 1 11 1 12 * * 2 12 2 12 2 12 2 12 2 12 * * 2 9 2 10 2 10 2 10 2 10 * * 2 9 1 10 1 10 1 10 1 10 * * 2 9 2 10 2 10 2 10 2 10 * * 2 11 2 12 2 12 2 11 2 12 * * 2 11 2 12 2 12 2 12 2 12 * * 6 24 6 25 6 24 6 25 6 24 * * 2 9 1 9 1 9 1 9 1 9 * * 2 11 2 13 2 13 2 13 2 13 * * 2 9 2 10 2 10 2 10 2 10 * * 2 10 2 10 2 10 2 10 2 10 * * 2 10 2 10 2 10 2 10 2 10 * * 3 21 3 21 3 21 3 21 3 21 * * 2 10 2 10 2 10 2 10 2 10 * * 2 10 2 9 2 9 2 9 2 9 * * 2 9 2 9 2 9 2 9 2 9 * * 18 26 94 100 94 100 94 100 94 100 Resource utilization (%) during last 60 minutes: session (average): 52 53 53 53 53 53 53 53 53 54 55 56 56 58 58 59 60 61 69 70 71 71 70 64 65 69 72 72 73 60 54 54 54 55 56 59 59 60 62 63 63 63 64 66 68 70 70 70 70 72 65 67 70 71 71 66 47 48 48 52 session (maximum): 53 53 53 53 53 53 53 53 53 55 56 56 58 58 59 60 60 69 69 71 71 71 73 65 65 72 73 75 75 75 54 54 54 56 59 59 59 61 63 63 63 63 66 67 70 70 70 70 72 80 65 68 71 71 72 72 49 49 49 52 packet buffer (average): 52 56 62 57 59 47 55 50 57 52 48 60 52 68 47 58 60 62 54 59 51 60 52 58 55 54 51 48 45 30 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 55 packet buffer (maximum): 93 94 93 93 93 93 93 93 93 93 93 93 93 93 93 93 93 93 93 93 93 93 93 93 93 93 93 93 94 93 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 93 packet descriptor (average): 13 14 16 14 15 12 14 13 14 13 12 15 13 17 12 15 15 16 14 15 13 15 13 14 14 14 13 12 11 8 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 14 packet descriptor (maximum): 24 23 23 23 23 23 23 23 23 24 23 23 24 23 23 24 23 23 23 23 23 24 24 24 24 24 24 24 24 23 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 24 packet descriptor (on-chip) (average): 65 67 69 68 65 56 65 59 58 63 64 61 66 72 64 68 70 70 64 69 58 72 65 67 63 68 68 61 61 48 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 67 packet descriptor (on-chip) (maximum): 88 88 88 88 88 88 88 88 88 88 88 88 88 88 88 88 88 88 88 88 88 88 88 88 88 88 88 88 88 88 2 2 2 4 2 2 2 2 2 2 2 2 2 2 2 2 5 2 2 19 2 2 2 2 2 2 2 2 2 88 Resource monitoring sampling data (per hour): CPU load (%) during last 24 hours: core 0 1 2 3 4 5 avg max avg max avg max avg max avg max avg max * * 2 92 3 100 3 100 3 100 3 100 * * 2 22 2 22 2 22 2 22 2 22 * * 2 12 2 12 2 12 2 12 2 12 * * 2 14 2 14 2 14 2 14 2 14 * * 2 13 2 13 2 13 2 13 2 13 * * 2 14 2 14 2 14 2 14 2 14 * * 2 18 2 18 2 18 2 18 2 18 * * 2 29 1 30 1 30 1 30 1 30 * * 2 31 1 31 1 31 1 31 1 31 * * 2 26 1 26 1 26 1 26 1 26 * * 1 1 0 1 0 1 0 1 0 1 * * 1 1 0 1 0 1 0 1 0 1 * * 1 1 0 1 0 1 0 1 0 1 * * 1 1 0 1 0 1 0 1 0 1 * * 1 1 0 1 0 1 0 1 0 1 * * 1 1 0 1 0 1 0 1 0 1 * * 1 1 0 1 0 1 0 1 0 1 * * 1 1 0 1 0 1 0 1 0 1 * * 1 1 0 1 0 1 0 1 0 1 * * 1 1 0 1 0 1 0 1 0 1 * * 1 1 0 1 0 1 0 1 0 1 * * 1 1 0 1 0 1 0 1 0 1 * * 1 1 0 1 0 1 0 1 0 1 * * 1 1 0 1 0 1 0 1 0 1 Resource utilization (%) during last 24 hours: session (average): 55 47 48 48 48 47 47 27 39 36 4 4 4 4 4 4 4 4 4 4 4 4 4 4 session (maximum): 80 49 49 49 49 49 49 49 49 49 5 5 5 5 5 5 7 6 5 5 5 5 5 5 packet buffer (average): 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 packet buffer (maximum): 93 0 0 0 0 0 0 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 packet descriptor (average): 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 packet descriptor (maximum): 23 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 packet descriptor (on-chip) (average): 3 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 packet descriptor (on-chip) (maximum): 88 2 2 2 2 2 2 56 3 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 Resource monitoring sampling data (per day): CPU load (%) during last 7 days: core 0 1 2 3 4 5 avg max avg max avg max avg max avg max avg max * * 1 92 1 100 1 100 1 100 1 100 * * 1 3 0 3 0 3 0 3 0 3 * * 2 26 2 25 2 25 2 25 2 25 * * 1 34 1 35 1 34 1 35 1 34 * * 2 38 2 39 2 39 2 38 2 39 * * 1 5 0 5 0 5 0 5 0 5 * * 1 5 0 5 0 5 0 5 0 5 Resource utilization (%) during last 7 days: session (average): 21 4 38 12 20 4 4 session (maximum): 80 6 50 79 100 47 46 packet buffer (average): 0 0 0 0 0 0 0 packet buffer (maximum): 93 0 0 0 2 0 0 packet descriptor (average): 0 0 0 0 0 0 0 packet descriptor (maximum): 23 0 0 0 0 0 0 packet descriptor (on-chip) (average): 2 2 2 2 2 2 2 packet descriptor (on-chip) (maximum): 88 2 13 2 55 2 2 Resource monitoring sampling data (per week): CPU load (%) during last 13 weeks: core 0 1 2 3 4 5 avg max avg max avg max avg max avg max avg max * * 2 38 1 39 1 39 1 38 1 39 * * 3 21 2 11 2 13 2 13 2 14 * * 3 4 2 4 2 4 2 4 2 4 * * 3 12 2 12 2 12 2 12 2 12 * * 3 5 2 5 2 5 2 5 2 5 * * 3 4 2 5 2 5 2 5 2 5 * * 3 6 2 7 2 7 2 7 2 7 * * 3 26 2 26 2 26 2 26 2 26 * * 2 81 2 100 2 100 2 100 2 100 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Resource utilization (%) during last 13 weeks: session (average): 16 26 26 28 28 27 27 27 25 0 0 0 0 session (maximum): 100 49 31 49 40 36 47 47 100 0 0 0 0 packet buffer (average): 0 0 0 0 0 0 0 0 0 0 0 0 0 packet buffer (maximum): 2 0 0 0 0 0 0 4 94 0 0 0 0 packet descriptor (average): 0 0 0 0 0 0 0 0 0 0 0 0 0 packet descriptor (maximum): 0 0 0 0 0 0 0 1 25 0 0 0 0 packet descriptor (on-chip) (average): 2 2 2 2 2 2 2 2 2 0 0 0 0 packet descriptor (on-chip) (maximum): 55 2 2 2 2 2 2 56 88 0 0 0 0

drewdown · ‎05-08-2020

IIRC at first I think they had us downgrade and re-upgrade but in the end we had to RMA the panorama box and that turned into a entire different mess. I would hope no one has to go through that because it seemed PA had no idea how to do it without causing interruptions.

drewdown · ‎02-04-2020

Thanks that worked. How do I get a FEED BASE URL configured for this? The goal there is to reference the list of github IPs via an EDL.

drewdown · ‎02-04-2020

Did you manually add that or import it? If manually can you copy/paste the syntax used to create it? I tried to create a new miner using those same settings but it won't let me save it and I am not sure why. IE the OK box has a red circle with a line through it so I am doing something wrong.

drewdown · ‎02-03-2020

Thanks man, will configure and let you know how it goes.

drewdown · ‎01-29-2020

Still fighting this issue. I tried your self signed cert as well from github and now I get a different error message when attempting to authenticate to minemeld using that cert profile: description contains 'EDL server certificate authentication failed....Reason: SSL peer certificate or SSH remote key was not OK' Update: So I changed the URL to include the server name instead of the IP address of minemeld and that seems to have fixed it. I can see the IPs and URLs now and all is well again. So: https://minemeld.mydomain.com/feeds/o365-any-any-ipv4-feed vs https://10.10.10.1/feeds/o365-any-any-ipv4-feed First one works, second does not after generating the self signed cert on minemeld itself.

drewdown · ‎01-28-2020

More digging shows this in the logs although not sure if its relevant because I still can't get the list to populate: description contains 'EDL server certificate authentication failed. The associated external dynamic list has been removed, which might impact your policy. EDL Name: o365-IPv4-01, EDL Source URL: https://youriphere/feeds/o365-any-any-ipv4-feed, CN: please use a real certificate, Reason: unable to get local issuer certificate ( description contains 'EDL(o365-IPv4-01) No changes to authentication status, still failing. ' ) The cert I used was the godaddy one from the mine meld install walk through that you wrote @lmori : https://live.paloaltonetworks.com/t5/MineMeld-Articles/Connecting-PAN-OS-to-MineMeld-using-External-Dynamic-Lists/ta-p/190414

drewdown · ‎01-28-2020

As you can see the list is empty on the device but if I go to that URL it shows all the O365 IPs. I am also referencing it on a security policy but it still won't populate. I am using Panorama to do this if that matters, youandme@fw3060-678876(active)> request system external-list show type ip name o365-IPv4 o365-IPv4 o365-IPv4-01 o365-IPv4-01 o365-IPv6 o365-IPv6 <name> <name> admin@fw1-3060-qts(active)> request system external-list show type ip name o365-IPv4-01 Server error : external dynamic list file either empty or not found https://youriphere/feeds/o365-any-any-ipv4-feed 101.28.252.0-101.28.252.255 103.9.8.0-103.9.11.255 112.25.33.0-112.25.33.255 115.231.150.0-115.231.150.255 123.150.49.0-123.150.49.255 123.235.32.0-123.235.32.255 125.65.247.0-125.65.247.255 139.217.17.219-139.217.17.219 139.217.19.156-139.217.19.156 139.217.21.3-139.217.21.3 139.217.25.244-139.217.25.244 139.219.145.0-139.219.145.31 139.219.146.0-139.219.146.255 139.219.156.0-139.219.159.255 139.219.16.0-139.219.16.31 139.219.17.0-139.219.17.255 139.219.24.0-139.219.27.255 168.63.252.62-168.63.252.62 171.107.84.0-171.107.84.255 171.111.154.0-171.111.154.255 ..............

drewdown · ‎01-28-2020

I want to feed o365 IPv4/URLs into external dynamic lists and reference them in policies using those EDLs as source and or destination objects. I configure the cert profile as well and I when browse to the URL in question I get a list of IPs but for whatever reason it doesn't look like PAN is creating the list correctly. IE its blank. I guess I would want to use the o365-worldwide-any-miner ?

drewdown · ‎01-28-2020

Weird because now that I am looking at this seems my external lists referencing mine meld are blank. So something is amiss. Either I have an older version of feed/nodes or something else entirely. I had set this up awhile ago and just assumed it was running. Some of URL references were simply https://youriphere/feeds/office365_IPv4s , was that used at one time? I went ahead and re-imported the configuration from the how-to and I can see it populating data. But my external mine meld dynamic IP lists are still blank. I tested source URL and it comes back successful but still seem to missing something. Basically I want to allow all O365 IPs on a specific policy via source IP using mind meld. Is this the way I would do that? Specific policy referencing mine meld external dynamic IP list as the source or destination?

drewdown · ‎01-28-2020

Here you go: VERSION: 0.9.52 O365-40.92.0.0-15

drewdown · ‎01-28-2020

Seeing an issue using minemeld and O365 IPs and not having the same IPs that Microsoft is advertising that need to be allowed. Is there any easy way to confirm what is there and and what isn't via minemeld? I've been using for awhile but only now did I notice that some of the CIDRs aren't coming across via minemeld.

drewdown · ‎01-21-2020

Can you share the syntax you used to do this? Thanks

drewdown · ‎01-21-2020

Little confused on how I actually do this. I want a list generated on minemeld from the following page: https://api.github.com/meta How do I go about making it so that list is referenced via a policy to allow github APP to that list of IPs? I am already using minemeld for o365 but that was canned and this isn't. Appreciate any help anyone can provide. Thanks

drewdown · ‎01-21-2020

With dest as any is there a downside to it? Meaning if it is set to ANY is it going to match and allow before it sees github or an IP related to github? No interest in manually entering all of those and I want to lock this down. I do use minemeld for o356 URLs but its been awhile since I did anything with it. Got a link to how I can configure it to pull github IPs? Edit I changed the dest to ANY and its still denying SSH to 'lb-140-82-114-3.iad.github.com' eventhough I have that policy to allow *.github.com. Honestly now that I look at it I don't know whats going on because before I made any changes it appears it was allowed sometimes and not others to same URL/IP over ssh. Anything before 7:11 was locked down to destination, the 7:11 attempt was just using the URL category with destination as ANY. Also it seems I went over this before and URL Category ONLY works http/SSL traffic and not SSH so I have to either allow github to ANY, configure all those IPs or use minemeld. For all the cool features PAN has somethings leave a lot to be desired.

drewdown · ‎01-21-2020

Hi..I want to be able to allow a specific set of apps to *.github.com. To do this would I simply specify a custom URL with *.github.com and destination of ANY? That would then only allow those apps to *.github.com? I ask just because I am wary of having the destination as ANY and not clear on which takes precedence. Currently I have it locked down to destination IPs and FQDN of github.com but that doesn't always work because IPs change and some of the valid traffic gets denied.

drewdown · ‎11-25-2019

Yeah pretty much. I think this thread has run its course, thanks everyone for the insight.

drewdown · ‎11-25-2019

Again I get all that and I don't expect it to be perfect but when I want to allow CURL and to do-so I need to allow google-base that can be confusing to me and I am sure others. Granted PA does make it easy to see what its doing and allow the appropriate app-id.

drewdown · ‎11-19-2019

I get the whole concept and I am using app-ids on the permit statement and denying everything else across this environment so its not that. What I didn't get is that if I did that and didn't allow whatever traffic pattern was being matched it would be dropped. I assumed, albeit incorrectly, that if I allowed 80/443 and curl uses 80/443 and there is no 'curl' app-id it would be allowed.

drewdown · ‎11-18-2019

I wish I could remember what our PA rep told me about actual application-id adoption rate, but it was something paltry at best across the board. Either way I know how to configure them and I think you missed the point of my argument. Which was why is curl being classified as google-base? I was also simply asking how to allow 80/443 and NOT classify the traffic at the same time. Whether I do that or not is really up to me.

drewdown · ‎11-18-2019

Yeah that is pretty much it. I understand it now but I guess I was just assuming if I allowed 80/443 via 'web-browsing' then it would allow all 80/443 and not try and match the traffic to a specific application-id. Having only recently gone to 8.1 and this being a new deployment using the same thought process as the previous ones it was odd to me that it broke a fair amount of connectivity based on not allowing whatever APP the PAN was classifying it as. For instance users were trying to curl www.google.com and the PAN was classifying that as 'google-base' but I would never equate curl to google-base (no curl app-id) so I would have never allowed it. Its only when I looked at the logs I saw what it was doing and once I allowed google-base the curl commands worked. Anyways if I wanted to allow outbound 80/443 and not match any application how would I do that?

drewdown · ‎11-18-2019

I use both but running into an issue with Lab specific traffic where I will allow a list of applications with service set to ANY but the PAN classifies some 443 traffic as (for example) 'windows push notification' or 'soap' but I am not allowing either of those APPs so it drops it. I am allowing web-browsing and windows push/soap both use tcp/443 so it seems to be classifying 443 traffic as any application that may or may not use tcp/443. How do I get around having to allow every application that may or may not use 80/443 or any other ports for that matter? I tried setting it to application-default but it still seems to be happening. Not doing any SSL decryption. What is odd is this seems to be a new problem for me since going to 8.1 from 8.0 for the longest time. Not sure I have run into this before and presently managed roughly 10 HA pairs of PANs across our environment.

drewdown · ‎09-24-2019

@MichaelShelton I changed the zone names on the FW to all lowercase and committed it but when I did that the tunnel between that FW and our on-prem FW went down. I had to bounce the tunnel to get it passing traffic again....odd but whatever. As far as the logging goes I am not logging anything to Panorama on the FW. Those 'Test-Alerts' are configured on the Panorama and pushed to my other managed PANs. On the FW I am trying to import logging is only set to 'Log at Session End' and Forwarding set to 'none' on every policy. Are you are saying to disable the log settings on the 2 shared POST security policies on the PANORAMA? This stuff is so cryptic, sometimes I love PAN and other times I want to beat it like a red headed stepchild.

drewdown · ‎09-24-2019

We have a handful of standalone PAs that we want to import into Panorama. However in our first interation it failed with the following errors and I am not sure why. The entire process isn't made clear to me either via PA (like a lot of their stuff but I digress) so I was wondering if anyone has done this and can help point me in the right direction? Commit/validation fails on the following items on the firewall after import/export back to it from the Panorama: Validation Error: log-settings -> profiles -> Forward to Panorama and Email -> match-list -> test-Alerts -> send-email 'Test Alerts' is not a valid reference log-settings -> profiles -> Forward to Panorama and Email -> match-list -> test-Alerts -> send-email is invalid log-settings -> profiles -> Forward to Panorama and Email -> match-list is invalid log-settings -> profiles is invalid log-settings is invalid shared is invalid rulebase -> security -> rules -> outbound-block-all -> from 'trust' is not an allowed keyword rulebase -> security -> rules -> outbound-block-all -> from 'trust' is not a valid reference rulebase -> security -> rules -> outbound-block-all -> from is invalid rulebase -> security -> rules -> outbound-block-all -> to 'untrust' is not an allowed keyword rulebase -> security -> rules -> outbound-block-all -> to 'untrust' is not a valid reference rulebase -> security -> rules -> outbound-block-all -> to is invalid rulebase -> security -> rules -> untrust-block-all -> from 'untrust' is not an allowed keyword rulebase -> security -> rules -> untrust-block-all -> from 'untrust' is not a valid reference rulebase -> security -> rules -> untrust-block-all -> from is invalid rulebase -> security -> rules is invalid rulebase -> security is invalid rulebase is invalid vsys is invalid devices is invalid In VSYS vsys1 from zone trust of type unknown and to zone untrust of type unknown are incompatible in security rule outbound-block-all Configuration is invalid 2 errors when trying to do this, both of which appear to be originating from the PAN > FW. The first one is a log setting on the 'outbound-block-all' rule on the PAN. That specific log settings doesn't exist on the FW. Again same rule that is already on the PAN in 'Post Rules,' its shared between all of our existing DGs on the PAN. The only difference between the zones on the FW and the PAN is the first letter is capitalized which I assume is why it chokes? I changed the zone names to match on the FW but not sure what to do about the log/email settings? Also not sure why its complaining about 'shared' as well.

Date Registered	‎08-20-2015 10:23 AM
Date Last Visited	‎08-19-2020 11:26 PM
Total Messages Posted	106
Total Likes Received	11

Online Status	Offline
Date Last Visited	‎08-19-2020 11:26 PM

Strata

Prisma

Cortex

About drewdown