<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: FQDN not working vs Resolved IP address in General Topics</title>
    <link>https://live.paloaltonetworks.com/t5/general-topics/fqdn-not-working-vs-resolved-ip-address/m-p/328395#M83451</link>
    <description>&lt;P&gt;&lt;a href="https://live.paloaltonetworks.com/t5/user/viewprofilepage/user-id/13081"&gt;@rockfort&lt;/a&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;Questions:&lt;/STRONG&gt;&lt;/P&gt;&lt;P&gt;1. Why would the&amp;nbsp;&lt;STRONG&gt;interzone-default&amp;nbsp;&lt;/STRONG&gt;rule become a part of the failed attempt to connect to the new rule&lt;/P&gt;&lt;P&gt;&lt;FONT color="#FF0000"&gt;Because the new rule isn't properly matching the traffic. I would verify with the '&lt;EM&gt;request system fqdn show'&amp;nbsp;&lt;/EM&gt;or&amp;nbsp;&lt;EM&gt;''show dns-proxy fqdn all'&amp;nbsp;&lt;/EM&gt;depending on your currently installed version of PAN-OS to verify that the firewall is actually properly resolving the FQDN object to the proper address.&lt;/FONT&gt;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;2. Anyone know why connection fails with the FQDN set as destination rather than it's resolved IP address&lt;/P&gt;&lt;P&gt;&lt;FONT color="#FF0000"&gt;99.8% of the time, this is due to the FQDN object either not refreshing properly or the rule not properly being built to accommodate for the traffic that's actually being seen by the firewall. Once you've verified the FQDN object is resolving properly, you'll want to test the rulebase entry and look at the recorded logs and make sure that your rulebase entry as configured properly accounts for the traffic.&amp;nbsp;&lt;/FONT&gt;&lt;/P&gt;</description>
    <pubDate>Sun, 17 May 2020 01:57:56 GMT</pubDate>
    <dc:creator>BPry</dc:creator>
    <dc:date>2020-05-17T01:57:56Z</dc:date>
    <item>
      <title>FQDN not working vs Resolved IP address</title>
      <link>https://live.paloaltonetworks.com/t5/general-topics/fqdn-not-working-vs-resolved-ip-address/m-p/328389#M83450</link>
      <description>&lt;P&gt;I created a new FQDN address object to facilitate a new Policy(rule).&lt;/P&gt;&lt;P&gt;&amp;nbsp;When tested the FQDN resolves internal to the Palo Alto Firewall.&lt;/P&gt;&lt;P&gt;The rule contains one destination address which is the new company.fqdn.com FQDN&lt;/P&gt;&lt;P&gt;The rule contains one source address&lt;/P&gt;&lt;P&gt;Application SSL with Application-Default Service&lt;/P&gt;&lt;P&gt;Action Allow&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;When attempts are made&amp;nbsp;&lt;SPAN&gt;to &lt;/SPAN&gt;&lt;SPAN&gt;connect&amp;nbsp; to this destination via the new rule with the &lt;STRONG&gt;FQDN&lt;/STRONG&gt; set(destination), the traffic is &lt;STRONG&gt;denied&lt;/STRONG&gt;(fails) and logs point to(identify) the "&lt;STRONG&gt;interzone-default&lt;/STRONG&gt;" rule instead of the "new rule" that is set up to facilitate this connection&lt;/SPAN&gt;&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;But when I replace the FQDN(destination) with it's &lt;STRONG&gt;&lt;EM&gt;resolved&lt;/EM&gt;&lt;/STRONG&gt; &lt;STRONG&gt;IP&lt;/STRONG&gt; in the new rule, it works fine(&lt;STRONG&gt;allowed&lt;/STRONG&gt;) and logs point the occurrence to the "new rule" (not the interzone-default) as to be expected since that is normal behavior&amp;nbsp;&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;Questions:&lt;/STRONG&gt;&lt;/P&gt;&lt;OL&gt;&lt;LI&gt;Why would the&amp;nbsp;&lt;STRONG&gt;interzone-default&amp;nbsp;&lt;/STRONG&gt;rule become a part of the failed attempt to connect to the new rule&lt;/LI&gt;&lt;LI&gt;Anyone know why connection fails with the FQDN set as destination rather than it's resolved IP address&lt;/LI&gt;&lt;LI&gt;As anyone had a similar experience&lt;/LI&gt;&lt;/OL&gt;&lt;P&gt;Thanks in advance.&lt;/P&gt;</description>
      <pubDate>Sun, 17 May 2020 01:45:51 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/general-topics/fqdn-not-working-vs-resolved-ip-address/m-p/328389#M83450</guid>
      <dc:creator>rockfort</dc:creator>
      <dc:date>2020-05-17T01:45:51Z</dc:date>
    </item>
    <item>
      <title>Re: FQDN not working vs Resolved IP address</title>
      <link>https://live.paloaltonetworks.com/t5/general-topics/fqdn-not-working-vs-resolved-ip-address/m-p/328395#M83451</link>
      <description>&lt;P&gt;&lt;a href="https://live.paloaltonetworks.com/t5/user/viewprofilepage/user-id/13081"&gt;@rockfort&lt;/a&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;Questions:&lt;/STRONG&gt;&lt;/P&gt;&lt;P&gt;1. Why would the&amp;nbsp;&lt;STRONG&gt;interzone-default&amp;nbsp;&lt;/STRONG&gt;rule become a part of the failed attempt to connect to the new rule&lt;/P&gt;&lt;P&gt;&lt;FONT color="#FF0000"&gt;Because the new rule isn't properly matching the traffic. I would verify with the '&lt;EM&gt;request system fqdn show'&amp;nbsp;&lt;/EM&gt;or&amp;nbsp;&lt;EM&gt;''show dns-proxy fqdn all'&amp;nbsp;&lt;/EM&gt;depending on your currently installed version of PAN-OS to verify that the firewall is actually properly resolving the FQDN object to the proper address.&lt;/FONT&gt;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;2. Anyone know why connection fails with the FQDN set as destination rather than it's resolved IP address&lt;/P&gt;&lt;P&gt;&lt;FONT color="#FF0000"&gt;99.8% of the time, this is due to the FQDN object either not refreshing properly or the rule not properly being built to accommodate for the traffic that's actually being seen by the firewall. Once you've verified the FQDN object is resolving properly, you'll want to test the rulebase entry and look at the recorded logs and make sure that your rulebase entry as configured properly accounts for the traffic.&amp;nbsp;&lt;/FONT&gt;&lt;/P&gt;</description>
      <pubDate>Sun, 17 May 2020 01:57:56 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/general-topics/fqdn-not-working-vs-resolved-ip-address/m-p/328395#M83451</guid>
      <dc:creator>BPry</dc:creator>
      <dc:date>2020-05-17T01:57:56Z</dc:date>
    </item>
    <item>
      <title>Re: FQDN not working vs Resolved IP address</title>
      <link>https://live.paloaltonetworks.com/t5/general-topics/fqdn-not-working-vs-resolved-ip-address/m-p/328436#M83467</link>
      <description>&lt;P&gt;Thank you very much&lt;/P&gt;</description>
      <pubDate>Sun, 17 May 2020 16:59:32 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/general-topics/fqdn-not-working-vs-resolved-ip-address/m-p/328436#M83467</guid>
      <dc:creator>rockfort</dc:creator>
      <dc:date>2020-05-17T16:59:32Z</dc:date>
    </item>
    <item>
      <title>Re: FQDN not working vs Resolved IP address</title>
      <link>https://live.paloaltonetworks.com/t5/general-topics/fqdn-not-working-vs-resolved-ip-address/m-p/378544#M89488</link>
      <description>&lt;P&gt;I Have similar problem however in my case on firewall when I create fqdn object it resolve to&amp;nbsp; IP and when I use same object in rule that rule doesnt work, then I need to add IPs manualy based on deny logs in same rule.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;I observe one strange thing when I resolved fqdn address object it resolved to some different IPs and when I nslookup fqdn in cmd it resolved to some&amp;nbsp; completely different subnet&amp;nbsp; IPs and same IPs when I allowed in rule then rule works.&lt;/P&gt;&lt;P&gt;I guess&amp;nbsp; firewall is not resolving to correct IPs .&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Fri, 08 Jan 2021 07:14:24 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/general-topics/fqdn-not-working-vs-resolved-ip-address/m-p/378544#M89488</guid>
      <dc:creator>DhananjayBhakte</dc:creator>
      <dc:date>2021-01-08T07:14:24Z</dc:date>
    </item>
    <item>
      <title>Re: FQDN not working vs Resolved IP address</title>
      <link>https://live.paloaltonetworks.com/t5/general-topics/fqdn-not-working-vs-resolved-ip-address/m-p/474503#M103376</link>
      <description>&lt;P&gt;I also have the same problem...and follow your steps to try to troubleshoot the problem but encounter a problem.&lt;BR /&gt;1. I have verified "show dns-proxy fqdn all" in the command line and confirmed that the fqdn has a proper match to the proper IP address.&lt;BR /&gt;2. How can I test that the firewall's rulebase resolves to the proper ip?&lt;/P&gt;</description>
      <pubDate>Mon, 21 Mar 2022 02:14:07 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/general-topics/fqdn-not-working-vs-resolved-ip-address/m-p/474503#M103376</guid>
      <dc:creator>DevonFan</dc:creator>
      <dc:date>2022-03-21T02:14:07Z</dc:date>
    </item>
    <item>
      <title>Re: FQDN not working vs Resolved IP address</title>
      <link>https://live.paloaltonetworks.com/t5/general-topics/fqdn-not-working-vs-resolved-ip-address/m-p/503368#M105417</link>
      <description>&lt;P&gt;We are also having a similar problem with the FQDN in an address object.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;For a given fqdn, the result of nslookup is different from&amp;nbsp;&lt;EM&gt;"show dns-proxy fqdn all" &lt;/EM&gt;which is also different from the&lt;EM&gt; "resolve" &lt;/EM&gt;of the fqdn in the address object of the gui.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Other fqdn's appear to work OK, but the associated IP's may be static and the IP list much shorter.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;We are using DNS Proxy and the cache is activated.&amp;nbsp; We had TTL activated as well, but i've removed it as its not necessary.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Shall we try deleting the address object and recreating?&amp;nbsp; How can we resolve this?&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Thanks&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Tue, 14 Jun 2022 06:58:42 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/general-topics/fqdn-not-working-vs-resolved-ip-address/m-p/503368#M105417</guid>
      <dc:creator>landoa</dc:creator>
      <dc:date>2022-06-14T06:58:42Z</dc:date>
    </item>
    <item>
      <title>Re: FQDN not working vs Resolved IP address</title>
      <link>https://live.paloaltonetworks.com/t5/general-topics/fqdn-not-working-vs-resolved-ip-address/m-p/503377#M105420</link>
      <description>&lt;P&gt;I also tried the fqdn force refresh command, to no avail.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;However, I just saw this article that states that only "up to 32 addresses" are mapped to an FQDN used in an address object:&amp;nbsp;&amp;nbsp;&lt;A href="https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClHJCA0" target="_blank"&gt;https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClHJCA0&lt;/A&gt;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;So, what does this mean for the fqdn we are using?&amp;nbsp; edge-teams.plcm.vc (&lt;A href="https://mxtoolbox.com/SuperTool.aspx?action=a%3aedge-teams.plcm.vc&amp;amp;run=toolpage" target="_blank"&gt;https://mxtoolbox.com/SuperTool.aspx?action=a%3aedge-teams.plcm.vc&amp;amp;run=toolpage&lt;/A&gt;) - goes way over the 32 limit.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Thanks&lt;/P&gt;</description>
      <pubDate>Tue, 14 Jun 2022 07:21:32 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/general-topics/fqdn-not-working-vs-resolved-ip-address/m-p/503377#M105420</guid>
      <dc:creator>landoa</dc:creator>
      <dc:date>2022-06-14T07:21:32Z</dc:date>
    </item>
  </channel>
</rss>

