Question: Why do the translated addresses seem not to exist (I can’t even ping them) even though the Address Translation configuration is correct?
You must modify the gateway’s internal routing tables to enable this to happen.
(enable_overlapping_nat:type (boolean):defvalue (false)) set to true : (overlap_nat_src_ipaddr:type (ip_address_or_empty)) the invalid overlapping network address)
: (overlap_nat_dst_ipaddr:type (ip_address_or_empty)) the valid (legal) network address)
: (overlap_nat_netmask:type (net_mask)) netmask of the overlapping net
parameter value
enable_overlapping_nat true
overlap_nat_src_ipaddr The overlapping IP addresses (before NAT). In the example configuration, this would be 10.0.0.0 for both interfaces.
overlap_nat_dst_ipaddr The IP addresses after NAT. In the example
configuration, this would be 11.0.0.0 for interface 1, and 12.0.0.0 for interface 2.
overlap_nat_netmask The net mask of the overlapping IP addresses (before NAT).
Note - VPN-1/FireWall-1 will drop packets from an internal networks whose source IP addresses (before overlapping NAT) does not belong to the network specifed for overlap_nat_src_ipaddr.
Overlapping NAT
Suppose the Address Translation is configured as follows:
If you ping 192.168.145.11 (whether from outside your network or from inside it), then the gateway routes the ping request to its external interface and it is never received by 192.168.145.11. This is because the internal routing takes place before the Address Translation.
In order to be able to ping 192.168.145.11 and 192.168.145.12, you must add static routes in the gateway which tell it to forward packets destined for 192.168.145.11 and 192.168.145.12 to the internal interface.
For additional information, see “Configuring Routing on the Gateway” on page 78.
Question: Can I translate the gateway’s internal address?
You should not translate the internal address (the address of the internal interface) of the translating gateway.
For example, consider the following network and Address Translation configuration:
No. From Original Address (Port) To Original Address (Port) Method First Translated Address (Port) 0 206.73.224.1 206.73.224.1 FWXT_SRC_STATIC 192.168.145.11 1 192.168.145.11 192.168.145.11 FWXT_DST_STATIC 206.73.224.1 2 206.73.224.85 206.73.224.85 FWXT_SRC_STATIC 192.168.145.12 3 192.168.145.12 192.168.145.12 FWXT_DST_STATIC 206.73.224.85
Note - This section describes anomalies which must be considered when you define Address Translation manually. If you generate Address Translation rules automatically, these considerations do not apply.
Frequently Asked Questions
FIGURE 2-40Hidden Internal Network
This example shows a simple translation scheme that hides the entire internal network, whose addresses are invalid, behind a valid address. The problem with this configuration is that the VPN/FireWall Module’s internal address (10.0.0.8) is also translated to the gateway’s external address, since 10.0.0.8 is in the range 10.0.0.0 – 10.255.255.255. An attempt to communicate from the gateway to an internal machine will not succeed. For example, if you TELNET from the gateway to 10.0.0.1, the gateway’s internal address (10.0.0.8) will be translated to 199.100.73.200. The reply packet will not reach its destination, because 10.0.0.1 will not be able to route the reply to 199.100.73.200. To solve this problem, use the following address translation scheme, which translates all the addresses except the gateway’s address:
Question: How can I use Encryption and Address Translation together on the same system? No. From Original Address (Port) To Original
Address (Port) Method
First Translated Address (Port) 0 10.0.0.1 10.255.255.255 FWXT_HIDE 199.100.73.200 No. From Original Address (Port) To Original
Address (Port) Method
First Translated Address (Port) 0 10.0.0.1 10.0.0.7 FWXT_HIDE 199.100.73.200 1 10.0.0.9 10.255.255.255 FWXT_HIDE 199.100.73.200 client 10.0.0.1 FireWalled Gateway le0 le1 10.0.0.8 199.100.73.241 internal network (invalid) 10.0.0.0 (netmask 255.0.0.0) Internet
Note - You do not have to do anything to ensure that Encryption is performed correctly for those objects for which you generate NAT rules automatically. This section describes anomalies which must be considered when you define NAT rules manually.
Overlapping NAT
For example, suppose you want to encrypt between Network-A and Network-B, where Network-A uses invalid addresses translated as follows:
Network-B uses the valid addresses of network 195.8.5.0.
FireWall-A (Network-A’s FireWall) should specify as its Encryption Domain both the invalid addresses (10.1.1.x) and the valid addresses (192.91.18.x).
FireWall-B (Network-B’s FireWall) knows FireWall-A only by its valid address.
Encryption Rules
On FireWall-A, two Encryption rules are needed:
As with all Address Translation, the VPN/FireWall Module see the packets as the originator of the connection sees it, so the first rule applies to outgoing connections and the second rule applies to incoming connections.
Two Encryption rules are needed on FireWall-B as well:
No. From Original Address (Port) To Original Address (Port) Method First Translated Address (Port) 0 10.1.1.2 10.1.1.2 FWXT_SRC_STATIC 192.91.18.2 1 192.91.18.2 192.91.18.2 FWXT_DST_STATIC 10.1.1.2 2 10.1.1.3 10.1.1.255 FWXT_HIDE 192.91.18.3
Source Destination Services Action Track Install On
10.1.1.0 195.8.5.0 Any Encrypt Log Gateways
195.8.5.0 192.91.18.0 Any Encrypt Log Gateways
Source Destination Services Action Track Install On
192.91.18.0 195.8.5.0 Any Encrypt Log Gateways
Frequently Asked Questions
Here too the first rule applies to outgoing connections and the second rule applies to incoming connections, but the same addresses are used in both rules, since FireWall-B doesn’t know about Network-A’s invalid addresses.
The sequence of actions between Network-A and Network-B is as follows (for a connection from Network-A to Network-B):
1 The packet’s source IP address is translated by FireWall-A.
2 The packet is encrypted and encapsulated by FireWall-A.
The outer IP header contains the gateways’ IP addresses and the inner header contains the translated IP addresses.
3 The packet is decrypted by FireWall-B.
4 The return packet is encrypted by FireWall-B.
5 The return packet is decrypted by FireWall-A.
6 The return packet’s destination IP address is translated by FireWall-A.
Question: What happens when an internal host with an invalid internal IP address tries to communicate with an external host that has the same IP address?
In this case, the internal network does not conform to the IANA recommendations (see “Frequently Asked Questions” on page 116) but instead uses IP addresses that “belong” to another network.
Consider what happens when the internal host 129.1.1.1 in FIGURE 2-41 tries to talk to the external host 129.1.1.1.
FIGURE 2-41Invalid IP Addresses
Note - When using an encryption scheme of type Tunnel Mode, it is usually not necessary to use NAT, because the packet’s original IP header is replaced by an IP header in which the source IP address is that of the gateway’s external interface and the destination IP address is that of the peer gateway’s external interface.
128.1.1.1 router Gateway Internet localnet Public Private 129.1.1.1
Overlapping NAT
The outbound packet will remain in the host, since it looks like this:
The host will route the packet right back to itself, and the packet will never reach the gateway.
If the internal host 128.1.1.1 tries to talk to the external host 129.1.1.1, the gateway will route the communication to the internal host 129.1.1.1 (connected to the gateway through another interface) rather than to the external host 129.1.1.1.
Using FWXT_HIDE to hide the invalid IP addresses behind the gateway’s valid address will not help, because with FWXT_HIDE the Address Translation takes place on the gateway’s external interface. The packet will not get that far because it will have been routed to the other internal interface.
Source IP Address Destination IP address
C H A P T E R