Enhanced Security Measures in Place:   To ensure a safer experience, we’ve implemented additional, temporary security measures for all users.

Allow wildcard DNS in a Network Address

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements

Allow wildcard DNS in a Network Address

L1 Bithead

Hello all,

 

We have setup a Hybrid Connection Wizard between our on-prem Exchange server and Office 365, Microsoft has provided the following link for reference in regards to firewall considerations (https://bit.ly/3dpfiZs)

 

under SMTP port 25 - the documents lists *.mail.protection.outlook.com as a required under ID#10.

Can anyone advise on the easiest method to allow this as a dynamic address to add to our firewall rule for port 25 traffic?

 

I found this article ( https://bit.ly/2L5CtM1) but it seems to be applied to URL whitelisting etc.

 

Would be great if PA or other member can share this element of the Hybrid Configuration  Wizard and how they overcame this issue.

1 accepted solution

Accepted Solutions

@C4c-1942,

 

Custom URL category and FQDN object are different configurations all together and used for different requirements.

 

FQDN object is address object which simply can be used as source Address or Destination Address under Security Policy. For FQDN objects, firewall sends query to its DNS server and get the list of IP addresses associated with that FQDN. Yes Palo Alto maps maximum 10 IP addresses to that FQDN object. And you can't add wildcard domain as a FQDN object as per it's name. It will accept only complete domain.

 

Now the solution that I am talking about is creation of Custom URL Category (type URL list). You can create custom URL category and add single/multiple wildcard domains under it. Once it is created. it can be called in Security Policy under URL category tab.

 

For your requirement, security policy would be,

Source IP - Required IP/Network

Destination - Any

APP ID/Service - Required one

URL category - Custom category created by you.

Action - Allow

 

This policy will allow only traffic which is specific to your desired wildcard domain specified under Custom URL category.

You can refer below article and follow Option 1 : Use URL Category.

 

https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000CltmCAC

 

Hope it helps!

Mayur

 

 

M

Check out my YouTube channel - https://www.youtube.com/@NetworkTalks

View solution in original post

10 REPLIES 10

L6 Presenter

@C4c-1942,

 

 

1. Create Custom URL category and add your wildcard domain in it i.e. *.mail.protection.outlook.com

2. Call this custom URL category under Security Policy --> URL Category tab.

3. Configure required Source and Destination zones/IPs and APP-ID /services in the policy.

 

Currently this is the best option available to achieve your requirement.

 

Mayur

M

Check out my YouTube channel - https://www.youtube.com/@NetworkTalks

i Mayur,

 

 

many thanks for your reply, im just learning the PA set-up so will try and implement and come back to you on the results

 

thanks for your time! 🙂

Hi Mayur,

 

This is what im getting back from the firewall team:-

 

When an FQDN object is committed to the system, the management plane sends out periodic DNS queries to populate this object with IP addresses mapped from the DNS reply. These mapped IP addresses are then be pushed down to the dataplane, where they're used inside the object in the security policy. On the dataplane, this object includes only the IP addresses it receives from the management plane, but no domain information. Each FQDN object on the dataplane is limited to a maximum of 10 IP addresses. No actual URL lookups are performed, which is why a wildcard cannot be used.

@C4c-1942,

 

Custom URL category and FQDN object are different configurations all together and used for different requirements.

 

FQDN object is address object which simply can be used as source Address or Destination Address under Security Policy. For FQDN objects, firewall sends query to its DNS server and get the list of IP addresses associated with that FQDN. Yes Palo Alto maps maximum 10 IP addresses to that FQDN object. And you can't add wildcard domain as a FQDN object as per it's name. It will accept only complete domain.

 

Now the solution that I am talking about is creation of Custom URL Category (type URL list). You can create custom URL category and add single/multiple wildcard domains under it. Once it is created. it can be called in Security Policy under URL category tab.

 

For your requirement, security policy would be,

Source IP - Required IP/Network

Destination - Any

APP ID/Service - Required one

URL category - Custom category created by you.

Action - Allow

 

This policy will allow only traffic which is specific to your desired wildcard domain specified under Custom URL category.

You can refer below article and follow Option 1 : Use URL Category.

 

https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000CltmCAC

 

Hope it helps!

Mayur

 

 

M

Check out my YouTube channel - https://www.youtube.com/@NetworkTalks

L1 Bithead

I know this post has already an accepted solution but it does not seem to answer the question.

 

The question is how to allowed traffic on port 25 from *.mail.protection.outlook.com.  I don't see how adding a URL category to the policy answers this since the traffic is coming in on port 25 and will not be using URLs.

 

 

I've just run into this problem converting Check Point's 'domain' objects (which match a parent and any subdomain). Expedition converted the objects to a group containing a) the domain suffix and b) a www record, assuming that's the only subdomain we needed 🙂

 

I have found the URL category match criteria in a rule does NOT appear to apply to connections that don't use an actual URL e.g. ping or ssh to *.amazonaws.com

 

In which case how would we allow ssh access to *.amazonaws.com in PAN-OS?

Hi @mb_equate ,

 

Have you found any solution for this? I wanted to do the same things too.

 

Thank you.

L3 Networker

Hi @KongLun 

Not currently. It's a result of the method used to resolve a FQDN object (i.e. forward DNS lookup), as the name implies it must be fully qualified. And URL filtering only applies to web traffic.

 

Since there's no indication of the remote DNS hostname in something like an SSH session there's no way for the device to accurately determine what the FQDN was.

 

The previous vendor achieved non-FQDN (i.e. wildcard/subdomain) enforcement through reverse lookups, which is not all that reliable anyway. I think if there was a robust solution it would be supported by PAN-OS already 🙂

How can I impelment this in a NAT Rule? Do you have any Idea?

 

Thx

Ahmad

Hi @Alammar, the simple answer is you can't - as @${userLoginName} described "you can't add wildcard domain as a FQDN object as per it's name", nor can you use a custom URL category or domain EDL (which permit the use of wildcards) as match criteria in a NAT rule. This is because the firewall caches the IPs that your FQDN object resolves to for use within a policy rule, which is not possible when the FQDN is not known as in the case of a wildcard or "domain".

There may be other ways to achieve what you want, depending on requirements e.g. use routing to steer traffic dynamically (e.g. BGP) and base your NAT on the destination zone, or use an EDL such as one of the IPv4 lists published at EDL Hosting Service (paloaltonetworks.com).

There are many ways to skin a cat 🙂

  • 1 accepted solution
  • 37617 Views
  • 10 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!