From 0cca0503efabc6cbd6decd53b142a8567f1c8e88 Mon Sep 17 00:00:00 2001 From: mhnoyes Date: Tue, 16 Dec 2003 16:43:41 +0000 Subject: [PATCH] DocBook XML conversion git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@859 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb --- Shorewall-docs/GenericTunnels.xml | 282 ++++++++++++++++++++++++++++++ 1 file changed, 282 insertions(+) create mode 100644 Shorewall-docs/GenericTunnels.xml diff --git a/Shorewall-docs/GenericTunnels.xml b/Shorewall-docs/GenericTunnels.xml new file mode 100644 index 000000000..85efaed2f --- /dev/null +++ b/Shorewall-docs/GenericTunnels.xml @@ -0,0 +1,282 @@ + + +
+ + Generic Tunnels + + + + Tom + + Eastep + + + + + 2001 + + 2002 + + 2003 + + Thomas M. Eastep + + + 2003-08-09 + + + Shorewall includes built-in support for a wide range of VPN solutions. + If you have need for a tunnel type that does not have explicit support, you + can generally describe the tunneling software using "generic + tunnels" + +
+ Bridging two Masqueraded Networks + + Suppose that we have the following situation: + + + + We want systems in the 192.168.1.0/24 subnetwork to be able to + communicate with the systems in the 10.0.0.0/8 network. This is + accomplished through use of the /etc/shorewall/tunnels file, the + /etc/shorewall/policy file and the /etc/shorewall/tunnel script that is + included with Shorewall. + + Suppose that you have tunneling software that uses two different + protocols: + + + + TCP port 1071 + + + + GRE (Protocol 47) + + + + The tunnel interface on system A is "tun0" and the + tunnel interface on system B is also "tun0". + + + + On each firewall, you will need to declare a zone to represent the + remote subnet. We'll assume that this zone is called 'vpn' and + declare it in /etc/shorewall/zones on both systems as follows. + + + + + + ZONE + + DISPLAY + + COMMENTS + + + + + + vpn + + VPN + + Remote Subnet + + + + + + On system A, the 10.0.0.0/8 will comprise the vpn + zone. In /etc/shorewall/interfaces: + + + + + + ZONE + + INTERFACE + + BROADCAST + + OPTIONS + + + + + + vpn + + tun0 + + 10.255.255.255 + + + + + + + + In /etc/shorewall/tunnels on system A, we need the following: + + + + + + TYPE + + ZONE + + GATEWAY + + GATEWAY ZONE + + + + + + generic:tcp:1071 + + net + + 134.28.54.2 + + + + + + generic:47 + + net + + 134.28.54.2 + + + + + + + + These entries in /etc/shorewall/tunnels, opens the firewall so that + TCP port 1071 and the Generalized Routing Encapsulation Protocol (47) will + be accepted to/from the remote gateway. + + + + + + ZONE + + INTERFACE + + BROADCAST + + OPTIONS + + + + + + vpn + + tun0 + + 192.168.1.255 + + + + + + + + In /etc/shorewall/tunnels on system B, we have: + + + + + + TYPE + + ZONE + + GATEWAY + + GATEWAY ZONE + + + + + + generic:tcp:1071 + + net + + 206.191.148.9 + + + + + + generic:47 + + net + + 134.28.54.2 + + + + + + + + You will need to allow traffic between the "vpn" zone and + the "loc" zone on both systems -- if you simply want to admit all + traffic in both directions, you can use the policy file: + + + + + + SOURCE + + DEST + + POLICY + + LOG LEVEL + + + + + + loc + + vpn + + ACCEPT + + + + + + vpn + + loc + + ACCEPT + + + + + + + + On both systems, restart Shorewall and start your VPN software on + each system. The systems in the two masqueraded subnetworks can now talk + to each other +
+
\ No newline at end of file