This website uses cookies essential to its operation, for analytics, and for personalized content. By continuing to browse this site, you acknowledge the use of cookies.
For details on cookie usage on our site, read our Privacy Policy
For details on cookie usage on our site, read our Privacy Policy
About rmcrae
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- LIVEcommunity
- About rmcrae
08-28-2022
30Posts
2Likes
0Solutions
Aug 28, 2022Last Visited
User
Activity
User
Profile
Latest posts by rmcrae
| Subject | Views | Posted |
|---|---|---|
| 726 | 08-26-2022 10:26 AM | |
| 563 | 08-12-2022 03:17 PM | |
| 640 | 08-11-2022 10:01 AM | |
| 1226 | 05-04-2022 09:00 AM | |
| 1263 | 05-03-2022 08:14 AM |
My Liked Posts
| Subject | Likes | Posted |
|---|---|---|
| 1 Like | 05-03-2022 08:14 AM | |
| 1 Like | 02-04-2022 03:13 PM |
User Badges
Community Statistics
| Member Since | 02-26-2020 09:31 PM |
| Date Last Visited | 08-28-2022 07:19 PM |
| Posts | 30 |
| Total Likes Received | 2 |
08-26-2022
10:26 AM
Is there any workaround? I've tried using a couple EDLs provided by Palo Alto for the Microsoft SharePoint and OneDrive endpoints and one for Microsoft Skype and Teams endpoints but there is too much cross over between the two EDLs so you cant force VOIP traffic to use a specific path via a PBF without also affecting filesharing traffic. As you pointed out the Security Profiles with App-IDs don't work at this point because we are much lower in the OSI model.
... View more
08-12-2022
03:17 PM
This problem still exists. I even checked the PBF with the Test Policy Match and according to the test results it is working as expected but when I run a trace route traffic is still passing from the server to the DA that should not be reachable since that path is down. So I can't explain what is causing this and before I turn up that path I'd like to understand what's happening. I've compared the rules to each other and all of the options are the same. The only differences are the DA, Egress Interface, and Next Hop.
I should also mention that Rule 5 is only a safety net rule. As long as that rule has been in place it has never received any hits under the Hit Counter. I realize that it's not really needed but at the same time it's not hurting anything either.
... View more
08-11-2022
10:01 AM
I have setup several PBFs to force traffic to use a specific egress interface for monitoring that particular path. I then setup a ping monitor on one of the servers, Source Address 192.168.200.15, to ping several different Destination Addresses (DA). The SA is the same for each 'monitor' but the DA is different. The PBF is then setup to forward this traffic based on the source and destination addresses to the interface I want to monitor.
The rules look something like this: Rule1. PBF_Egress-1 SA:192.168.200.15 DA:4.2.2.1 Action:Forward Egress-I/F:Eth1/1 Next Hop:192.168.0.1
Rule2. PBF_Egress-2 SA:192.168.200.15 DA:4.2.2.2 Action:Forward Egress-I/F:Eth1/2 Next Hop:192.168.1.1
Rule3. PBF_Egress-3 SA:192.168.200.15 DA:4.2.2.3 Action:Forward Egress-I/F:Eth1/3 Next Hop:192.168.2.1
Rule4. PBF_Egress-4 SA:192.168.200.15 DA:4.2.2.4 Action:Forward Egress-I/F:Eth1/4 Next Hop:192.168.3.1
Rule5. PBF_Egress-Block SA:192.168.200.15 DA:<all of the above DAs> Action:discard
Rule 5 is in place to make sure that if the traffic gets past those monitor PBF rules 1-4 it is discarded so that it can't use the default routes. I just setup a new rule and the interface is still not active so I would expect that the traffic to not be forwarded because it should still be handled by the new rule, rule 4 or at the very least rule 5, but even though the route is not yet valid but it seems to be making it past all of these rules to the default route rule and getting forwarded. When I verify the traffic via Trace Route from the above SA to 4.2.2.4 I can see that the new traffic is bouncing around the other interfaces and that tells me it's making it to the default routing rules that are a load balanced SD-WAN interface. Those default routing rules are much lower in the stack.
Anyone have any ideas why this is happening and how to make sure the PBF rules are honored?
... View more
05-04-2022
09:00 AM
I think it depends on what country your Excel thinks it in but the semicolon in your formula needs to be a comma. Also you have cell A52 in your formula, not A1. Here is a little fix...: =HEX2DEC(MID(SUBSTITUTE(A1,":",""),7,2)) & "." & HEX2DEC(MID(SUBSTITUTE(A1,":",""),5,2)) & "." & HEX2DEC(MID(SUBSTITUTE(A1,":",""),3,2)) & "." & HEX2DEC(MID(SUBSTITUTE(A1,":",""),1,2)) Also, I'm not sure how this Excel formula is going to handle a single digit Octet that isn't padded with a leading zero.
... View more
05-03-2022
08:14 AM
1 Kudo
It was working correctly for me for a very short time after updating to 10.2.0 on my PA220 but reverted to the hex encoded addresses. I was hoping that 10.2.1 actually fixed it but it doesn't, not even for the "Last Hour" as suggested above. As @laurence64 suggested above I think it's time we all open TAC cases for this to put a little pressure on them to fix it. PA is obviously not reading these threads any more.
... View more
LEGAL NOTICES
Copyright 2007 - 2023 - Palo Alto Networks