I just configured a Sophos UTM cluster based on software version 9. I was able to configure the appliance via WebAdmin and I could access the User Portal without any problems. The customer is using a Citrix based environment with Internet Explorer 9. IE9 is configured to use the Sophos UTM cluster as proxy server. The customer was able to access the User Portal, but he couldn’t access the WebAdmin page.
When they tried to access the WebAdmin page, the page isn’t shown correctly. The page is crippled and you don’t get the login options for entering username and password. We tried different settings, like adding the page to the trusted websites and to the proxy exemptions. Nothing seemed to help. We asked mighty Google for help and we found the following thread.
The following snippet from the thread solved the problem:
Had one of my guys have this problem already… remove the URL for the UTM from the Compatibility View list (in his case, he had to uncheck the “view intranet sites in compatibility view” checkbox in IE).
The customer changed this Group Policy Object in Active Directory and everybody was happy.
While testing a McAfee Enterprise Firewall running software 8.2.0, I had some problems with the creation of a NAT mapping. The firewall is configured as standalone firewall. All (NAT / access rule) configuration on the firewall is done using Access Control Rules. McAfee uses two types of NAT mapping:
I tried to publish an internal network component to the internet. I created a simple rule with the following parameters. These parameters are very straightforward and the configuration is similar to firewalls from different vendors:
|Application: SSH||Source Zone:
Public IP address
Private IP address
I tested the NAT mapping, but couldn’t connect to the internal component using the public IP address. The first step in troubleshooting is looking at the logging, but I couldn’t find any logging on the firewall. It looked like the traffic didn’t even reach the firewall.
We have a shared internet segment with multiple firewalls. So I started doubting the configuration of the different firewalls.
I looked at the configuration of the firewalls, but nobody was using the public IP address. With this in mind, I ruled out the ARP entry “problems” on the ISP router.
When using NAT on a public IP address, which isn’t the same as the interface IP address, the firewall has to proxy ARP the public IP address. So does the firewall proxy ARP for the public IP address?
I started looking at the rest of the configuration with emphasis on the network configuration. I noticed that I had the option to add an alias IP address to the external interface. This can be found under Network – Interfaces – external interface. I added the public IP address as alias.
You guessed it. The NAT mapping is working……
Today I am playing with eSafe 8 operating in eSafe Proxy with NTLM authentication mode. Configuring eSafe Proxy with NTLM authentication is very straightforward and not difficult. The authentication settings are configuring using the eSafe Appliance Manager web interface, like shown below.
I did some testing with multiple browsers and single sign-on with NTLM authentication is working perfectly. The system administrator was also testing, but he was complaining that he couldn’t authenticate. A pop-up box is received and when you enter the appropriate credentials, they aren’t accepted by eSafe. I found out that the customer is using Windows 7 and I was testing with Windows XP and Windows Server 2003.
Windows Vista, Windows 7 and Windows Server 2008 R2 and higher use NTLM v2.0-only by default. eSafe Proxy uses NTLM v1.0. The default setting within Windows can be changed to operate in a mode which is backwards compatible with eSafe Proxy. Take the following steps to change the NTLM settings:
The picture shows the policy setting within Windows. This should solve the problem with single sign-on on Windows Vista, Windows 7 and Windows Server 2008 R2 and higher.
ISA Web Chaining rules define how traffic will be handled by the proxy server. Web request to specific destination can be handled in different ways by ISA:
The most popular use for Web Chaining is to chain branch office ISA firewalls with main office ISA firewalls. But also combining two ISP connections is a commonly used scenario for Web Chaining. I often use Web Chaining from ISA server with some kind of upstream proxy server. A lot of organizations use ISA as proxy server and some kind of dedicated appliance (maybe in DMZ environment) as content scanner.
With Web Chaining you can forward all request to the upstream proxy server, which will retrieve the specified destination from the internet. Specific website could have problems with being forwarded to the upstream server. I normally use Web Chaining to directly retrieve these website from the internet without being forwarded to the upstream proxy.
To create a Web Chaing Rule, open the ISA Management Console and navigate to Networks. In the center of the Management Console you will find a tab called Web Chaining. The default Web Chaining rule is configured to forward all request to an upstream proxy server.
The following screenshots tell you how to configure an additional Web Chaining rule to directly retrieve the destination (www.4ip.nl) from the internet.
|Start the creation of a Web Chaining rule by clicking on Task – Create new Web Chaining rule.
This will start the New Web Chaining Rule Wizard.
Enter a valid name for the newly created Web Chaining Rule.
|Select the destination to which this Web Chaining Rule will apply.
I configured an URL set containing the URL: http://www.4ip.nl/*
|On the Request Action page, you configure how you want the Web requests to that particular destination routed by the ISA firewall.
The default setting is to route the request directly to the destination Web site. This is exactly what I would like to accomplish.
The last step is Finishing the New Web Chaining Rule Wizard.
The newly created Web Chaining Rule is placed above the Default Web Chaining rule in the Web Chaining tab. The rules are matched sequentially, so now all traffic matching the configured URL set will be retrieved directly from the internet. All other traffic will be forwarded to the upstream proxy server.
My Internet provider, XS4ALL, offers me the possibility to use a free SIP account. This is especially useful when travelling abroad. I can call to the Netherlands with the SIP accounts. This saves me a lot of money compared to calling with my regular cell phone.
I often hard reset my phone, so all settings will be gone. Sometimes I forget to backup my phone first before giving it a hard reset. After resetting the phone to its factory default settings, I always struggle with configuring the SIP account again. So here is the manual……finally:
Now you have, besides making a voice or video call, the opportunity to make an Internet call.