- CheckMates
- :
- Products
- :
- Quantum
- :
- Security Gateways
- :
- Wildcard fqdn not matching R80.40
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Wildcard fqdn not matching R80.40
Hi,
I have a problem using wildcard fqdn's in R80.40, here is the exact issue:
DE-FRA-ANX-P002.teamviewer.com
will not match to: .*.teamviewer.com or .*teamviewer.com or .teamviewer.com
No matter what combination i try, all traffic towards teamviewer.com ends up in the cleanup rule.
Similar issues with other domains also: .*citrixonline\.*, .*gotomeeting\.*...
Can anyone help me with this?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
What precise object type are you using to create this?
Perhaps a screenshot would help.
If it’s a Domain object, this won’t work at all since that relies on reverse DNS which is almost never going to resolve to the correct name.
If it’s a Custom Application/Site, then it will only work for HTTP/HTTPS traffic.
I’m also pretty sure we have an App Control definition for TeamViewer which I recommend instead.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
So i gather that domain Objects are not the way to got with this.
i'm glad you mentioned App Control definition for TeamViewer, i was going to make a separate post for this. As using this results in a permit any for all ports matched in the App Control definition for TeamViewer. Including http and https.
Connections are permitted with this reason:
Connection terminated before detection: Insufficient data passed.
To learn more see sk113479.
I've atached some screenshots.
Thanks for your help.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
That’s the way App Control works: some traffic has to be allowed on the relevant ports for TeamViewer in order to determine it’s actually TeamViewer.
If the connection terminates before we’ve made a determination, which usually requires a few packets, then yes, that connection will be allowed.
What is your precise goal here?
Is it to allow access to TeamViewer’s website, using the TeamViewer application, or?
The TeamViewer website may require a different rule than the Application Signature, which is more for the TeamViewer application itself.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
FQDN is not a wildcard, is it?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes, i have now learned that wildcard fqdn's dont work.
My goal is to get teamviewer working again. Something on the end user PC's changed and the proxy settings are ignored, of course no one knows why. And only our Sites in Romania are affected.
I've just tested again using the App Control definition for TeamViewer, that works fine for me.
Slightly off topic here, but regarding fqdn's. I use the ip block tool described in sk103154 and beside some dynamic feeds i also feed a list (attached) of fqdn's and IP's that i manually edit. That should be fine i hope when not using wildcards..?
