Booches.nl

McAfee Firewall – NAT mapping

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:

1. 1. NAT: mostly used to translate a private IP address to a public IP address;
2. 2. Redirect: redirect traffic to a public IP address to a private IP address;

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:

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.

• Was somebody already using the public IP address in a NAT configuration?
• Has the default gateway of the internet segment already an ARP entry for the public IP address?

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……

eSafe Proxy with NTLM v2.0

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:

1. 1. Open the Group Policy Editor with gpedit.msc;
2. 2. Go to Computer Configuration – Windows Settings – Security Settings – Local Policies – Security Options;
3. 3. Go to the setting: Network security: LAN Manager authentication level
4. 4. Change this setting to: Send LM & NTLM – use NTLMv2 session security if negotiated
5. 5. Apply the policy with gpupdate /force

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 2006 Web Chaining

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:

1. Retrieve directly from the destination / internet;
2. Forward to an upstream proxy server;
3. Redirect the request to a specific server / web page;

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.

Nokia E71, XS4ALL and SIP

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:

1. Go to Menu –> Tools –> Settings –> Connection –> SIP Setting;
2. Create a new account
3. Profile name: XS4ALL
4. Service Profile: IETF
5. Default Access Point: none (I choose the correct access point manually)
6. Public name: <SIP phone number>@sip.xs4all.nl
7. Use compression: No
8. Registration: When needed
9. Use security: No
10. Proxy Server

1. Registrar server

1. Next go to Menu –> Tools –> Settings –> Connection –> Internet telephone
2. Create a new profile
3. Name: XS4ALL
4. SIP profiles: XS4ALL

Now you have, besides making a voice or video call, the opportunity to make an Internet call.

eSafe Gateway 7.1 Forwarding Proxy with squid

My colleague over at PBSPlaza wrote a nice article about enabling squid on eSafe Gateway 7.1 Forwarding Proxy. Today I had to configure an extra step to enable squid. I followed the instructions from my colleague, but when I tried to start squid I received the following error message.

FATAL: Could not determine fully qualified hostname.  Please set ‘visible_hostname’

Squid Cache (Version 2.6.STABLE18): Terminated abnormally.
CPU Usage: 0.030 seconds = 0.000 user + 0.030 sys
Maximum Resident Size: 0 KB
Page faults with physical i/o: 244
Aborted

I added the following line to /opt/eproxy/etc/squid.conf:

visible_hostname mail.booches.nl

Now squid starts perfectly