We're proud to announce today that Version 1.3.3 of SecureGUARD Communication Gateway is available for download today.
We did a lot of improments and extensions to this version.
Such a lot that it's nearly impossible to write everything within one blog post.
There will be a lot of articles comming up the next days with new features and scenario descriptions.
Feature Highlights from Version 1.3.3:
- Report generation (one-time and recurring reports)
- Alerting Module
- Extended Publishing
- NTLM/KERBEROS authentication delegation
- New Templates for:
- SharePoint Server (BETA!)
How will you get the latest version?
1. If you are an existing customer with a valid CG License please register at http://www.secureguard.at/Company/Support to gain access to our download center. (if you already have a user for the support center and can’t see the CG15 tab in the download section please write a short mail with your username to email@example.com)
2. If you’re already on our newsletter mailing list you will get a direct download link with the newsletter.
3. If you’re new to EPS just sign-up via http://www.secureguard.at/Company/EPSRegistration and receive a download link immediately per mail.
Stay tuned for further information about the new version.
Hi @ all,
we changed or ISP and so we also got a new IP-Address Range.
As there are some predefined network objects within the firewall policy, on existing installations and also upgrade installations you have to change two custom computer objects:
old IP: 126.96.36.199
new IP: 188.8.131.52
old IP: 184.108.40.206
new IP: 220.127.116.11
Stay tuned for a lot of new articles in the next week.
Also a new version with a bunch of new features will be released soon.
In this blogpost i want to cover an issues we currently faced within a support case.
Per default RRAS in Windows Server 2012 R2 doesn't allow special character within the username.
This includes e.g. ö,ä,ü for the german speaking area.
You will receive a failed authentication attempt when trying to login with a user including such a character.
To workaround this issue please process the following steps:
- Click Start and type cmd
- Right-click Command Prompt and choose Run as administrator
- Type the following command: REG ADD HLKM\SYSTEM\CurrentControlSet\Services\EapHost\Configuration /v IdentityEncodingFormat /t REG_DWORD /d 1
With this registry key Windows will allow the use of special characters within the usernames.
Due to support issues we cann't recommend the use of special characters within usernamen, but if you have an existing environment you can get it to work with this registry key.
ATTENTION: Only implement this registry key if you're facing the described issue as this can lead to unpredictable side effects.
The above configuration change would however result in EAP-based authentication from a Windows 7 client to fail. To fix this case, the same registry key (shown above) can be set on the Windows 7 client so that the Windows 7 client uses ANSI format for EAP-based authentication protocols too.
Concerning our earlier blog entry regarding the Windows Update issue we want to inform you, that the july 2016 update rollup KB3172614 is also resolving the issues with KB3147071 andKB3126593.
KB3156418 is superseded by KB3172614 and no longer has to be installed.
Please ignore the warning which is shown on the opening of SG Management regarding these issues if you have already installed KB3172614.
We want to inform you that the Windows Update issues with KB3147071 and KB3126593 are confirmed as a bug in Windows Server 2012 R2.
More Information: https://support.microsoft.com/en-us/kb/3155768
If you are facing this issue please install the following Update Rollup from May 17th, 2016:
ATTENTION: Windows Update KB3147071 issues problems with the local Windows Firewall of Windows Server 2012 R2.
As Communication Gateway makes use of the local Windows Firewall this also affects CG in working correctly.
Please do not install KB3147071 on operating system instances Communication Gateway is installed on.
In case the update is already installed: uninstalling KB3147071 restores the local Windows Firewall functionality and will regain the full Communication Gateway experience.
Please be sure to disable the automatic update functionality for KB3147071 to prevent future installation.
As the known issue with KB3126593 is still under investigation by Microsoft, please also disable the automatic update functionality for update KB3126593.
As soon as we have further information from Microsoft, we will post an update.
We want to inform that an issue with Windows Updates released in April 2016 is currently under investigation.
We will update this post as soon as more information is available.
In the mean time we do not recommend installing Windows Updates released on April 12th, 2016 at EPS installations.
More information about Windows Update: https://technet.microsoft.com/en-us/library/security/ms16-apr.aspx
In the last part of the "Web Access Rules" blog post series I want to cover "URL Permission Set".
You can select one permission set per Web Access Rule.
There are two default preconfigured permission sets available: "Allow All" and "Block All"
You can also define custom URL Permission Sets:
There are two settings available for a URL Permission Set regarding Antivirus capabilities:
- Treat executable file as virus
- Treat encrypted file as virus
This settings are only active if both of the following applies:
- Antivirus is activated within the Web Access Rules General Settings
- You have valid subscription for the Web Security Add On
A Permission Set consists of one or more Permission entries. For each entry you can define if you want to Block or Allow the appropriate traffic.
You can mix-up Block and Allow entries as you want, but be aware that also the Permission Entries set is processed on a first-match base!
You can pick three different filter types:
All traffic will be blocked or allowed when using this type.
You can specify specific URL's which you want to block or allow with an permission entry. You can also use regular expressions within the URL entries (e.g. *.secureguard.at).
If you have an active subscription of the Web Security Add On you can select from an URL filtering database consisting of more than 100 different categories.
In this blog post I want to cover the different available authentication methods for Web Access Rules.
A Web Access Rule allows HTTP/HTTPS traffic from a specific source to a specific destination.
There are three different possibilities for "Authentication Methods":
- No Authentication
- LDAP Authentication
If you select "No Authentication" the Web Access Rule will apply to all HTTP/HTTPS Traffic from the specified source to the specified destination (for sure depending on your "Rule Mode" settings ;-) ).
If you want to make use of LDAP Authentication please make sure that the LDAP Authentication Settings are configured properly.
As soon as you select "LDAP Authentication" you will get a new "USERS/GROUPS" tab:
Within this Tab you can choose between Users or Groups and have to enter the appropriate User or Group Name as registered in LDAP:
You can make use of this authentication method if the OS/appliance is part of an Active Directory Domain (or if you want to use local users and groups).
As soon as you select "NTLM/Kerberos Authentication" you will also get a new "USERS/GROUPS" tab:
As soon as you click plus, you get a selection wizard for selecting Users or Groups:
Within this dialog you can browse different locations (local machine or your entire Active Directory Forest) and search for Users and Groups to select them.
With Authentication, you can restrict the validity of a Web Access Rule to a specific set of Users or Groups. Please be aware that the "Web Access Rules" ruleset is processed by first-match. This is especially important if User are member in different Groups.
Also be aware that rules where LDAP or NTLM/Kerberos is configured will not match for transparent HTTP traffic. You have to define a specific ruleset for the transparent mode (without authentication).
In todays blog post I want to cover the different Rule Modes when creating a Web Access Rule.
You can define the behavior with Rule Mode for every single Web Access Rule with the following Rule Modes:
Allows or blocks web access using an explicit proxy IP address and port (which is configured within the HTTP Proxy setting within the Web Access Rules module). Every single client have to be configured with the appropriate settings. You can also use Kerberos authentication (if the server is domain joined) or LDAP authentication (LDAP Authentication settings have to be configured) with Proxy Mode.
The required Firewall Rules and NAT rules will be generated automatically.
Allows or blocks web access as transparent proxy. On the clients the IP address of the server have to be configured as default gateway or as gateway on a dedicated route.
Please be aware that the transparent rule mode doesn't support authentication.
The required Firewall Rules and NAT Rules will be generated automatically.
Proxy and Transparent
Combines both modes proxy and transparent modes. All required Firewall Rules will be generated automatically.
Please be aware that authentication is only used when a client accesses the proxy via the dedicated IP address - port combination.
Manually create FW and NAT rules
By selecting this mode, firewall rules and NAT rules have to be created manually. Select this option if you want to use a dedicated external IP address used for hide-NAT. The other three modes use the primary IP-address configured on the external interface.