It's pretty obvious from looking through the number of 404s I'm seeing in Google's Webmaster tools that a lot of pages still link to old stuff I wrote about Check Point FireWall-1. I'm actually trying to "fix" these 404s now by resurrecting some of the old content.  Not updating it, of course, but at least making the links point to something semi-useful, if historical.

This is one of those articles, obviously not at it's original URL, but the original URLs will point here. What amazes me about this particular article is that it's still relevant today as NAT really hasn't fundamentally changed in the Check Point products for some time. The basic concepts are still the same, too, and other than the implementation details, is probably relevant for other security products, too. 

Bottom line: NAT only works if the firewall is in the path of the communication. How do you know? Follow the bouncing packet, otherwise known as Troubleshooting 101. 

Hit the break to see this old FAQ in all its ASCII network mapped glory.

When implementing address translation, the unspoken assumption is the firewall will always be between the two machines talking to each other. For external machines accessing internal machines, this is a safe assumption. In the case where internal hosts are accessing internal hosts, this is not always the case.

Another important thing to note is that NAT rules are processed in the order they are listed. Once a packet matches a rule in the rulebase, subsequent rules are not processed for that packet. NAT rules are not applied cumulatively.

To demonstrate these principles in action, here is an example network:

Internet Segment (204.32.38.x)
-------------------------------- (204.32.38.1)
                                   FireWall
                                  (10.0.0.1)
                                       |
                                       |
                                (10.0.255.254)
                                    Router
                         (10.1.0.1)        (10.3.0.1)
                             |                  |
       Segment A (10.1.x.x)  |                  | Segment B (10.3.x.x)
                             |                  | 

The firewall has two interfaces: 204.32.38.1 and 10.0.0.1. The router has three interfaces: 10.0.255.254, 10.1.0.1, and 10.3.0.1. Each interface of the router has a class B netmask (255.255.0.0).

Let's assume an "Externally" accessible SMTP server is at 10.1.2.25 and it has an external address of 204.32.38.25 (via NAT). There is some other internal SMTP server (10.3.4.25) that tries to access the "external" SMTP server via the external address. Assume the following NAT rules:

  Original Translated
No Source Destination Service Source Destination Service
1 Any 204.32.38.25 Any Orig 10.1.2.25(S) Orig
2 10.x.x.x Any Any 204.32.38.1(H) Orig Orig

10.3.4.25 tries to initate a connection to 204.32.38.25. Routing will eventually take this packet to the firewall. The packet is accepted by the firewall's security policy and is then processed by NAT. The first rule that matches is rule 1, which translates the destination of the packet from 204.32.38.25 to 10.1.2.25. The "source" of the packet is not changed (rule 1 says not to touch it). The packet will then be routed to 10.0.255.254, then 10.1.2.25.

When 10.1.2.25 sends its "reply," it will be sent to 10.3.4.25 (the "source" of the connection attempt). The reply is routed to 10.1.0.1 and then directly to 10.3.4.25. 10.3.4.25 is expecting replies from 204.32.38.25 (who it thinks it tried to connect to), not 10.1.2.25, so they are dropped (as they should be). If a machine on 10.1.x.x were to access 204.32.38.25, the same thing would happen except the packet would travel one less hop.

What would happen if the rules were reversed (i.e. rule 2 was listed before rule 1)? When 10.3.4.25 tries to access 204.32.38.25, the packet gets routed to the firewall and passes through the rulebase. NAT then would rewrite the source of the packet to be 204.32.38.25. The destination of the packet would still be 204.32.38.25 (i.e. it does not get translated), but gets routed out the internal interface (or at least it should if you've configured NAT correctly. ;-). The internet router sees this packet and routes it back to the firewall (it's an external address, after all). The packet would ping pong back and forth until the TTL expires.

One reason why you might connect to the translated IP address is because your internal client's DNS server points to it. You can resolve this problem by implementing split-horizon DNS, i.e. different DNS servers for the internal and external networks. An internal DNS server reflects the internal IP address for a host and the external DNS server reflects the externally resolvable IP addresses for the host. Internal clients will use the internal DNS server. You can also put a host entry on the local system pointing at the internal address.

Other than implementing split-horizon DNS, can you get around this problem? There are two methods you can use to get around this problem, which I have documented below.

Put Externally Accessible Hosts on a DMZ

This actually makes more sense from a security standpoint because you can provide more control over access if externally accessible host are all on their own segment. To create a DMZ, you would have to add a third interface to your firewall with a different logical subnet and move the accessible hosts to that subnet.

Internet Segment (204.32.38.x)
-------------------------------- (204.32.38.1)          DMZ segment (172.31.0.x)
                                   FireWall (172.31.0.0)------------------------
                                  (10.0.0.1)
                                       |
                                       |
                                (10.0.255.254)
                                    Router
                         (10.1.0.1)        (10.3.0.1)
                             |                  |
       Segment A (10.1.x.x)  |                  | Segment B (10.3.x.x)
                             |                  | 

This puts the firewall between the client and the server, thus solving the NAT problem.

The Dual-NAT Trick

The success or failure of this trick is dependent on the OS that you use for your firewall and may even depend on the environment. In most cases, it does not work. When a packet is received in one interface and is routed out that same interface, the OS's TCP/IP stack will instead issue an ICMP Redirect with the system's untranslated IP address. Depending on the circumstances, this connection may either never take place or take a long time to establish. FireWall-1 can't do anything about this. Assuming my trick does work for you, you are effectively doubling the amount of traffic that the connection would generate and add additional, unnecessary load to the firewall. The best way to resolve this problem is to simply not use the translated IP address in the internal network.

In order to insure that the firewall stays between the connection between the two hosts, you will need to create dual NAT rule. The NAT rule will look at both the source and destination of the packet and translate both the source and the destination of the packet. Because the rules are processed in order, the dual NAT rule must come before both your "HIDE" rule and your SMTP server's translation rule as below:

  Original Translated
No. Source Destination Service Source Destination Service
1 10.x.x.x 204.32.38.25 Any 10.0.0.1(H) 10.1.2.25(S) Orig
2 Any 204.32.38.25 Any Orig 10.1.2.25(S) Orig
3 10.x.x.x Any Any 204.32.38.1(H) Orig Orig

What will this do?

  • All traffic coming from 10.x.x.x that is destined for 204.32.38.25 will get hidden behind 10.0.0.1 (the internal IP address of the firewall) and have a destination of 10.1.2.25.
  • All other traffic coming to 204.32.38.25 will keep the original source and have a destination of 10.1.2.25.
  • All other traffic coming from 10.x.x.x will get hidden behind 204.32.38.1 (the external IP of the firewall) and keep the original destination.

The side effect of this is that for each connection to your "internal" SMTP server using the external IP address, you will see the network connection traverse your internal network twice:

  1. Once between the "server" and the FireWall
  2. Once between the firewall and the "client"

If you have done this and you still can not access the host in question, use a packet sniffer to determine what is going on. In cases where it will not work, the firewall system will send an ICMP redirect to the client pointing them to the internal host using the untranslated address. Since the client is not expecting to see the host's real IP address, the connection will fail. In this case, you will need to disable ICMP redirects on your host system. The only system I know how to do this on is Solaris, and the command is as follows:

   /usr/sbin/ndd -set /dev/ip ip_send_redirects 0

On IPSO, this is done at a per-interface level. If VRRP is running on a particular interface, this is the default behaviour. If you are not running VRRP on a particular interface, then issue the following command if the interface you wish to enable it on is eth-s3p1c0 (add it to /var/etc/rc.local if you wish for this command to be active after a reboot):

   ipsctl -w interface:eth-s3p1c0:family:inet:flags:icmp_no_rdir 1

On NT, you can disable ICMP Redirects with NT Service Pack 5 and later by adding or modifying the following registry entry:

   HKEY_LOCAL_MACHINESystemCurrentControlSetServicesTcpipParametersEnableICMPRedirects

This key should be a DWORD set to 0.

If you know how to do this on other platforms, please contact me so I can update the page.

Optionally, you can also block ICMP Redirects at the firewall:

No. Source Destination Service Action Track Install-On
1 Firewall any icmp-redirect drop   Source

Binding the NATted IP address to the Loopback Interface

The basic idea is to bind the translated IP address to the loopback interface of the server. On Unix machines, you use a command like

   ifconfig lo0:0 204.32.38.25 up

On NT, you will need to add the MS Loopback interface (which you will need to add to the system) and add the IP address to this interface with a netmask of 255.255.255.255. If packets come into the system for the translated IP address (because, for instance, they did not come to the firewall), the system will respond to packets for this IP address. This method does require slightly more administration since now you must also maintain the NAT on the individual servers as well.

From PhoneBoy Speaks Ep 305: Threat? What Threat?

In sealed court documents accidentally leaked on a US Federal government website, the US government basically admits that there has been no attempted domestic hijackings of any kind in the 12 years since 9/11. Furthermore, at least as of mid-2011, terrorist threat groups present in the Homeland are not known to be actively plotting against civil aviation targets or airports.

It gets better. Jonathan Corbett, the guy who has been challenging the feds on the constitutionality and the effectiveness of the TSA in the courts, was told by the US Justice Department to take down his comments about a sealed document he wasn't allowed to talk about, but the government themselves posted the unredacted version on their site and other sites made it public.

The same is true for Corbett's comments about those documents, the Justice Department asked him to remove from his site, but they apparently forgot to tell Google as it was still in their cache!

This is a clear demonstration of what can happen if confidential data inadvertently leaves your organization. Clearly this unredacted, sealed legal brief should have never been made public. Thankfully, in this case, it was, but surely some folks in the US Government weren't happy with this lapse. Neither would your employer if it's your company's secret plans for world domination that got leaked.

Likewise, if you inadvertently leak information on your own website, or someone else does, even if you can manage to get it taken down, Google takes a while to forget it saw it. The rest of the Internet won't necessarily forget, though. Ever.

So what are your plans for Data Loss Prevention in your organization? Are you even employing any DLP technology? Is it actually catching real incidents of data loss or is everyone going around it? 

I'm not saying DLP is a panacea or 100% effective, but if you're not doing it, then you don't have any idea where your corporate information might end up. 

Sample Link Post

This theme supports link posts, made famous by John Gruber. To use, just add

1
link: http://url-you-want-linked
to the post’s YAML front matter and you’re done.

If you ran Check Point FireWall-1 on SunOS or Solaris, you probably remember this screen:

This is a screen capture from fwui, the management interface for FireWall-1. Actually FireWall-1 2.0 and 2.1 looked like this too.

Meanwhile if you ran the management interface on Windows, you were presented with something like this:

You could actually run the firewall on Windows NT as of 2.1, though it took until 2.1c until it was reasonably stable.

Actually you could run something that looked like the Windows UI on Solaris with Motif, which Check Point charged extra for. Eventually the Motif and the OpenLook GUI were deprecated and what we now refer to as SmartDashboad only runs on Windows.

And, of course, there are far more GUI clients these days–about a dozen or so if I remember correctly. But then again, the product does so much more today than it did back in the mid 1990s.

And yes, I remember those days quiet fondly.

For those of you who never had to work with Check Point FireWall-1 4.1 and earlier, you're lucky you likely never EVER had to use putkeys.

The fw putkey was used to establish authentication between the Management and Firewall modules. The problem was: the authentication would frequently break. Especially in larger, distributed environments. Often for reasons that no one outside of a few developers in Tel Aviv never fully understood.

The eventual replacement for fw putkey was SIC, which was added in FireWall-1 NG (5.0). It is based on certificates and is way easier to set up. It's also far less prone to random breakage. 

The following classic article is presented for nostalgia purposes only. Hopefully no one in their right mind still needs this article, which was very popular on my FireWall-1 FAQ back in the day. It was the collective wisdom of my peers and my own experience as of around 2000 or so.

Can't Get Putkeys to Work

Q:

I can't get my putkeys to work ir I can't keep them working. What am I
doing
wrong?

A:

One thing that I've always done on habit with my firewall systems is to

make sure all IPs on both the management and firewall are resolvable to
a
hostname within the system's local host file and that the systems are
configured
to look at the local hosts file before looking to DNS. As a
result, the
number of issues I personally have had with putkeys in any
systems I have
personally set up have been minimal. I would suggest doing
this before redoing
all your putkeys. Also, double-check to make sure the time on your management
console and firewall module have their time synchronized (relative to GMT).

One known issue: If you are using skey authentication on versions of
FireWall-1
prior to 4.0 SP5, there is an issue whereby the authentication
can get out
of sync. Either use fwn1 (which works on systems 4.0 SP4 and
earlier) or
use none authentication. For more information, see: Failed

to Install Security Policy on fw62bs01: Unauthorized action.

If you have to redo your putkeys, there are three methods one can use

to do putkeys, one of which usually works:

Putkey with all IPs

A trick I have found that works is to use all possible IP addresses in
a
putkey command. For example, if my management console had only one IP
(172.31.0.42)
and my firewall had several IPs:

le0: 153.1.214.10
qe0: 192.168.0.10
qe1: 172.16.0.10
qe2: 10.0.0.10

My putkey from the management console to the firewall would look like

this:

fw putkey 153.1.214.10 192.168.0.10 172.16.0.10 10.0.0.10

And my putkey from the firewall to the management console would be:

fw putkey 172.31.0.42

In a step-by-step manner, here is what you would do:

  1. fwstop both the management and firewall modules
  2.  

  3. On the FireWall, type: fw putkey 172.31.0.42
  4.  

  5. On the management console, type: fw putkey 153.1.214.10 192.168.0.10

    172.16.0.10 10.0.0.10

  6. fwstart the management console
  7.  

  8. fwstart the firewall module

Forcing the nodename IP

When performing the authentication necessary for remote management, FireWall-1

will attempt to use the 'nodename IP' to communicate between the systems.

If the nodename IP does not exist or is not reachable from all systems,
this
causes putkeys to not work. A way to get around this problem is to
use putkey
in the following manner:

fw putkey -n local-ip remote-ip

The "local ip" here depends on which interface you will need to talk
out
to see the remote system. The "remote ip" will be the IP address that
is
closest to you.

For instance, if your firewall had the following interfaces:

le0: 153.1.214.10
qe0: 192.168.0.10
qe1: 172.16.0.10
qe2: 10.0.0.10

And your management console had the following interfaces:

le0: 172.16.10.42

On the firewall console, you would type:

fw putkey -n 172.16.0.10 172.16.10.42

On the management console, you would type:

fw putkey -n 172.16.10.42 172.16.0.10

In a step-by-step manner, here is what you would do:

  1. fwstop both the management and firewall modules
  2. On the FireWall, type: fw putkey -n 172.16.0.10 172.16.10.42
  3. On the management console, type: fw putkey -n 172.16.10.42 172.16.0.10
  4. fwstart the management console
  5. fwstart the firewall module

Touching all putkey-related files

Karim Ismail makes the following

suggestion: Simply "touch" the following files (i.e. use the Unix/IPSO
"touch"
command) before performing the putkey command:

$FWDIR/conf/fwauth.keys

$FWDIR/conf/serverkeys.*

$FWDIR/database/authkeys.C

$FWDIR/database/opsec_authkeys.C

The control.map file

Sometimes, you will need to add IP addresses to $FWDIR/lib/control.map
because,
for whatever reason, FireWall-1 is not seeing the IP address it
is hearing
the connection from as the appropriate type of host (either
as a remote
firewall module or a management console). In any case, you
can insure that
FireWall-1 is handling this correctly by editing $FWDIR/lib/control.map.

Add all the IPs of the remote hosts you wish to authenticate with

in a new line (above the MASTERS, CLIENT, and * lines) and force the authentication

that will be used for these IPs to the appropriate authentication scheme

(fwn1, fwa1, skey).

a.b.c.d, e.f.g.h : */fwa1
MASTERS :stat,getkey,gettopo/none opsec/fwn1 */fwa1
CLIENT  :load,db_download,fetch,log/fwa1   opsec/fwn1

*/none
*       :stat,getkey,gettopo/none
unload,ioctl,load,db_download/deny
opsec/fwn1 */fwa1

If you edit this file, stop and start FireWall-1. For more information 
on control.map, see: Failed to Install Security Policy
on fw62bs01: Unauthorized action

Flushing All Putkey-Related Files

There are some cases where even this does not work. Here is a procedure

developed by Lance Spitzner (which

I have slightly modified):

On the Management Module

  •  fwstop
  •  Backup the following files by copying them to <filename>.old
    • $FWDIR/database/authkeys.C
    • $FWDIR/database/opsec_authkeys.C
    • $FWDIR/conf/fwauth.keys
    • $FWDIR/conf/serverkeys.*
  • Remove the above files
  • Confirm that $FWDIR/lib/control.map is using the same authentication
    as
    the remote modules (fwa1 or skey).
  • Make sure /etc/hosts has an entry for the remote module(s).

On the Remote Module

  • fwstop
  • Backup the following files by copying them to <filename>.old
    • $FWDIR/database/authkeys.C
    • $FWDIR/database/opsec_authkeys.C
    • $FWDIR/conf/fwauth.keys
    • $FWDIR/conf/serverkeys.*
  • Remove the above files
  • Confirm that $FWDIR/lib/control.map is using the same authentication
    as
    the management module (fwa1 or skey).
  • Make sure /etc/hosts has an entry for the management module.

On the Management Module: fw putkey -p <password> -n <local IP>
<remote
IP>

On the Remote Module: fw putkey -p <password> -n <local IP>
<remote
IP>

On the Mangement Module: fwstart

On the Remote Module: fwstart

That's it!  If that did not do the trick, ensure all Network Objects

in Rule Base match /etc/hosts file and fw putkey IP addresses.  Repeat

steps above.

If you don't want to fwstop the firewall modules

I personally have had success sometimes simply killing and restarting fwd,

which is not as drastic as restarting FireWall-1, but can make certain
services
unavailable. However, Bradley

Filmer says this method does not require fwstopping the firewall module.

On the firewall module, edit $FWDIR/database/authkeys.C and remove everything

between the opening parenthesis "(" and the closing parenthesis ")". Redo

the putkeys using one of the methods above (he suggests using the -n method,

but only use that method if you have to). On the management console, do
the
same thing except perform an fwstop and fwstart afterwords.

As a Last Resort

Sometimes, you will need to reboot either the management console, firewall

module, or both to make putkeys work. Don't necessarily have an explanation

for it. If you reboot one but not the other, execute an fwstop; fwstart
on
the other box.

Even after that, it may not work either. What you can do is disable
putkey
authentication entirely. Note that this is not entirely recommended
in all
cases, but if you need to get it working quickly, this trick will
definately
work. Edit control.map as above on all involved systems and
use "none" as
the authentication scheme. Stop and start FireWall-1. You
will no longer
have any more troubles with putkeys between these systems
as you have effectively
reduced the authentication to IP only.