Network Mapping

Tom Eastep

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover, and with no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License.


Why use Network Mapping

Network Mapping is most often used to resolve IP address conflicts. Suppose that two organizations, A and B, need to be linked and that both organizations have allocated the subnetwork. There is a need to connect the two networks so that all systems in A can access the network in B and vice versa without any re-addressing.


Shorewall NETMAP support is designed to supply a solution. The basic situation is as shown in the following diagram.

While the link between the two firewalls is shown here as a VPN, it could be any type of interconnection that allows routing of RFC 1918 traffic.

The systems in the top cloud will access the subnet in the lower cloud using addresses in another unused /24. Similarly, the systems in the bottom cloud will access the subnet in the upper cloud using a second unused /24.

In order to apply this solution:

  • You must be running Shorewall 2.0.1 Beta 2 or later.

  • Your kernel must have NETMAP support. 2.6 Kernels have NETMAP support without patching while 2.4 kernels must be patched using Patch-O-Matic from

  • NETMAP support must be enabled in your kernel (CONFIG_IP_NF_TARGET_NETMAP=m or CONFIG_IP_NF_TARGET_NETMAP=y).

  • Your iptables must have NETMAP support. NETMAP support is available in iptables 1.2.9 and later.

Network mapping is defined using the /etc/shorewall/netmap file. Columns in this file are:


Must be DNAT or SNAT.

If DNAT, traffic entering INTERFACE and addressed to NET1 has its destination address rewritten to the corresponding address in NET2.

If SNAT, traffic leaving INTERFACE with a source address in NET1 has its source address rewritten to the corresponding address in NET2.


Must be expressed in CIDR format (e.g., Beginning with Shorewall 4.4.24, exclusion is supported.


A firewall interface. This interface must have been defined in /etc/shorewall/interfaces.


A second network expressed in CIDR format.

NET3 (Optional) - network-address

Added in Shorewall 4.4.11. If specified, qualifies INTERFACE. It specifies a SOURCE network for DNAT rules and a DESTINATON network for SNAT rules.

PROTO (Optional - Added in Shorewall - protocol-number-or-name

Only packets specifying this protocol will have their IP header modified.

DPORT (Optional - Added in Shorewall - port-number-or-name-list

Destination Ports. A comma-separated list of Port names (from services(5)), port numbers or port ranges; if the protocol is icmp, this column is interpreted as the destination icmp-type(s). ICMP types may be specified as a numeric type, a numberic type and code separated by a slash (e.g., 3/4), or a typename. See

If the protocol is ipp2p, this column is interpreted as an ipp2p option without the leading "--" (example bit for bit-torrent). If no PORT is given, ipp2p is assumed.

An entry in this field requires that the PROTO column specify icmp (1), tcp (6), udp (17), sctp (132) or udplite (136). Use '-' if any of the following field is supplied.

SPORT (Optional - Added in Shorewall - port-number-or-name-list

Source port(s). If omitted, any source port is acceptable. Specified as a comma-separated list of port names, port numbers or port ranges.

An entry in this field requires that the PROTO column specify tcp (6), udp (17), sctp (132) or udplite (136). Use '-' if any of the following fields is supplied.

Referring to the figure above, lets suppose that systems in the top cloud are going to access the network in the bottom cloud using addresses in and that systems in the bottom could will access in the top could using addresses in


You must arrange for routing as follows:

  • Traffic from the top cloud to must be routed to eth0 on firewall 1.

  • Firewall 1 must route traffic to through firewall 2.

  • Traffic from the bottom cloud to must be routed to eth0 on firewall 2.

  • Firewall 2 must route traffic to through firewall 1.

If you are running Shorewall 4.4.22 or Earlier

The entries in /etc/shorewall/netmap in firewall1 would be as follows:

#TYPE NET1           INTERFACE        NET2
SNAT vpn            #RULE 1A
DNAT  vpn           #RULE 1B

The entry in /etc/shorewall/netmap in firewall2 would be:

#TYPE NET1           INTERFACE        NET2
DNAT  vpn           #RULE 2A
SNAT vpn            #RULE 2B

Example 1. in the top cloud connects to in the bottom cloud

In order to make this connection, the client attempts a connection to The following table shows how the source and destination IP addresses are modified as requests are sent and replies are returned. The RULE column refers to the above /etc/shorewall/netmap entries and gives the rule which transforms the source and destination IP addresses to those shown on the next line.

FROMTOSOURCE IP ADDRESSDESTINATION IP ADDRESSRULE in upper cloudFirewall 1192.168.1.410.10.10.271A
Firewall 1Firewall
Firewall 2192.168.1.27 in lower cloud10.10.11.4192.168.1.27 in the lower cloudFirewall 2192.168.1.2710.10.11.42B
Firewall 2Firewall
Firewall 1192.168.1.4 in upper cloud10.10.10.27192.168.1.4 

See the OpenVPN documentation for a solution contributed by Nicola Moretti for resolving duplicate networks in a roadwarrior VPN environment.

If you are running Shorewall 4.4.23 or Later

Beginning with Shorewall 4.4.23, you can bridge two duplicate networks with one router, provided that your kernel and iptables include Rawpost Table Support. That support is used to implement Stateless NAT which allows for performing DNAT in the rawpost table POSTROUTING and OUTPUT chains and for performing SNAT in the raw table PREROUTING chain. Using this support, only firewall1 requires /etc/shorewall/netmap. Two additional entries are added.

#TYPE NET1            INTERFACE        NET2
SNAT vpn    
DNAT  vpn    
SNAT:P vpn    
DNAT:T  vpn    

The last two entries define Stateless NAT by specifying a chain designator (:P for PREROUTING and :T for POSTROUTING respectively). See shorewall-netmap (5) for details.


Beginning with Shorewall6 4.4.24, IPv6 support for Netmap is included. This provides a way to use private IPv6 addresses internally and still have access to the IPv6 internet.


IPv6 netmap is stateless which means that there are no Netfilter helpers for applications that need them. As a consequence, applications that require a helper (FTP, IRC, etc.) may experience issues.

For IPv6, the chain designator (:P for PREROUTING or :T for POSTROUTING) is required in the TYPE column. Normally SNAT rules are placed in the POSTROUTING chain while DNAT rules are placed in PREROUTING.

To use IPv6 Netmap, your kernel and iptables must include Rawpost Table Support.

IPv6 Netmap has been verified at using the configuration shown below.

IPv6 support is supplied from Hurricane Electric; the IPv6 address block is 2001:470:b:227::/64.

Because of the limitations of IPv6 NETMAP (no Netfilter helpers), the servers in the DMZ have public addresses in the block 2001:470:b:227::/112. The local LAN uses the private network fd00:470:b:227::/64 with the hosts autoconfigured using radvd. This block is allocated from the range (fc00::/7) reserved for Unique Local Addresses.

The /etc/shorewall6/netmap file is as follows:

#												PORT(S)	PORT(S)
SNAT:T	fd00:470:b:227::/64	HE_IF		2001:470:b:227::/64
DNAT:P  2001:470:b:227::/64!2001:470:b:227::/112\
				HE_IF		fd00:470:b:227::/64

HE_IF is the logical name for interface sit1. On output, the private address block is mapped to the public block. Because autoconfiguration is used, none of the local addresses falls into the range fd00:470:b:227::/112. That range can therefore be excluded from DNAT.


While the site local network that was used is very similar to the public network (only the first word is different), that isn't a requirement. We could have just as well used fd00:bad:dead:beef::/64


The MacBook Pro running OS X Lion refused to autoconfigure when radvd advertised a site-local network (fec0:470:b:227/64) but worked fine with the unique-local network (fd00:470:b:227::/64). Note that site-local addresses were deprecated in RFC3879.


This whole scheme isn't quite as useful as it might appear. Many IPv6-enabled applications (web browsers, for example) are smart enough to recognize unique local addresses and will only use IPv6 to communicate with other such local addresses.


Frequently Used Articles

- FAQs - Manpages - Configuration File Basics - Beginner Documentation - Troubleshooting

Shorewall 4.4/4.5/4.6 Documentation

Shorewall 4.0/4.2 Documentation

Shorewall 5.0/5.1/5.2 HOWTOs and Other Articles

- 6to4 and 6in4 Tunnels - Accounting - Actions - Aliased (virtual) Interfaces (e.g., eth0:0) - Anatomy of Shorewall - Anti-Spoofing Measures - AUDIT Target support - Bandwidth Control - Blacklisting/Whitelisting - Bridge/Firewall - Building Shorewall from GIT - Commands - Compiled Programs - Configuration File Basics - DHCP - DNAT - Docker - Dynamic Zones - ECN Disabling by host or subnet - Events - Extension Scripts - Fallback/Uninstall - FAQs - Features - Fool's Firewall - Forwarding Traffic on the Same Interface - FTP and Shorewall - Helpers/Helper Modules - Installation/Upgrade - IPP2P - IPSEC - Ipsets - IPv6 Support - ISO 3661 Country Codes - Kazaa Filtering - Kernel Configuration - KVM (Kernel-mode Virtual Machine) - Limiting Connection Rates - Linux Containers (LXC) - Linux-vserver - Logging - Macros - MAC Verification - Manpages - Manual Chains - Masquerading - Multiple Internet Connections from a Single Firewall - Multiple Zones Through One Interface - My Shorewall Configuration - Netfilter Overview - Network Mapping - No firewalling of traffic between bridge port - One-to-one NAT - Operating Shorewall - OpenVPN - OpenVZ - Packet Marking - Packet Processing in a Shorewall-based Firewall - 'Ping' Management - Port Forwarding - Port Information - Port Knocking (deprecated) - Port Knocking, Auto Blacklisting and Other Uses of the 'Recent Match' - PPTP - Proxy ARP - QuickStart Guides - Release Model - Requirements - Routing and Shorewall - Routing on One Interface - Samba - Shared Shorewall/Shorewall6 Configuration - Shorewall Events - Shorewall Init - Shorewall Lite - Shorewall on a Laptop - Shorewall Perl - Shorewall Setup Guide - SMB - SNAT - Split DNS the Easy Way - Squid with Shorewall - Starting/stopping the Firewall - Static (one-to-one) NAT - Support - Tips and Hints - Traffic Shaping/QOS - Simple - Traffic Shaping/QOS - Complex - Transparent Proxy - UPnP - Upgrade Issues - Upgrading to Shorewall 4.4 (Upgrading Debian Lenny to Squeeze) - VPN - VPN Passthrough - White List Creation - Xen - Shorewall in a Bridged Xen DomU - Xen - Shorewall in Routed Xen Dom0

Top of Page