Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
- Get Started
- News & Events
- Collaboration
- Education Services
- Technologies
- Next-Generation Firewall
- GlobalProtect
- Threat Prevention Services
- Endpoint Protection
- SSL Decryption
- 5G
- IoT Security
- Prisma SD-WAN
Network Security
- Prisma Access
- Prisma SaaS
- Prisma Cloud
- CN-Series
- VM-Series:
- Alibaba
- AWS
- GCP
- Azure
Cloud Security
- Cortex XDR
- Cortex XSOAR
- Cortex Data Lake
Security Operations
- Resources
- COVID-19 Response Center
- LIVEcommunity
- ›
- About El-ahrairah
About El-ahrairah
Announcements
Changes to the LIVEcommunity experience are coming soon... Here's what you need to know.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
4 weeks ago
33Posts
3Likes
4Solutions
Mar 16, 2021Last Visited
User
Activity
User
Profile
Latest posts by El-ahrairah
| Subject | Views | Posted |
|---|---|---|
| 2156 | 05-01-2019 05:30 PM | |
| 1240 | 05-01-2019 05:27 PM | |
| 1868 | 04-29-2019 04:02 PM | |
| 1637 | 04-22-2019 06:30 PM | |
| 1648 | 04-22-2019 05:26 PM |
My Liked Posts
| Subject | Likes | Posted |
|---|---|---|
| 1 | 04-22-2019 06:30 PM | |
| 1 | 04-17-2019 08:09 PM | |
| 1 | 04-16-2019 10:28 PM |
Posts I Liked
| Subject | Likes | Author | Latest Post |
|---|---|---|---|
| 1 | |||
| 2 |
User Badges
Public Statistics
| Date Registered | 03-14-2017 07:58 PM |
| Date Last Visited | 4 weeks ago |
| Total Messages Posted | 35 |
| Total Likes Received | 3 |
05-01-2019
05:30 PM
I've arranged an FR for an issue I raised in a post here a few weeks back to allow for Static route path monitoring to be done using the FIB as opposed to being locked to the gateway of the route itself. 11524 This is my OP which outlines the issue which this resolves. https://live.paloaltonetworks.com/t5/General-Topics/Route-Monitoring-Possible-FR/m-p/257932#M73180
... View more
04-29-2019
04:02 PM
Need a bit more detail here. But it sounds like you need a redistribution profile. I'm assuming b.b.b.b/27 is going to be used for NAT on your public facing zone? If b.b.b.b/27 is connected or learned via another routing protocol (eg static, ospf), you can configure a Redistribution profile to advertise them to your eBGP public peer. If b.b.b.b/27 does not exist, then you can manually redistribute it without tieing it to any other interface or routing protocol. This just means your firewall with redistribute it not matter what. Secondly you need to make sure the route filters are in place on your end to allow the redistribution and on the peers end to allow for the learning and further distribution of the b.b.b.b/27 network.
... View more
04-22-2019
06:30 PM
1 Kudo
Its shows the log collector preference defined IN Panorama yes. AFAIK there is no way to locally override this setting. It's impossible to have a setting here without Panorama. So there isnt a question of this configuration coming from anywhere else other than the Panorama server configured on the firewall.
... View more
04-22-2019
05:26 PM
It should take effect after a Panorama & Managed Collector commit. A push to the firewalls is not neccessary (I believe). I'm not fully clear on what you're trying to confirm exactly. The command in my OP when run on the firewall will show the LC preference its has gotten from Panorama after the aforementioned commit.
... View more
04-22-2019
05:09 PM
I think i kind of answered that in my post. The information is shared when a commit to Panorama is performed. In terms of the means on transport, I assume its via the Panorama communication channel over TCP 3978.
... View more
04-21-2019
05:49 AM
I tried this one as well. Even some uglier permutations using NAT. Neither produced results unforatunety. The first one runs into problems with route asymmetry I think when the return packet comes from R2, but I didnt go so far as to confirm this.
... View more
04-19-2019
03:54 AM
I did also try this. There is a validation error upon closing our the VR configuration. Path Monitoring requires interface specified vr_local -> routing-table -> ip -> static-route -> asdasd -> path-monitor is invalid
... View more
04-18-2019
04:11 PM
Hi @vsys_remo Yes. But the current function of the path monitor means that if I do that it tries to monitor 2.2.2.2 via 1.1.1.2 gateway configured in the static route in question, which instantly fails. This is confirmed if you A - check the status directly after a commit and B - performing a tx PCAP reveals ICMP requests going out of eth1/1. On the other hand.... ping source 1.1.1.1 host 2.2.2.2 ...works perfectly fine. But this is not the same, as a ping will use the FIB for determining the path. Whereas a path monitor ignores the FIB and uses the gateway defined in the static route no matter what you try to monitor.
... View more
04-17-2019
09:33 PM
Hi I ran into an interesting requirement which (I believe) is not possible with the current path monitoring features for static routes. Here is my scenario... First lets just remove dynamic routing from the equation. For this specific use case dyanamic routing isnt possible between R1, R2 and the PA. PA has a default route configured to R1. R1 is routing the 3.3.3.0/24 network to the PA, which is a network segment on a seperate DMZ. Hosts in this DMZ have a have depdance on resources beyond R2 however. At first a path monitoring is configured on the next hop for the gateway (green). However this would only trigger if the link between R1 and the PA fails. Since the hosts in 3.3.3.0/24 have large dependancies on hosts beyond R2, we'd also like to tear down the default route to R1 if the connection to R2 fails (orange). Since path monitoring in its current guise only montiors a path via the gateway configured in the static route itself, this isnt possible (AFAIK). This means that even if the R2 link went down, hosts in 3.3.3.0/24 would still respond to requests from hosts beyond R1. In this use case we do not want this to occur. Hence it would be advantageous in this scenario to be able to monitor a route in the FIB as a metric for tearing down a static route. Since if we could tear down the default route to R1 by monitoring R2, hosts beyond R1 would not get responses when querying hosts in 3.3.3.0/24. I know this kind of function exists on dedicated router products (eg. Cisco). Am I missing something? Or is this in fact not possible? Cheers EDIT: Just thought I'd add. I'm pretty sure this scenario could be solved by introducing seperate virtual routers. But I'm trying to avoid this level of complexity in this case.
... View more
- Tags:
- route monitoring
04-17-2019
08:14 PM
Keep in mind 8.0.x goes end of life this year. October I believe. 8.1.7 is the current "stable" version according to eTac recommendation.
... View more
04-17-2019
08:09 PM
1 Kudo
Multi edit is a function people have been begging for since version 4! Ironically the function has existed for ages in the Migration Tool and now Expedition. Expedition is relatively easy to spin up. You can then connect your firewall to it to import the policy and perform your multi edits here. Then Expedition can push the policy back to the firewall via API. Other than this, you're only options are ones already mentioned... - Mass CLI commands probably written up in a spreadsheet - Output the XML and manually edit it (highly suseptible to corruption) - API automation (Basically what Expedition does for you). EDIT: Forgot to include the link! https://live.paloaltonetworks.com/t5/Expedition-Migration-Tool/ct-p/migration_tool
... View more
04-17-2019
03:22 PM
I was afraid this might be the only option :'( Thanks
... View more
04-16-2019
11:15 PM
GOOGLE TRANSLATE Look at the reference site, how to extend the log area of Panorama (ESX 6.5 VM) by 120GB I tried a few things, but I'm troubled not expanding well. In the end, you will not be able to log in. We have already repeated over 10 times deploy → expand → delete. You may not be able to do basic things because you do not have knowledge of Paloalto products. Could you give me some advice? Thank you very much. I'm going to assume you're running Panorama on version >8.0. It sounds like (and this could be bad translation) that you are literally trying to expanding the existing virtual disk allocated to your Panorama VM. This is probably not advisable. You would be much better off creating a new virtual disk with the size you require and adding it to the VM. The article you linked explains how to do this quite clearly. https://docs.paloaltonetworks.com/panorama/8-1/panorama-admin/set-up-panorama/set-up-the-panorama-virtual-appliance/expand-log-storage-capacity-on-the-panorama-virtual-appliance/add-a-virtual-disk-to-panorama-on-an-esxi-server.html# Keep in mind you may need to add more CPU and RAM depending on the amount of disk you add.
... View more
04-16-2019
11:04 PM
First things first. Is your M100 device in Panorama mode? If so, you need to make sure that the default Local Collector is in a different Collector Group to that of the two M500's. Collector Groups must contain devices all of the same SKU. This means if you want to introduce log redundancy for logs already residing on your M100 local collector you might be out of luck. AFAIK there is no method to transfer logs between different Collector Groups (would love to be proven wrong here!). But assuming your M500's are in a distinct collector group and you have configured your devices in preferences lists/'s. This should be shared with the devices as soon as it makes its association to Panorama (Setup > Panorama Servers) and the device is part of the Managed Devices list. It is not part of any Template or Device Config. If your devices are members of the default collector group and you relocate them to another, I believe the information is pushed from Panorama when you commit to Panorama. I dont think this action requires a device push. You can confirm log collector preferences on a managed firewall by running the below command on the firewall itself. show log-collector status Obviously for the logs to be collected you will need to configure log forwarding profiles and logging settings using the usual Panorama setting.
... View more
Contact Me
| Online Status |
Offline
|
| Date Last Visited |
4 weeks ago
|
Latest Blogs
Latest Posts
Copyright 2007 - 2021 - Palo Alto Networks
