mirror of
https://gitlab.com/shorewall/code.git
synced 2024-11-15 12:14:32 +01:00
339 lines
11 KiB
XML
339 lines
11 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
|
|
"http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd">
|
|
<article>
|
|
<!--$Id$-->
|
|
|
|
<articleinfo>
|
|
<title>Network Mapping</title>
|
|
|
|
<authorgroup>
|
|
<author>
|
|
<firstname>Tom</firstname>
|
|
|
|
<surname>Eastep</surname>
|
|
</author>
|
|
</authorgroup>
|
|
|
|
<pubdate><?dbtimestamp format="Y/m/d"?></pubdate>
|
|
|
|
<copyright>
|
|
<year>2004-2005</year>
|
|
|
|
<year>2007</year>
|
|
|
|
<holder>Thomas M. Eastep</holder>
|
|
</copyright>
|
|
|
|
<legalnotice>
|
|
<para>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
|
|
<quote><ulink url="GnuCopyright.htm">GNU Free Documentation
|
|
License</ulink></quote>.</para>
|
|
</legalnotice>
|
|
</articleinfo>
|
|
|
|
<section id="Why">
|
|
<title>Why use Network Mapping</title>
|
|
|
|
<para>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.</para>
|
|
</section>
|
|
|
|
<section id="Solution">
|
|
<title>Solution</title>
|
|
|
|
<para>Shorewall NETMAP support is designed to supply a solution. The basic
|
|
situation is as shown in the following diagram.<graphic
|
|
fileref="images/netmap.png" /></para>
|
|
|
|
<para>While the link between the two firewalls is shown here as a VPN, it
|
|
could be any type of interconnection that allows routing of <ulink
|
|
url="shorewall_setup_guide.htm#RFC1918">RFC 1918</ulink> traffic.</para>
|
|
|
|
<para>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.</para>
|
|
|
|
<para>In order to apply this solution:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>You must be running Shorewall 2.0.1 Beta 2 or later.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>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 <ulink
|
|
url="http://www.netfilter.org">netfilter.org</ulink>.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>NETMAP support must be enabled in your kernel
|
|
(CONFIG_IP_NF_TARGET_NETMAP=m or CONFIG_IP_NF_TARGET_NETMAP=y).</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Your iptables must have NETMAP support. NETMAP support is
|
|
available in iptables 1.2.9 and later.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>Network mapping is defined using the
|
|
<filename>/etc/shorewall/netmap</filename> file. Columns in this file
|
|
are:</para>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term>TYPE</term>
|
|
|
|
<listitem>
|
|
<para>Must be DNAT or SNAT.</para>
|
|
|
|
<para>If DNAT, traffic entering INTERFACE and addressed to NET1 has
|
|
its destination address rewritten to the corresponding address in
|
|
NET2.</para>
|
|
|
|
<para>If SNAT, traffic leaving INTERFACE with a source address in
|
|
NET1 has its source address rewritten to the corresponding address
|
|
in NET2.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>NET1</term>
|
|
|
|
<listitem>
|
|
<para>Must be expressed in CIDR format (e.g.,
|
|
192.168.1.0/24).</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>INTERFACE</term>
|
|
|
|
<listitem>
|
|
<para>A firewall interface. This interface must have been defined in
|
|
<ulink
|
|
url="manpages/shorewall-interfaces.html"><filename>/etc/shorewall/interfaces</filename></ulink>.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>NET2</term>
|
|
|
|
<listitem>
|
|
<para>A second network expressed in CIDR format.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
|
|
<para>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.<important>
|
|
<para>You must arrange for routing as follows:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Traffic from the top cloud to 10.10.10.0/24 must be routed
|
|
to eth0 on firewall 1.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Firewall 1 must route traffic to 10.10.10.0/24 through
|
|
firewall 2.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Traffic from the bottom cloud to 10.10.11.0/24 must be
|
|
routed to eth0 on firewall 2.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Firewall 2 must route traffic to 10.10.11.0/24 through
|
|
firewall 1.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</important></para>
|
|
|
|
<section id="Solution">
|
|
<title>If you are running Shorewall 4.4.22 or Earlier</title>
|
|
|
|
<para>The entries in
|
|
<filename><filename>/etc/shorewall/netmap</filename></filename> in
|
|
firewall1 would be as follows:</para>
|
|
|
|
<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</programlisting>
|
|
|
|
<para>The entry in <filename>/etc/shorewall/netmap</filename> in
|
|
firewall2 would be:</para>
|
|
|
|
<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</programlisting>
|
|
|
|
<example id="Example1">
|
|
<title>192.168.1.4 in the top cloud connects to 192.168.1.27 in the
|
|
bottom cloud</title>
|
|
|
|
<para>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
|
|
<filename>/etc/shorewall/netmap</filename> entries and gives the rule
|
|
which transforms the source and destination IP addresses to those
|
|
shown on the next line. <informaltable>
|
|
<tgroup cols="5">
|
|
<thead>
|
|
<row>
|
|
<entry>FROM</entry>
|
|
|
|
<entry>TO</entry>
|
|
|
|
<entry>SOURCE IP ADDRESS</entry>
|
|
|
|
<entry>DESTINATION IP ADDRESS</entry>
|
|
|
|
<entry>RULE</entry>
|
|
</row>
|
|
</thead>
|
|
|
|
<tbody>
|
|
<row>
|
|
<entry>192.168.1.4 in upper cloud</entry>
|
|
|
|
<entry>Firewall 1</entry>
|
|
|
|
<entry>192.168.1.4</entry>
|
|
|
|
<entry>10.10.10.27</entry>
|
|
|
|
<entry>1A</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>Firewall 1</entry>
|
|
|
|
<entry>Firewall 2</entry>
|
|
|
|
<entry>10.10.11.4</entry>
|
|
|
|
<entry>10.10.10.27</entry>
|
|
|
|
<entry>2A</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>Firewall 2</entry>
|
|
|
|
<entry>192.168.1.27 in lower cloud</entry>
|
|
|
|
<entry>10.10.11.4</entry>
|
|
|
|
<entry>192.168.1.27</entry>
|
|
|
|
<entry></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>192.168.1.27 in the lower cloud</entry>
|
|
|
|
<entry>Firewall 2</entry>
|
|
|
|
<entry>192.168.1.27</entry>
|
|
|
|
<entry>10.10.11.4</entry>
|
|
|
|
<entry>2B</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>Firewall 2</entry>
|
|
|
|
<entry>Firewall 1</entry>
|
|
|
|
<entry>10.10.10.27</entry>
|
|
|
|
<entry>10.10.11.4</entry>
|
|
|
|
<entry>1B</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>Firewall 1</entry>
|
|
|
|
<entry>192.168.1.4 in upper cloud</entry>
|
|
|
|
<entry>10.10.10.27</entry>
|
|
|
|
<entry>192.168.1.4</entry>
|
|
|
|
<entry></entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</informaltable></para>
|
|
|
|
<para>See the<ulink url="OPENVPN.html"> OpenVPN documentation</ulink>
|
|
for a solution contributed by Nicola Moretti for resolving duplicate
|
|
networks in a roadwarrior VPN environment.</para>
|
|
</example>
|
|
</section>
|
|
|
|
<section>
|
|
<title>If you are running Shorewall 4.4.23 or Later</title>
|
|
|
|
<para>Beginning with Shorewall 4.4.23, you <emphasis>can</emphasis>
|
|
bridge two duplicate networks with one router, provided that your kernel
|
|
and iptables include <emphasis>Rawpost Table Support</emphasis>. 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 <filename>/etc/shorewall/netmap</filename>. Two
|
|
additional entries are added.</para>
|
|
|
|
<programlisting>#TYPE NET1 INTERFACE NET2
|
|
SNAT 192.168.1.0/24 vpn 10.10.11.0/24
|
|
DNAT 10.10.11.0/24 vpn 192.168.1.0/24
|
|
<emphasis role="bold">SNAT:P 192.168.1.0/24 vpn 10.10.10.0/24
|
|
DNAT:T 10.10.10.0/24 vpn 192.168.1.0/24</emphasis></programlisting>
|
|
|
|
<para>The last two entries define Stateless NAT by specifying a chain
|
|
designator (:P for PREROUTING and :T for POSTROUTING respectively). See
|
|
<ulink url="manpages/shorewall-netlink.html">shorewall-netmap</ulink>
|
|
(5) for details.</para>
|
|
</section>
|
|
</section>
|
|
|
|
<section id="Notes">
|
|
<title>Author's Notes</title>
|
|
|
|
<para>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 <ulink
|
|
url="mailto:webmaster@shorewall.net">me</ulink> know and I'll add the
|
|
example to this page.</para>
|
|
|
|
<para>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.</para>
|
|
</section>
|
|
</article>
|