diff --git a/STABLE/documentation/VPN.htm b/STABLE/documentation/VPN.htm new file mode 100644 index 000000000..d18deab54 --- /dev/null +++ b/STABLE/documentation/VPN.htm @@ -0,0 +1,81 @@ + + + + + + + +VPN + + + + + + + + +
+

VPN

+
+

It is often the case that a system behind the firewall needs to be able to +access a remote network through Virtual Private Networking (VPN). The two most +common means for doing this are IPSEC and PPTP. The basic setup is shown in the +following diagram:

+

+

A system with an RFC 1918 address needs to access a remote +network through a remote gateway. For this example, we will assume that the +local system has IP address 192.168.1.12 and that the remote gateway has IP +address 192.0.2.224.

+

If PPTP is being used, there are no firewall requirements beyond +the default loc->net ACCEPT policy. There is one restriction however: Only one +local system at a time can be connected to a single remote gateway unless you +patch your kernel from the 'Patch-o-matic' patches available at +http://www.netfilter.org.

+

If IPSEC is being used then there are firewall configuration +requirements as follows:

+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ACTIONSOURCEDESTINATIONPROTOCOLPORTCLIENT
+ PORT		ORIGINAL
+ DEST
DNATnet:192.0.2.224loc:192.168.1.1250   
DNATnet:192.0.2.224loc:192.168.1.12udp500  
+
+

If you want to be able to give access to all of your local systems to the +remote network, you should consider running a VPN client on your firewall. As +starting points, see + +http://www.shorewall.net/Documentation.htm#Tunnels or +http://www.shorewall.net/PPTP.htm.

+

Last modified 8/27/2002 - Tom +Eastep

+Copyright © 2002 Thomas M. Eastep.

 

+ + + + diff --git a/STABLE/documentation/images/VPN.png b/STABLE/documentation/images/VPN.png new file mode 100644 index 000000000..2f3177ca2 Binary files /dev/null and b/STABLE/documentation/images/VPN.png differ diff --git a/STABLE/documentation/upgrade_issues.htm b/STABLE/documentation/upgrade_issues.htm new file mode 100644 index 000000000..1e292ef03 --- /dev/null +++ b/STABLE/documentation/upgrade_issues.htm @@ -0,0 +1,145 @@ + + + + + + Upgrade Issues + + + + + + + + + + + + + +
+

Upgrade Issues

+
+ +

For upgrade instructions see the + Install/Upgrade page.

+ +

Version >= 1.3.7

+ +

Users specifying ALLOWRELATED=No in + /etc/shorewall.conf will need to include the + following rules in their /etc/shorewall/icmpdef + file (creating this file if necessary):

+ + 
	run_iptables -A icmpdef -p ICMP --icmp-type echo-reply -j ACCEPT
+	run_iptables -A icmpdef -p ICMP --icmp-type source-quench -j ACCEPT
+	run_iptables -A icmpdef -p ICMP --icmp-type destination-unreachable -j ACCEPT
+	run_iptables -A icmpdef -p ICMP --icmp-type time-exceeded -j ACCEPT
+	run_iptables -A icmpdef -p ICMP --icmp-type parameter-problem -j ACCEPT
+

Users having an /etc/shorewall/icmpdef file may remove the ". + /etc/shorewall/icmp.def" command from that file since the icmp.def file is now + empty.

+

Upgrading Bering to + Shorewall >= 1.3.3

+ +

To properly upgrade with Shorewall version + 1.3.3 and later:

+ +
    +
  1. Be sure you have a backup -- you will need + to transcribe any Shorewall configuration + changes that you have made to the new + configuration.
    2. +
  2. Replace the shorwall.lrp package provided on + the Bering floppy with the later one. If you did + not obtain the later version from Jacques's + site, see additional instructions below.
    3. +
  3. Edit the /var/lib/lrpkg/root.exclude.list + file and remove the /var/lib/shorewall entry if + present. Then do not forget to backup root.lrp !
    4. +
+

The .lrp that I release isn't set up for a two-interface firewall like + Jacques's. You need to follow the instructions for + setting up a two-interface firewall plus you also need to add the following + two Bering-specific rules to /etc/shorewall/rules:

+
+ 
# Bering specific rules:
+# allow loc to fw udp/53 for dnscache to work
+# allow loc to fw tcp/80 for weblet to work
+#
+ACCEPT loc fw udp 53
+ACCEPT loc fw tcp 80
+
+ +

Version >= 1.3.6

+ +

If you have a pair of firewall systems configured for + failover, you will need to modify your firewall setup slightly under + Shorewall versions >= 1.3.6.

+ +
    +
  1. + +

    Create the file /etc/shorewall/newnotsyn and in it add + the following rule
    +
    + run_iptables -A newnotsyn -j RETURN # So that the + connection tracking table can be rebuilt
    +                                    + # from non-SYN packets after takeover.
    + 

    2. +
  2. + +

    Create /etc/shorewall/common (if you don't already + have that file) and include the following:
    +
    + run_iptables -A common -p tcp --tcp-flags + ACK,FIN,RST ACK -j ACCEPT #Accept Acks to rebuild connection
    +                                                                    + #tracking table.
    + . /etc/shorewall/common.def

    3. +
+ +

Versions >= 1.3.5

+ +

Some forms of pre-1.3.0 rules file syntax are no + longer supported.

+ +

Example 1:

+ +
+ 
	ACCEPT    net    loc:192.168.1.12:22    tcp    11111    -    all
+
+ +

Must be replaced with:

+ +
+ 
	DNAT	net	loc:192.168.1.12:22	tcp	11111
+
+
+

Example 2:

+
+ 
	ACCEPT	loc	fw::3128	tcp	80	-	all
+
+
+

Must be replaced with:

+
+ 
	REDIRECT	loc	3128	tcp	80
+
+ +

Version >= 1.3.2

+ +

The functions and versions files together with the + 'firewall' symbolic link have moved from /etc/shorewall to /var/lib/shorewall. + If you have applications that access these files, those applications + should be modified accordingly.

+ +

+ Last updated 9/13/2002 - + Tom Eastep

+ +

Copyright + © 2001, 2002 Thomas M. Eastep.

+ + + \ No newline at end of file