About El-ahrairah

El-ahrairah · ‎05-01-2019

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

El-ahrairah · ‎05-01-2019

I've managed to get a feature request raised for this. 11524

El-ahrairah · ‎04-29-2019

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.

El-ahrairah · ‎04-22-2019

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.

El-ahrairah · ‎04-22-2019

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.

El-ahrairah · ‎04-22-2019

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.

El-ahrairah · ‎04-21-2019

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.

El-ahrairah · ‎04-19-2019

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

El-ahrairah · ‎04-18-2019

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.

El-ahrairah · ‎04-17-2019

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.

El-ahrairah · ‎04-17-2019

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.

El-ahrairah · ‎04-17-2019

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

El-ahrairah · ‎04-17-2019

I was afraid this might be the only option :'( Thanks

El-ahrairah · ‎04-16-2019

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.

El-ahrairah · ‎04-16-2019

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.

El-ahrairah · ‎04-16-2019

Not really no. Generally speaking it would be best practice to use a totally unrelated domain for the company/organization the remote access is for. For example, it wouldnt be advisable for CompanyA to use... eg "remoteaccess.companya.com" Something generic that could not be traced back to the CompanyA in question would be much more advisable. Also the use of a top level domain that doesnt require it to be registered to a legitimate organisation if you want to be really paranoid.... eg. "tasty.spacechicken.systems" Obviously something more appropriate than that, but you get the idea 🙂

El-ahrairah · ‎04-16-2019

Technically speaking this would work, but it would exceedingly pointless since you are only using two IP addresses. A /30 mask would be much more appropraite.

El-ahrairah · ‎04-16-2019

Hi, I'm looking for a way to re-order BGP Import/Export filters via the CLI or via the API (preferrably CLI). I have not been able to find a set, move or edit command which does this and searching the API browser there doesnt seem to be a path that would be able to alter order of these rules. Is this even possible? Cheers

El-ahrairah · ‎03-26-2018

Hi, I'm wondering what effect, if any, does the default wildfire analysis profile have when you do not have the wildfire license applied to your firewall? Thanks

El-ahrairah · ‎03-05-2018

No worries

El-ahrairah · ‎03-05-2018

It seems in version 7.1.15 of Panorama there are two "Green" tags that are different colour. But it seems you are only able to select one. If you attempt to select the Green at the bottom of the drop down list, it instantly reverts to the darker green near the top of the list.

El-ahrairah · ‎08-08-2017

Just for fun I installed Docker on a laptop running Windows Server 2016 and was able to build MineMeld with run command. Seems to work fine. docker run -it -p 8443:443 jtschichold/minemeld As mentioned prior... AFAIK Docker wont run on a Windows VM since it relies on Hyper-V Hypervisor, which generally doesnt wort when running on other hypervisors (ESX etc.). I have only tested on VMWare hypervisors so far and Docker installation fails. Might test on AWS and Azure later, but I dont expect any different results.

El-ahrairah · ‎08-08-2017

Yes I have run it in Ubuntu and CentOS but for various non-technical reasons I have had it requested to run on Windows. But that has now been ruled out 🙂

El-ahrairah · ‎08-07-2017

Thanks @lmori As I turns out Docker doesnt function on Windows guests running on ESXi hypervisor due to Hyper-V incompatiblity on such a scenario. I'll endevour to test it in my free time on a thick client, but insuitable for my current use case.

El-ahrairah · ‎07-30-2017

Is there a process to install MineMeld on a Windows isntance of Docker (much like the CentOS/RHEL deployments)? Cheers

El-ahrairah · ‎07-30-2017

What is the current standing of the MineMeld CentOS docker deployment model? The latest post I have seen from @lmori (29/11/2016) is that it is "quite stable now and supported". Could we get an update on PA's current stance on this deployment model? Is it production viable? Cheers

El-ahrairah · ‎07-02-2017

Should be updated to note that the htpasswd file is now located in.... "/opt/minemeld/local/config/api" not " /opt/minemeld/local/config/"

El-ahrairah · ‎06-25-2017

Perfect. Thanks for the response.

El-ahrairah · ‎06-15-2017

AFAIK there is no way to convert them perse. You can however clone objects and put the clone into either the Shared or specific Device Group. You would then need to then go and reassociate the new objects all throughout your policy which would be a pretty laborious process.

El-ahrairah · ‎06-15-2017

Hi, I'm curious to know if it is possible to configure an AE Group of interfaces in a PA 7000 series appliances with interfaces accross multiple NPC's? This just seems to me to be the most logical way to load share on the platform with multiple NPC's, assuming its supported. Thanks

Date Registered	‎03-14-2017 07:58 PM
Date Last Visited	Wednesday
Total Messages Posted	35
Total Likes Received	3

Online Status	Offline
Date Last Visited	Wednesday

Strata

Prisma

Cortex

About El-ahrairah