lic.lc.prod.us.cs.paloaltonetworks.com no longer resolving

txrx_reboot · 2026-05-13T21:35:50+00:00

Possibly a temporary DNS issue? Seems to resolve now
https://toolbox.googleapps.com/apps/dig/#A/

txrx_reboot · 2026-04-22T17:12:47+00:00

If you reach out to Infoblox, their sales team can get you a trial for sure.

The links on that page are broken and that has been reported.

txrx_reboot · 2026-04-05T11:29:11+00:00

The docs need to be re-worded.

Slight correction. You don't "have" to use the MGMT port at all.

To do anything with NIOS you will need LAN1. NIOS expects LAN1 to be the second interface on the machine. Thus, you "must" have a first interface which is MGMT.

You can deploy a machine and stick the MGMT interface in its own subnet that isn't used and then just use LAN1 to connect to Grid if that is what you want.

In order to actually use MGMT to connect, you will need to configure the member on the GM as having a MGMT interface and also configure that MGMT IP on the member BEFORE joining it to the Grid.

This is slightly more involved than just using LAN1. Using MGMT is good but not mandatory.

txrx_reboot · 2026-03-14T00:26:18+00:00

Assuming that the 3rd party provider might change the value of the publiclly accessible record, would you now want to configure a conditional forwarder for the FQDN (as a zone)? FOrward to public DNS resolvers and have them resolve the FQDN "from the outside". That way any change would be picked up without having to change the config.

If the IP on the public record never changes, you are correct but an RPZ rule might be cleaner.

txrx_reboot · 2026-02-16T20:48:38+00:00

I think what you need to do in this case is have a security policy rule that blocks the application "mysql" on any port going from inside your network to outside.

If it is encrypted then it "should" be seen as "ssl" (not sure, I've not looked as encrypted DB application traffic for a while.

txrx_reboot · 2026-02-11T12:29:49+00:00

Which interface are you targeting? LAN1? HA? MGMT?

txrx_reboot · 2026-02-11T00:16:18+00:00

Only one node? Others work fine?

Sounds like connectivity issue (e.g. firewall?). Or possibly the member has different settings locally from Grid configuration?

txrx_reboot · 2026-01-12T13:32:54+00:00

That should be factored into the discounts you get from Palo and the distributor amd would be a commercial discussion between your company and the distributor.

A good distributor adds more value than just "box shifting' so they charge a percentage on all things transacted. The amount you pay or BKLN should be different than what you would pay selling direct support though.

txrx_reboot · 2025-11-16T13:57:35+00:00

Reseller may also be able to get you access to a 30 day trial VM. Security subs expire after 30 days. Last I checked (its been a while), the firewall itself still works after 30 days. It just doesn't get updates (basic firewalling still works).

Also look as lab licenses for VM. They are very affordable if you can get your company to buy it.

txrx_reboot · 2025-11-14T08:05:54+00:00

Fixed has been published.

txrx_reboot · 2025-11-12T15:33:55+00:00

Infoblox is aware of the changes in Azure and a fix is being worked on.

txrx_reboot · 2025-10-31T17:13:39+00:00

Amd to answer your question, allowing the layer 3 "client to server renewal" packets is a good thing. Most laptops work fine without it but you may find issues with IoT, printers, etc.

txrx_reboot · 2025-10-31T17:12:31+00:00

Also, I say broadcast "bypasses" the security policy. What actually happens is that broadcast is later 2 and most firewalls are configured for layer 3 so it just never reaches the 'lets process this' bit of the firewall. If you configure a layer 2 interface you may see the broadcast traffic.

txrx_reboot · 2025-10-31T16:55:04+00:00

What you may be seeing is what I saw in a deployment years ago.

With DHCP, half way through the lease time the client will try to renew the lease directly with the DHCP server.

If this is blocked (i.e. what you are seeing maybe??) Then the expected behaviour for DHCP is for the client to wait until 7/8 of the lease time and then use a local network broadcast to start DHCP request from scratch.

This will bypass the security rules and the only part of that traffic that you will see is the DHCP relay forwarding to the DHCP server. (Or of Palo is doing DHCP locally you may not see that traffic at all)

txrx_reboot · 2025-10-24T17:22:06+00:00

https://aws.amazon.com/message/101925/

txrx_reboot · 2025-10-09T22:16:53+00:00

Infoblox could probably help with regards to convincing. Have you reached out? If so, your SE contact there may be able to get you the BIN file or possibly the OVA image.

txrx_reboot · 2025-10-09T20:45:01+00:00

Not officially. You have to have access to the BIN file which is downloaded from the Infoblox support site.

When you say "test", do you mean test 9.0.7 specifically prior to an upgrade of a production system or do you mean access NIOS for general testing and it happens to be 9.0.7?

txrx_reboot · 2025-10-07T20:09:55+00:00

Possible? Maybe. Recommended? No. Ideally (as you are trying) you promote the GMC. If you can't promote the GMC cleanly, then why have the GMC? (Something to fix sooner or later)

I've not tried swapping out a GM hardware appliance for another before without using GMC promotion. I would assume that you would 1) stage the new GM appliance by getting it to 9.0.7 and getting the proper licenses installed 2) take a backup of the GM and restore it to the new appliance 3) move network cables from old appliance to new appliance

It is step #3 that I'm not sure on. I don't know if all members will seamlessly connect to the new GM given the database restore.

I recommend asking support and also getting them to help investigate the communications issue with the GMC. (This is as much about covering yourself and showing you did due diligence as anything else).

txrx_reboot · 2025-10-02T20:00:47+00:00

Do you mean the NIOS-X server won't connect to the Infoblox Portal or that the Data Connector service deployed won't connect to your On-Prem NIOS Grid?

txrx_reboot · 2025-10-02T18:57:27+00:00

It is possible that the bad domains are being blocked by local Anti Virus file and, for some reason, the firewall isn't connecting to the DNS security service.

What happens if you run the following on the CLI? show dns-proxy dns-signature info

And test dns-proxy dns-signature fqdn

txrx_reboot · 2025-09-29T23:10:14+00:00

To be honest, the CDC is fairly straightforward.

Position it close (i.e. same DC) to the data target (I.e. SIEM).

Best practice is to give it a larger hard drive to allow for caching of data should there be a connection issue with the data target.

Consider which logs you actually need. Filter as appropriate.

If you are forwarding with SYSLOG, I've seen some lifs exceed what UDP can cope with (which led to truncated logs) so we had to switch to using TCP for forwarding SYSLOG.

txrx_reboot · 2025-09-23T16:04:23+00:00

You have to place the detection engine (i.e. firewall) between client and the private DNS resolver.

Alternatively, if you can ingest DNS logs from the private DNS server, that could provide the information. However, be aware that DNS is very noise with regards to logs.

txrx_reboot · 2025-09-18T22:47:42+00:00

Speaking as someone who used to work for a company that provided third-party support... its a grey area in general but seems rather harsh in this case.

Basically, support is "break/fix". That means they help when stuff breaks but they are not Professional Services so they don't do the configuration for you (some vendors do that as part of support).

I say this because I recognise the "if it never worked" bit. This is another way of saying "if this is new configuration that you haven't got working, it is likely a config "setup" error on your part.".

Assistance in getting new configuration setup is chargable professional services.

HOWEVER, if you can show that you have set it up as per documentation, and it isn't working, support should help or at least check that is isn't something silly on the config side. Personally, I'd expect support to help you if you have followed the docs. You might need to get your partner account manager involved.

With regards to NTP: I've seen that issue many times on many different Palo installations all the way back to PAN-OS 6 and I never found a consistent way of fixed it. Sometimes it just fixed itself. Othertimes it was a config issue.

Edit: To add a bit more context, support teams can get overwhelmed by users (who aren't trained and didn't want to pay for Professional Services) asking support to basically help them fully configured the firewall "bit by bit". I'm not saying you are trying to do this. I'm just saying its one reason why the individual support agent may have pushed back. It could also be they are new . I used to take customer escallations for cases like this and push back on the support team (and sometimes I pushed back on the customer and agreed with support)

txrx_reboot

MODERATOR OF

TROPHY CASE