From c2196d749c1fa0d67f5ea803eabbfbd683ea6b9e Mon Sep 17 00:00:00 2001 From: mhnoyes Date: Wed, 24 Dec 2003 22:28:25 +0000 Subject: [PATCH] fixed quotes git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@945 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb --- Shorewall-docs/FAQ.xml | 134 ++++++++++++++++++++--------------------- 1 file changed, 66 insertions(+), 68 deletions(-) diff --git a/Shorewall-docs/FAQ.xml b/Shorewall-docs/FAQ.xml index 34c111262..ff3ba6669 100644 --- a/Shorewall-docs/FAQ.xml +++ b/Shorewall-docs/FAQ.xml @@ -32,8 +32,8 @@ 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". + Texts. A copy of the license is included in the section entitled + GNU Free Documentation License. @@ -227,8 +227,8 @@ - As root, type "iptables -t nat -Z". This clears the - NetFilter counters in the nat table. + As root, type iptables -t nat -Z. This clears + the NetFilter counters in the nat table. @@ -236,7 +236,7 @@ - As root type "shorewall show nat" + As root type shorewall show nat @@ -268,7 +268,7 @@ you are trying to connect to a secondary IP address on your firewall and your rule is only redirecting the primary IP address (You need to specify the secondary IP address in the - "ORIG. DEST." column in your DNAT rule); or + ORIG. DEST. column in your DNAT rule); or @@ -373,7 +373,7 @@ The accessibility problem is best solved using Bind Version 9 "views" + url="shorewall_setup_guide.htm#DNS">Bind Version 9 views (or using a separate DNS server for local clients) such that www.mydomain.com resolves to 130.141.100.69 externally and 192.168.1.5 internally. That's what I do here at shorewall.net @@ -526,15 +526,15 @@
- (FAQ 2a) I have a zone "Z" with an RFC1918 subnet and I - use one-to-one NAT to assign non-RFC1918 addresses to hosts in Z. - Hosts in Z cannot communicate with each other using their external + <title>(FAQ 2a) I have a zone <quote>Z</quote> with an RFC1918 subnet + and I use one-to-one NAT to assign non-RFC1918 addresses to hosts in + Z. Hosts in Z cannot communicate with each other using their external (non-RFC1918 addresses) so they can't access each other using their DNS names. If the ALL INTERFACES column in /etc/shorewall/nat is empty or - contains "Yes", you will also see log messages like the + contains Yes, you will also see log messages like the following when trying to access a host in Z from another host in Z using the destination hosts's public address: @@ -545,9 +545,9 @@ Answer: This is another problem - that is best solved using Bind Version 9 "views". It allows - both external and internal clients to access a NATed host using the - host's DNS name. + that is best solved using Bind Version 9 views. It + allows both external and internal clients to access a NATed host using + the host's DNS name. Another good way to approach this problem is to switch from one-to-one NAT to Proxy ARP. That way, the hosts in Z have non-RFC1918 @@ -572,7 +572,7 @@ Set the ALL INTERFACES column in the nat file to - "Yes". + Yes. In this configuration, all Z->Z traffic will look to @@ -673,8 +673,8 @@ - In /etc/shorewall/nat, be sure that you have "Yes" in - the ALL INTERFACES column. + In /etc/shorewall/nat, be sure that you have Yes + in the ALL INTERFACES column.
@@ -765,7 +765,7 @@ through the firewall Answer: If you want your firewall - to be totally open for "ping", + to be totally open for ping, @@ -773,8 +773,8 @@ - Be sure that the first command in the file is ". - /etc/shorewall/common.def" + Be sure that the first command in the file is . + /etc/shorewall/common.def @@ -792,10 +792,10 @@ (FAQ 15) My local systems can't see out to the net Answer: Every time I read - "systems can't see out to the net", I wonder where the + systems can't see out to the net, I wonder where the poster bought computers with eyes and what those computers will - "see" when things are working properly. That aside, the most - common causes of this problem are: + see when things are working properly. That aside, the + most common causes of this problem are: @@ -831,15 +831,16 @@ the destination? Answer: NetFilter uses the - kernel's equivalent of syslog (see "man syslog") to log - messages. It always uses the LOG_KERN (kern) facility (see "man - openlog") and you get to choose the log level (again, see "man - syslog") in your policies - and rules. The destination - for messaged logged by syslog is controlled by /etc/syslog.conf (see - "man syslog.conf"). When you have changed /etc/syslog.conf, be - sure to restart syslogd (on a RedHat system, "service syslog - restart"). + kernel's equivalent of syslog (see man syslog) to log + messages. It always uses the LOG_KERN (kern) facility (see + man openlog) and you get to choose the log level (again, + see man syslog) in your policies and rules. The destination for + messaged logged by syslog is controlled by /etc/syslog.conf (see + man syslog.conf). When you have changed /etc/syslog.conf, + be sure to restart syslogd (on a RedHat system, service syslog + restart). By default, older versions of Shorewall ratelimited log messages through settings in @@ -961,10 +962,10 @@ run_iptables -A common -p udp --sport 53 -mstate --state NEW -j DROPAnswer: If you are running Shorewall version 1.4.4 or 1.4.4a then check the errata. - Otherwise, see the 'dmesg' man page ("man dmesg"). You - must add a suitable 'dmesg' command to your startup scripts or - place it in /etc/shorewall/start. Under RedHat, the max log level that - is sent to the console is specified in /etc/sysconfig/init in the + Otherwise, see the 'dmesg' man page (man dmesg). + You must add a suitable 'dmesg' command to your startup scripts + or place it in /etc/shorewall/start. Under RedHat, the max log level + that is sent to the console is specified in /etc/sysconfig/init in the LOGLEVEL variable. @@ -1075,7 +1076,7 @@ run_iptables -A common -p udp --sport 53 -mstate --state NEW -j DROP The packet has a source IP address that isn't in any of - your defined zones ("shorewall check" and look at the + your defined zones (shorewall check and look at the printed zone definitions) or the chain is FORWARD and the destination IP isn't in any of your defined zones. Also see for another cause of packets being logged @@ -1110,9 +1111,8 @@ run_iptables -A common -p udp --sport 53 -mstate --state NEW -j DROP This packet was REJECTed out of the all2all - chain -- the packet was rejected under the - "all"->"all" REJECT policy ( above). + chain -- the packet was rejected under the all->all + REJECT policy ( above). @@ -1121,8 +1121,8 @@ run_iptables -A common -p udp --sport 53 -mstate --state NEW -j DROP the packet entered the firewall via eth2. If you see - "IN=" with no interface name, the packet originated on - the firewall itself. + IN= with no interface name, the packet originated + on the firewall itself. @@ -1131,7 +1131,7 @@ run_iptables -A common -p udp --sport 53 -mstate --state NEW -j DROP if accepted, the packet would be sent on eth1. If you see - "OUT=" with no interface name, the packet would be + OUT= with no interface name, the packet would be processed by the firewall itself. @@ -1172,8 +1172,8 @@ run_iptables -A common -p udp --sport 53 -mstate --state NEW -j DROPFor additional information about the log message, see http://logi.cc/linux/netfilter-log-format.php3. - In this case, 192.168.2.2 was in the "dmz" zone and - 192.168.1.3 is in the "loc" zone. I was missing the rule: + In this case, 192.168.2.2 was in the dmz zone and + 192.168.1.3 is in the loc zone. I was missing the rule: ACCEPT dmz loc udp 53 @@ -1486,8 +1486,7 @@ Hint: insmod errors can be caused by incorrect module parameters, including inva /lib/modules/2.4.17/kernel/net/ipv4/netfilter/ip_tables.o failed /lib/modules/2.4.17/kernel/net/ipv4/netfilter/ip_tables.o: insmod ip_tables failed iptables v1.2.3: can't initialize iptables table `nat': iptables who? (do you need to insmod?) -Perhaps iptables or your kernel needs to be upgraded. - +Perhaps iptables or your kernel needs to be upgraded. This problem is usually corrected through the following sequence of commands @@ -1552,8 +1551,8 @@ Creating input Chains... instructional material use the -A command which adds the rules to the end of the chain. Most chains that Shorewall constructs end with an unconditional DROP, ACCEPT or REJECT rule and any rules that you add - after that will be ignored. Check "man iptables" and look at the - -I (--insert) command. + after that will be ignored. Check man iptables and look + at the -I (--insert) command. @@ -1583,14 +1582,14 @@ Creating input Chains...
- (FAQ 13) Why do you call it "Shorewall"? + (FAQ 13) Why do you call it <quote>Shorewall</quote>? Answer: Shorewall is a - concatenation of "Shoreline" (Shoreline (the city where I live) and - "Firewall". The full name of the product is - actually "Shoreline Firewall" but "Shorewall" is must - more commonly used. + Firewall. The full name of the + product is actually Shoreline Firewall but + Shorewall is must more commonly used.
@@ -1798,8 +1797,8 @@ Creating input Chains... (FAQ 24) How can I allow conections to let's say the ssh port only from specific IP Addresses on the internet? - In the SOURCE column of the rule, follow "net" by a colon - and a list of the host/subnet addresses as a comma-separated list. + In the SOURCE column of the rule, follow net by a + colon and a list of the host/subnet addresses as a comma-separated list. net:<ip1>,<ip2>,... @@ -1812,17 +1811,16 @@ Creating input Chains...
(FAQ 26) When I try to use any of the SYN options in nmap on or - behind the firewall, I get "operation not permitted". How can I - use nmap with Shorewall?" + behind the firewall, I get operation not permitted. How + can I use nmap with Shorewall?" - Edit /etc/shorewall/shorewall.conf and change - "NEWNOTSYN=No" to "NEWNOTSYN=Yes" then restart - Shorewall. + Edit /etc/shorewall/shorewall.conf and change NEWNOTSYN=No + to NEWNOTSYN=Yes then restart Shorewall.
- (FAQ 26a) When I try to use the "-O" option of nmap - from the firewall system, I get "operation not permitted". How - to I allow this option? + (FAQ 26a) When I try to use the <quote>-O</quote> option of + nmap from the firewall system, I get <quote>operation not permitted</quote>. + How to I allow this option? Add this command to your /etc/shorewall/start file: @@ -1836,8 +1834,8 @@ Creating input Chains... First take a look at the Shorewall kernel configuration page. You probably also want to be sure that you - have selected the "NAT of local connections - (READ HELP)" on the Netfilter Configuration menu. + have selected the NAT of local connections + (READ HELP) on the Netfilter Configuration menu. Otherwise, DNAT rules with your firewall as the source zone won't work with your new kernel.
@@ -1849,8 +1847,8 @@ Creating input Chains... allow you to route bridge traffic through Netfilter, the environment is so different from the Layer 3 firewalling environment that very little of Shorewall works. In fact, so much of Shorewall doesn't work that - my official position is that "Shorewall doesn't work with Layer - 2 Bridging". + my official position is that Shorewall doesn't work with + Layer 2 Bridging.