Important note about SSL VPN compatibility for 20.0 MR1 with EoL SFOS versions and UTM9 OS. Learn more in the release notes.

Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 5 replies
  • Subscribers 38 subscribers
  • Views 2083 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Wildcard FQDN Stopped Working After Upgrade

CV_Sophos

Hello,

Over the holiday weekend we upgraded our XG330's from 19.5.4 to 20.0.2 MR-2-Build378. After the upgrade none of our wildcard FQDN rules are resolving/working. They worked perfectly fine prior. This is causing quite a bit of issues for user authentication as several services utilize Azure IDP and they are no longer syncing. I cannot create individual FQDN items for every hostname as they appear to be dynamically created (literally have thousands of different ones in the logs for the provisioning attempts). The firewall DNS is our internal DCs (required or other aspects of the firewall fail/break going between zones). What is the best way to troubleshoot this? The lack of FQDN wildcards has become quite annoying in this day/age.

Thank you,

James



This thread was automatically locked due to age.
Parents
  • +1

    I believe I have found the issue. Under previous support recommendations I was advised that each rule should have its own dedicated/linked NAT configured. So, a large portion of our "dedicated" rules have a linked NAT configured. This appears to be working fine until there are two rules that apply to a wildcard FQDN as the destination that also contains the same host in both sources. For instance, in this case our ADSync server was a source for two rules (one for actual AD Sync - let's call it rule #1 - and another for Entra App Sync - let's call it rule #2) and both rules required a wildcard destination of *.msappproxy.net. After heavily monitoring the log files I was able to see that a request would be sent with rule #1, received, and then responded/translated to using rule #2 and vice versa. This was ultimately leading to the packets being dropped because they were not associated with a request/connection. Once I disabled rule #2 and gave the firewall 24 hours to, hopefully, clear all active sessions, the rules are working as they did with the prior firmware (19.5.4). Other similar situations have happened before when working with rules that have a linked NAT rule. To clarify, these are all LAN to WAN firewall rules. No other zone to zone type has a linked NAT. I'm not really sure why the prior firmware was behaving differently. Maybe it was more associated with the appliance restart that reset all the connections. Regardless, the issue is now resolved (ticket closed) and I will be cleaning up firewall rules and the linked NAT configurations.

    Thank you,

    James

  • 0 in reply to CV_Sophos

    Hello James,

    Thank you for taking the time to update the thread. We're glad the issue has now been resolved. 

    Thank you for your time and patience and thank you for choosing Sophos.

    Regards,

    Raphael Alganes
    Community Support Engineer | Sophos Technical Support
    Sophos Support Videos | Product Documentation  |  @SophosSupport  | Sign up for SMS Alerts
    If a post solves your question use the 'Verify Answer' link.

Reply Children
No Data
Unfiltered HTML