<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Network Mapping</title><link rel="stylesheet" href="html.css" type="text/css" /><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /></head><body><div class="article" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="id257523"></a>Network Mapping</h2></div><div><div class="authorgroup"><div class="author"><h3 class="author"><span class="firstname">Tom</span> <span class="surname">Eastep</span></h3></div></div></div><div><p class="copyright">Copyright © 2004-2005, 2007 Thomas M. Eastep</p></div><div><div class="legalnotice"><a id="id292638"></a><p>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
“<span class="quote"><a class="ulink" href="GnuCopyright.htm" target="_self">GNU Free Documentation
License</a></span>”.</p></div></div><div><p class="pubdate">2008/12/15</p></div></div><hr /></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#Why">Why use Network Mapping</a></span></dt><dt><span class="section"><a href="#Solution">Solution</a></span></dt><dt><span class="section"><a href="#Notes">Author's Notes</a></span></dt><dt><span class="section"><a href="#WhyTwo">Can't I do this with one router? Why do I need two?</a></span></dt></dl></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Why"></a>Why use Network Mapping</h2></div></div></div><p>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 192.168.1.0/24 subnetwork. There is a
need to connect the two networks so that all systems in A can access the
192.168.1.0/24 network in B and vice versa without any
re-addressing.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Solution"></a>Solution</h2></div></div></div><p>Shorewall NETMAP support is designed to supply a solution. The basic
situation is as shown in the following diagram.</p><div><img src="images/netmap.png" /></div><p>While the link between the two firewalls is shown here as a VPN, it
could be any type of interconnection that allows routing of <a class="ulink" href="shorewall_setup_guide.htm#RFC1918" target="_self">RFC 1918</a> traffic.</p><p>The systems in the top cloud will access the 192.168.1.0/24 subnet
in the lower cloud using addresses in another unused /24. Similarly, the
systems in the bottom cloud will access the 192.168.1.0/24 subnet in the
upper cloud using a second unused /24.</p><p>In order to apply this solution:</p><div class="itemizedlist"><ul type="disc"><li><p>You must be running Shorewall 2.0.1 Beta 2 or later.</p></li><li><p>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 <a class="ulink" href="http://www.netfilter.org" target="_self">netfilter.org</a>.</p></li><li><p>NETMAP support must be enabled in your kernel
(CONFIG_IP_NF_TARGET_NETMAP=m or CONFIG_IP_NF_TARGET_NETMAP=y).</p></li><li><p>Your iptables must have NETMAP support. NETMAP support is
available in iptables 1.2.9 and later.</p></li></ul></div><p>Network mapping is defined using the
<code class="filename">/etc/shorewall/netmap</code> file. Columns in this file
are:</p><div class="variablelist"><dl><dt><span class="term">TYPE</span></dt><dd><p>Must be DNAT or SNAT.</p><p>If DNAT, traffic entering INTERFACE and addressed to NET1 has
its destination address rewritten to the corresponding address in
NET2.</p><p>If SNAT, traffic leaving INTERFACE with a source address in
NET1 has its source address rewritten to the corresponding address
in NET2.</p></dd><dt><span class="term">NET1</span></dt><dd><p>Must be expressed in CIDR format (e.g.,
192.168.1.0/24).</p></dd><dt><span class="term">INTERFACE</span></dt><dd><p>A firewall interface. This interface must have been defined in
<a class="ulink" href="manpages/shorewall-interfaces.html" target="_self"><code class="filename">/etc/shorewall/interfaces</code></a>.</p></dd><dt><span class="term">NET2</span></dt><dd><p>A second network expressed in CIDR format.</p></dd></dl></div><p>Referring to the figure above, lets suppose that systems in the top
cloud are going to access the 192.168.1.0/24 network in the bottom cloud
using addresses in 10.10.10.0/24 and that systems in the bottom could will
access 192.168.1.0/24 in the top could using addresses in
10.10.11.0.</p><div class="important" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Important</h3><p>You must arrange for routing as follows:</p><div class="itemizedlist"><ul type="disc"><li><p>Traffic from the top cloud to 10.10.10.0/24 must be routed
to eth0 on firewall 1.</p></li><li><p>Firewall 1 must route traffic to 10.10.10.0/24 through
firewall 2.</p></li><li><p>Traffic from the bottom cloud to 10.10.11.0/24 must be
routed to eth0 on firewall 2.</p></li><li><p>Firewall 2 must route traffic to 10.10.11.0/24 through
firewall 1.</p></li></ul></div></div><p> The entries in
<code class="filename"><code class="filename">/etc/shorewall/netmap</code></code> in
firewall1 would be as follows:</p><pre class="programlisting">#TYPE NET1 INTERFACE NET2
SNAT 192.168.1.0/24 vpn 10.10.11.0/24 #RULE 1A
DNAT 10.10.11.0/24 vpn 192.168.1.0/24 #RULE 1B</pre><p>The entry in <code class="filename">/etc/shorewall/netmap</code> in firewall2
would be:</p><pre class="programlisting">#TYPE NET1 INTERFACE NET2
DNAT 10.10.10.0/24 vpn 192.168.1.0/24 #RULE 2A
SNAT 192.168.1.0/24 vpn 10.10.10.0/24 #RULE 2B</pre><div class="example"><a id="Example1"></a><p class="title"><b>Example 1. 192.168.1.4 in the top cloud connects to 192.168.1.27 in the
bottom cloud</b></p><div class="example-contents"><p>In order to make this connection, the client attempts a connection
to 10.10.10.27. 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
<code class="filename">/etc/shorewall/netmap</code> entries and gives the rule
which transforms the source and destination IP addresses to those shown
on the next line. </p><div class="informaltable"><table border="1"><colgroup><col /><col /><col /><col /><col /></colgroup><thead><tr><th>FROM</th><th>TO</th><th>SOURCE IP ADDRESS</th><th>DESTINATION IP ADDRESS</th><th>RULE</th></tr></thead><tbody><tr><td>192.168.1.4 in upper cloud</td><td>Firewall 1</td><td>192.168.1.4</td><td>10.10.10.27</td><td>1A</td></tr><tr><td>Firewall 1</td><td>Firewall 2</td><td>10.10.11.4</td><td>10.10.10.27</td><td>2A</td></tr><tr><td>Firewall 2</td><td>192.168.1.27 in lower cloud</td><td>10.10.11.4</td><td>192.168.1.27</td><td> </td></tr><tr><td>192.168.1.27 in the lower cloud</td><td>Firewall 2</td><td>192.168.1.27</td><td>10.10.11.4</td><td>2B</td></tr><tr><td>Firewall 2</td><td>Firewall 1</td><td>10.10.10.27</td><td>10.10.11.4</td><td>1B</td></tr><tr><td>Firewall 1</td><td>192.168.1.4 in upper cloud</td><td>10.10.10.27</td><td>192.168.1.4</td><td> </td></tr></tbody></table></div></div></div><br class="example-break" /></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Notes"></a>Author's Notes</h2></div></div></div><p>This could all be made a bit simpler by eliminating the TYPE field
and have Shorewall generate both the SNAT and DNAT rules from a single
entry. I have chosen to include the TYPE in order to make the
implementation a bit more flexible. If you find cases where you can use an
SNAT or DNAT entry by itself, please let <a class="ulink" href="mailto:webmaster@shorewall.net" target="_self">me</a> know and I'll add the
example to this page.</p><p>In the previous section, the table in the example contains a bit of
a lie. Because of Netfilter's connection tracking, rules 2B and 1B aren't
needed to handle the replies. They ARE needed though for hosts in the
bottom cloud to be able to establish connections with the 192.168.1.0/24
network in the top cloud.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="WhyTwo"></a>Can't I do this with one router? Why do I need two?</h2></div></div></div><p>I wrote this article before Shorewall included <a class="ulink" href="MultiISP.html" target="_self">multiple provider support</a>. You should be able
to accomplish the same thing with just one router through careful use of
/etc/shorewall/netmap and <a class="ulink" href="MultiISP.html" target="_self">multiple
providers</a>. If you try it and get it working, please contribute an
update to this article.</p></div></div></body></html>
