Connecting the world…


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. NAT: mostly used to translate a private IP address to a public IP address;
  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:

Application: SSH Source Zone:
Destination Zone:
Source Endpoint:
Destination Endpoint:
Public IP address
NAT 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.

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

GNS3 supports JunOS

A lot of you will know GNS3. GNS3 is a graphical network simulator that allows simulation of complex networks. With GNS3 you can simulate multiple Cisco routers and the Cisco PIX firewall. GNS3 allows you to emulate real Cisco IOS images, design and experiment with complex networks, connect the virtual lab to the real world and capture packets with tools like Wireshark. I often use GNS3 to test my designs for customers or use it for training and workshop purposes.

As mentioned before GNS3 only supported some Cisco routers and the Cisco PIX firewall. In GNS3 0.7RC1 the emulation of Junipers JunOS is added. Just like the emulation of the Cisco ASA firewall. This makes GNS3 even more powerful. The preparation of a JunOS image is not as straightforward as an IOS one, but GNS3 wrote this excellent article for emulating a JunOS image.

I recommend GNS3 for everyone how is playing and likes to play with Cisco routers and firewalls, and from now on also Juniper routers.

Barracuda – Mail Protocol Violation

A customer updated the firmware from a Barracuda SPAM &Virus 300 firewall. The firmware was upgraded from version 3.4 to version After the upgrade no email was coming in or going out through the Barracuda firewall.

All email was blocked and the following reason was visible in the message log:

Mail Protocol Violation

At first I couldn’t find a reason why all mail was blocked, so I contacted Barracuda and established a remote connection with Barracuda for remote troubleshooting. (I really like that feature). Finally the engineer found the problem. The Maximum Message Size value under Advanced – Email Protocol – SMTP Configuration was set to:

100000000000000000000000000000000000000 bytes

Yep, you read that correctly. I have no idea where that value came from. So I changed it back to the recommended value of 100 MB. After changing the value, mail started coming in and going out again through the Barracuda.

Secret Barracuda Spam firewall options

While troubleshooting a Barracuda Spam Firewall 300 I found a forum on internet, which shows you how to get an extra tab under the Advanced configuration of the Barracuda Spam Firewall. The “secret” configuration page is enabled with the following steps:

  1. Logon to the Barracude Spam Firewall 300;
  2. Click on the Advanced tab;
  3. Add &expert=1 at the end of the URL and hit enter;

You will now get the extra tab Expert Variables like shown below.


Failed to establish VPN through PIX

We migrated our Internet connection lately and reconfigured our PIX firewall. We added some memory to install the latest firmware version (8.0(4)). After putting the PIX firewall in production some of the employees were complaining they couldn’t establish any PPTP VPN Tunnels anymore to customers.

Every time when some one called me, I tried it myself and I was always able to connect using a PPTP VPN Tunnel, but every time I was working remote and not at the office. So I always thought that something was wrong with there laptops, but today I encountered the problem myself.

Looking at the logging of the PIX firewall, I saw the following error message:

%ASA-3-305006: regular translation creation failed for protocol 47 src inside:<IP address> dst outside:<IP address>

The error message indicates that there is no NAT mapping for the specified traffic, which could direct you in the wrong direction. I checked the NAT mappings to be sure, but as I already thought, this couldn’t be the cause of the problem.

PPTP uses a TCP connection that uses port 1723 and an extension of generic routing encapsulation (GRE) [protocol 47] to carry the actual data (PPP frame). The TCP connection is initiated by the client, followed by the GRE connection that is initiated by the server. Because the PPTP connection is initiated as TCP on one port and the response is GRE protocol, the PIX Adaptive Security Algorithm (ASA) does not know that the traffic flows are related.

The PPTP fixup feature in version 6.3 allows the PPTP traffic to traverse the PIX when configured for PAT. Stateful PPTP packet inspection is also performed in the process. The fixup protocol pptp command inspects PPTP packets and dynamically creates the GRE connections and translations necessary to permit PPTP traffic. Specifically, the firewall inspects the PPTP version announcements and the outgoing call request/response sequence. Only PPTP Version 1, as defined in RFC 2637, is inspected. Further inspection on the TCP control channel is disabled if the version announced by either side is not Version 1. In addition, the outgoing call request and reply sequence is tracked. Connections and/or translations are dynamically allocated as necessary to permit subsequent secondary GRE data traffic. The PPTP fixup feature must be enabled for PPTP traffic to be translated by PAT.

So I had to configure the fixup protocol pptp feature with the following command:

fw01(config)# fixup protocol pptp 1723

As stated before, we are using fireware version 8.0(4). This version doesn’t support the fixup protocol pptp command and the converts the command an inspect pptp command as shown below.

fw01(config)# fixup protocol pptp 1723
INFO: converting ‘fixup protocol pptp 1723’ to MPF commands



policy-map global_policy
class inspection_default
  inspect dns preset_dns_map
  inspect ftp
  inspect pptp