- CheckMates
- :
- Products
- :
- Quantum
- :
- Security Gateways
- :
- Re: HTTPS on external interface
- 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
HTTPS on external interface
Hi,
I have a single R80.30 gateway, with Identity awareness blade enabled.
A few days ago, I migrated from AD Query to Identity Collector. Since then, the external interface is reachable via HTTPS. The response is:
HTTP ERROR 404
Problem accessing /. Reason:
Not Found
However I would like to completely block any incoming connections from the Internet.
Both Portal an Identity Collector are configured to allow access "through internal interfaces" only.
Any ideas?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
R80.30 is out of support already, please consider moving to the recommended version as soon as possible.
I assume your external HTTPS connections are accepted via rulebase? Which rule in particular?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Val,
That's the thing - I have no rule that allows HTTPS access to the firewall object. I even created a rule that explicitly blocks HTTPS access to the firewall object from non-internal networks (i.e. added internal networks to the cell, and negate), but it made no difference.
Also, there are no HTTPS-related Implied rules.
Andy - the URL filtering blade is not enabled on this gateway. I believe it requires a license (?).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Look in the logs please, there should be something for this access.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Everything on CP requires a license, haha. Anyway, the reason why I said to add object Internet to the rule is because "any" means internal stuff as well and you dont want to block that.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
First, an emergency can be tackled with an evaluation license. Second, I do not believe it is something related to URL filtering, it is a different configuration issue.
Adding complexity and trying to block it with URL filtering does not make sense. Lt's figure out simple things first.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
True, but I never said its URL filtering related anyway. The reaosn why I brought it up in the first place is due to being able to use object "Internet", you have to have URLF enabled, thats all.
But I agree, checking the logs would be a good idea to start with.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I am testing this with an external computer that has a fixed IP.
In the logs, there are a few DROPs, either because 'First packet isn't SYN', or 'Dropped by multiportal infrastructure'. However, I cannot see any ACCEPTs.
EDIT: Just to clarify, no Rule Name/Number is associated with these DROPs.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Just have a rule that says source Internet, dst your fw object, service https, action block. Make sure you have url filtering blade enabled in policy properties to use "Internet" object itself.
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Seen that sk before, makes sense.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I want to give it a try but for some reason the utility fails to connect (make sure that the server is up and running etc.). SmartConsole works just fine from this very computer/user ☹️
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Can you confirm that traffic from TCP 18190 is being received on your management server from the computer in question (e.g. with tcpdump)?