Failed to fetch ingest/query FQDN for customer (curl failed)

[LukeBullimore]

Hi Team,

I'm trying to onboard one of our firewals to the Cortex Data Lake. It has the logging service license and when I put in the onboarding PSK and click status, I get:

Failed to fetch ingest/query FQDN for customer (curl failed)

I've tried

- Giving the firewall an NTP server

- Removing and re-adding the license

- Manually fetching the certificate (it fails)

> request logging-service-forwarding certificate fetch

Successfully scheduled logging service certificate fetch job with a job id of 2132

> show jobs id 2132

Enqueued Dequeued ID Type Status Result Completed
------------------------------------------------------------------------------------------------------------------------------
2019/10/14 10:18:24 10:18:24 2132 LCaaS-certificate-fetch FIN FAIL 100 %
Warnings:
Details:

- Manually fetching the customer info (it fails)

> request logging-service-forwarding customerinfo fetch

Successfully fetch Logging Service region info

> request logging-service-forwarding customerinfo show

Server error : Unable to read the LCaaS customer information. Please re-fetch region info

[Chacko42]

Hi - I'm experiencing exactly the same error and opened a TAC case for this.

Do you got any feedback on your situation?

[cdowdy]

Same here.. Guess I'll be opening one as well.

[LukeBullimore]

@cdowdy @Chacko42 

Did you both get anything useful from your TAC case? This is still a problem for us and its fallen off my radar up until now.

Cheers,

Luke.

[Chacko42 · Accepted solution]

@LukeBullimore: Yes, TAC case already closed. If you are not on 9.0.4 or 8.1.13 (not available yet), you need to contact TAC to set the tenant-id for cortex/logging service.

Problem is fixed in the versions mentioned above - no workarounds available, so TAC creates root access to device and edits local files on each firewall

[cdowdy]

Yep, did that on Friday. Easy fix for TAC with root.  

[root@XXXXXXXXX ~]# sdb -i cfg.saas.custid
cfg.saas.custid: string (10 bytes)
[root@XXXXXXXXX ~]# sdb cfg.saas.custid=None
cfg.saas.custid: None
[root@XXXXXXXXX ~]# sdb cfg.saas.custid=123456789
cfg.saas.custid: 123456789
[root@XXXXXXXXX ~]# sdb -i cfg.saas.custid
cfg.saas.custid: int (len 4)

re-license FW's from Panorama

Finally, on each fw:

request logging-service-forwarding certificate delete

request logging-service-forwarding certificate fetch

[rtruyers]

Hi All,

I have seen this issue with other customers and I was able solve it with following steps :

1. Delete Logging Service License key :
   
   Rutger@panGW> delete license key Logging_Service_xx_xx_xx.key​
   successfully removed Logging_Service_xx_xx_xx.key
   
   
2. Request license Fetch:
   Rutger@panGW> request license fetch License entry:
   License entry:
   Feature: Logging Service
   Description: Device Logging Service
   Serial: xxxxxxxxx
   Authcode:
   Issued: July 29, 2019
   Expires: July 27, 2022
   Expired?: no
   Log Storage TB: 1
   
   
3. Check to see if the logging service region is being fetched. 
   In my case it was not so it was manually entered via cli:
   
   Rutger@panGW> request logging-service-forwarding customerinfo show
   Server error : Unable to read the LCaaS customer information. Please re-fetch region info​
   
   
4. Configure Location Manually via CLI:
   Rutger@panGW> configure
   Entering configuration mode
   Rutger@panGW# set deviceconfig setting logging logging-service-forwarding logging-service-regions {LOCATION, Example Europe or Americas}
   Rutger@panGW# exit
   Exiting configuration mode
   COMMIT YOUR CHANGES
5. Delete the logging service certificate
   
   Rutger@panGW request logging-service-forwarding certificate delete
   Successfully deleted Logging Service certificate.
   
   
6. MANUALLY enter the PSK that you generated from the data lake
   
   Rutger@panGW> request logging-service-forwarding certificate fetch-noproxy pre-shared-key YOUR_KEY_HERE
   Successfully scheduled logging service certificate fetch job with a job id of 12
   ​
   
   
7. Check the job ID it should say finished OK successful

Now your Firewall is onboarded with data lake

PS: in an active-passive cluster you only need to this on one of both firewalls, all the rest will be synced over the HA.

[noclss2000]

having the same issues here. we have 22 pa-220's sending to cortex data late and iot security(zingbox) using 9.1.6 and this has been an abysmal experience to say the least.

had a tac case open. after fighting with it for almost a month, they finally went into root and reset the custid from there, then relicense the firewall, then delete/re-add the certificate. seems that doing the last two steps without tac resetting the custid doesn't always help as the cert won't pull in. I just brought up another box and it's having the same issue as a lot of the other ones I had. Beware, this is not a seemless setup, very cumbersome and quite frankly makes me hate palo a little bit for their poor implementation of this. I'm opening up yet another case to get this one fixed.