diff --git a/Shorewall-docs/FAQ.xml b/Shorewall-docs/FAQ.xml new file mode 100644 index 000000000..c090a0d0e --- /dev/null +++ b/Shorewall-docs/FAQ.xml @@ -0,0 +1,1846 @@ + + +
+ + Shorewall FAQs + + + Shorewall Community + + + Tom + + Eastep + + + + 2003-12-04 + + + + 1.1 + + 2003-12-04 + + MN + + Converted to Simplified DocBook XML + + + + 1.0 + + 2002-08-13 + + TE + + Initial revision + + + + + Looking for Step by Step Configuration Instructions? Check out the + QuickStart Guides. + + + +
+ Port Forwarding + +
+ I want to forward UDP port 7777 to my my personal PC with IP + address 192.168.1.5. I've looked everywhere and can't find how + to do it. + + Answer: The first example in the rules file documentation shows how + to do port forwarding under Shorewall. The format of a port-forwarding + rule to a local system is as follows: + + + + + + ACTION + + SOURCE + + DESTINATION + + PROTOCOL + + PORT + + SOURCE PORT + + ORIG. DEST. + + + + + + DNAT + + net + + loc:<local IP address>[:<local port>] + + <protocol> + + <port #> + + + + + + + + + + So to forward UDP port 7777 to internal system 192.168.1.5, the + rule is: + + + + + + ACTION + + SOURCE + + DESTINATION + + PROTOCOL + + PORT + + SOURCE PORT + + ORIG. DEST. + + + + + + DNAT + + net + + loc:192.168.1.5 + + udp + + 7777 + + + + + + + + + + If you want to forward requests directed to a particular address ( + <external IP> ) on your firewall to an + internal system: + + + + + + ACTION + + SOURCE + + DESTINATION + + PROTOCOL + + PORT + + SOURCE PORT + + ORIG. DEST. + + + + + + DNAT + + net + + loc:<local IP address>[:<local port>] + + <protocol> + + <port #> + + - + + <external IP> + + + + + + Finally, if you need to forward a range of ports, in the PORT + column specify the range as low-port:high-port. + +
+ Ok -- I followed those instructions but it doesn't work + + Answer: That is usually the + result of one of three things: + + + + You are trying to test from inside your firewall (no, that + won't work -- see ). + + + + You have a more basic problem with your local system (the + one that you are trying to forward to) such as an incorrect + default gateway (it should be set to the IP address of your + firewall's internal interface). + + + + Your ISP is blocking that particular port inbound. + + +
+ +
+ I'm still having problems with port forwarding + + Answer: To further diagnose + this problem: + + + + As root, type "iptables -t nat -Z". This clears the + NetFilter counters in the nat table. + + + + Try to connect to the redirected port from an external host. + + + + As root type "shorewall show nat" + + + + Locate the appropriate DNAT rule. It will be in a chain + called <source zone>_dnat + ('net_dnat' in the above examples). + + + + Is the packet count in the first column non-zero? If so, the + connection request is reaching the firewall and is being + redirected to the server. In this case, the problem is usually a + missing or incorrect default gateway setting on the local system + (the system you are trying to forward to -- its default gateway + should be the IP address of the firewall's interface to that + system). + + + + If the packet count is zero: + + + + the connection request is not reaching your server + (possibly it is being blocked by your ISP); or + + + + 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 + + + + your DNAT rule doesn't match the connection request + in some other way. In that case, you may have to use a packet + sniffer such as tcpdump or ethereal to further diagnose the + problem. + + + + +
+ +
+ From the internet, I want to connect to port 1022 on my + firewall and have the firewall forward the connection to port 22 on + local system 192.168.1.3. How do I do that? + + In /etc/shorewall/rules: + + + + + + ACTION + + SOURCE + + DESTINATION + + PROTOCOL + + PORT + + SOURCE PORT + + ORIG. DEST. + + + + + + DNAT + + net + + loc:192.168.1.3:22 + + tcp + + 1022 + + + + + + + + +
+
+ +
+ I'm confused about when to use DNAT rules and when to use + ACCEPT rules. + + It would be a good idea to review the QuickStart Guide + appropriate for your setup; the guides cover this topic in a tutorial + fashion. DNAT rules should be used for connections that need to go the + opposite direction from SNAT/MASQUERADE. So if you masquerade or use + SNAT from your local network to the internet then you will need to use + DNAT rules to allow connections from the internet to your local network. + In all other cases, you use ACCEPT unless you need to hijack connections + as they go through your firewall and handle them on the firewall box + itself; in that case, you use a REDIRECT rule. +
+
+ +
+ DNS and Port Forwarding/NAT + +
+ I port forward www requests to www.mydomain.com (IP + 130.151.100.69) to system 192.168.1.5 in my local network. External + clients can browse http://www.mydomain.com but internal clients + can't. + + Answer: I have two objections to + this setup. + + + + Having an internet-accessible server in your local network is + like raising foxes in the corner of your hen house. If the server is + compromised, there's nothing between that server and your other + internal systems. For the cost of another NIC and a cross-over + cable, you can put your server in a DMZ such that it is isolated + from your local systems - assuming that the Server can be located + near the Firewall, of course :-) + + + + The accessibility problem is best solved using 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 + for my local systems that use one-to-one NAT. + + + + If you insist on an IP solution to the accessibility problem + rather than a DNS solution, then assuming that your external interface + is eth0 and your internal interface is eth1 and that eth1 has IP address + 192.168.1.254 with subnet 192.168.1.0/24. + + If you are running Shorewall 1.4.0 or earlier see the 1.3 FAQ for instructions suitable for + those releases. + + If you are running Shorewall 1.4.1 or Shorewall 1.4.1a, please + upgrade to Shorewall 1.4.2 or later. + + Otherwise: + + + + In /etc/shorewall/interfaces: + + + + + + ZONE + + INTERFACE + + BROADCAST + + OPTIONS + + + + + + loc + + eth1 + + detect + + routeback + + + + + + + + In /etc/shorewall/rules: + + + + + + ACTION + + SOURCE + + DESTINATION + + PROTOCOL + + PORT + + SOURCE PORT + + ORIG. DEST. + + + + + + DNAT + + loc + + web:192.168.1.5 + + tcp + + www + + - + + 130.151.100.69:192.168.1.254 + + + + + + That rule only works of course if you have a static external + IP address. If you have a dynamic IP address and are running + Shorewall 1.3.4 or later then include this in /etc/shorewall/init: + + ETH0_IP=`find_interface_address eth0` + + and make your DNAT rule: + + + + + + ACTION + + SOURCE + + DESTINATION + + PROTOCOL + + PORT + + SOURCE PORT + + ORIG. DEST. + + + + + + DNAT + + loc + + web:192.168.1.5 + + tcp + + www + + - + + $ETH0_IP:192.168.1.254 + + + + + + Using this technique, you will want to configure your + DHCP/PPPoE client to automatically restart Shorewall each time that + you get a new IP address. + + + +
+ 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 (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 + following when trying to access a host in Z from another host in Z + using the destination hosts's public address: + + Oct 4 10:26:40 netgw kernel: Shorewall:FORWARD:REJECT:IN=eth1 OUT=eth1 + SRC=192.168.118.200 DST=192.168.118.210 LEN=48 TOS=0x00 PREC=0x00 TTL=127 + ID=1342 DF PROTO=TCP SPT=1494 DPT=1491 WINDOW=17472 RES=0x00 ACK SYN URGP=0 + + + 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. + + 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 + addresses and can be accessed externally and internally using the same + address. + + If you don't like those solutions and prefer routing all + Z->Z traffic through your firewall then: + + + + Set the Z->Z policy to ACCEPT. + + + + Masquerade Z to itself. + + + + Set the routeback option on the interface to Z. + + + + Set the ALL INTERFACES column in the nat file to + "Yes". + + WARNING: In this + configuration, all Z->Z traffic will look to the server as if + it came from the firewall rather than from the original client! I + DO NOT RECOMMEND THIS SETUP. + + + + + Example: + + Zone: dmz +Interface: eth2 +Subnet: 192.168.2.0/24 + + In /etc/shorewall/interfaces: + + + + + + ZONE + + INTERFACE + + BROADCAST + + OPTIONS + + + + + + dmz + + eth2 + + 192.168.2.255 + + routeback + + + + + + In /etc/shorewall/policy: + + + + + + SOURCE + + DESTINATION + + POLICY + + LIMIT:BURST + + + + + + dmz + + dmz + + ACCEPT + + + + + + + + In /etc/shorewall/masq: + + + + + + INTERFACE + + SUBNET + + ADDRESS + + + + + + eth2 + + 192.168.2.0/24 + + + + + + + + In /etc/shorewall/nat, be sure that you have "Yes" in + the ALL INTERFACES column. + +
+
+
+ +
+ Netmeeting/MSN + +
+ I want to use Netmeeting or MSN Instant Messenger with Shorewall. + What do I do? + + Answer: There is an H.323 + connection tracking/NAT module that helps with Netmeeting. Look + here for a + solution for MSN IM but be aware that there are significant security + risks involved with this solution. Also check the Netfilter mailing list + archives at http://www.netfilter.org. +
+
+ +
+ Open Ports + +
+ I just used an online port scanner to check my firewall and it + shows some ports as 'closed' rather than 'blocked'. Why? + + Answer: The common.def included + with version 1.3.x always rejects connection requests on TCP port 113 + rather than dropping them. This is necessary to prevent outgoing + connection problems to services that use the 'Auth' mechanism + for identifying requesting users. Shorewall also rejects TCP ports 135, + 137 and 139 as well as UDP ports 137-139. These are ports that are used + by Windows (Windows can be configured to use the + DCE cell locator on port 135). Rejecting these connection requests + rather than dropping them cuts down slightly on the amount of Windows + chatter on LAN segments connected to the Firewall. + + If you are seeing port 80 being 'closed', that's + probably your ISP preventing you from running a web server in violation + of your Service Agreement. + +
+ I just ran an nmap UDP scan of my firewall and it showed 100s + of ports as open!!!! + + Answer: Take a deep breath and + read the nmap man page section about UDP scans. If nmap gets nothing back from your firewall then it reports + the port as open. If you want to see which UDP ports are really open, + temporarily change your net->all policy to REJECT, restart + Shorewall and do the nmap UDP scan again. +
+ +
+ I have a port that I can't close no matter how I change my + rules. + + I had a rule that allowed telnet from my local network to my + firewall; I removed that rule and restarted Shorewall but my telnet + session still works!!! + + Answer: Rules only govern the + establishment of new connections. Once a connection is established + through the firewall it will be usable until disconnected (tcp) or + until it times out (other protocols). If you stop telnet and try to + establish a new session your firerwall will block that attempt. +
+ +
+ How to I use Shorewall with PortSentry? + + Here's + a writeup on a nice integration of Shorewall and PortSentry. +
+
+
+ +
+ Connection Problems + +
+ I've installed Shorewall and now I can't ping through the + firewall + + Answer: If you want your firewall + to be totally open for "ping", + + + + Create /etc/shorewall/common if it doesn't already exist. + + + + Be sure that the first command in the file is ". + /etc/shorewall/common.def" + + + + Add the following to /etc/shorewall/common + + run_iptables -A icmpdef -p ICMP --icmp-type echo-request -j ACCEPT + + + + For a complete description of Shorewall 'ping' management, + see this page. +
+ +
+ 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 + 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: + + + + The default gateway on each local system isn't set to the + IP address of the local firewall interface. + + + + The entry for the local network in the /etc/shorewall/masq + file is wrong or missing. + + + + The DNS settings on the local systems are wrong or the user is + running a DNS server on the firewall and hasn't enabled UDP and + TCP port 53 from the firewall to the internet. + + +
+ +
+ FTP Doesn't Work + + See the Shorewall and FTP page. +
+
+ +
+ Logging + +
+ Where are the log messages written and how do I change 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"). + + By default, older versions of Shorewall ratelimited log messages + through settings in + /etc/shorewall/shorewall.conf -- If you want to log all messages, set: + + LOGLIMIT="" +LOGBURST="" + + Beginning with Shorewall version 1.3.12, you can set up Shorewall to log all of its messages + to a separate file. + +
+ Are there any log parsers that work with Shorewall? + + Answer: Here are several links + that may be helpful: + + http://www.shorewall.net/pub/shorewall/parsefw/ +http://www.fireparse.com +http://cert.uni-stuttgart.de/projects/fwlogwatch +http://www.logwatch.org +http://gege.org/iptables +http://home.regit.org/ulogd-php.html + + I personnaly use Logwatch. It emails me a report each day from + my various systems with each report summarizing the logged activity on + the corresponding system. +
+ +
+ DROP messages on port 10619 are flooding the logs with their + connect requests. Can i exclude these error messages for this port + temporarily from logging in Shorewall? + + Temporarily add the following rule: + + DROP net fw udp 10619 +
+ +
+ All day long I get a steady flow of these DROP messages from + port 53 to some high numbered port. They get dropped, but what the + heck are they? + + Jan 8 15:50:48 norcomix kernel: Shorewall:net2all:DROP:IN=eth0 OUT= MAC=00:40:c7:2e:09:c0:00:01:64:4a:70:00:08:00 + SRC=208.138.130.16 DST=24.237.22.45 LEN=53 TOS=0x00 PREC=0x00 + TTL=251 ID=8288 DF PROTO=UDP SPT=53 DPT=40275 LEN=33 + + Answer: There are two + possibilities: + + + + They are late-arriving replies to DNS queries. + + + + They are corrupted reply packets. + + + + You can distinguish the difference by setting the logunclean option (/etc/shorewall/interfaces) + on your external interface (eth0 in the above example). If they get + logged twice, they are corrupted. I solve this problem by using an + /etc/shorewall/common file like this: + + # +# Include the standard common.def file +# +. /etc/shorewall/common.def +# +# The following rule is non-standard and compensates for tardy +# DNS replies +# +run_iptables -A common -p udp --sport 53 -mstate --state NEW -j DROP + + The above file is also include in all of my sample + configurations available in the Quick Start Guides and in + the common.def file in Shorewall 1.4.0 and later. +
+ +
+ Why is the MAC address in Shorewall log messages so long? I + thought MAC addresses were only 6 bytes in length. + + What is labeled as the MAC address in a Shorewall log message is + actually the Ethernet frame header. IT contains: + + + + the destination MAC address (6 bytes) + + + + the source MAC address (6 bytes) + + + + the ethernet frame type (2 bytes) + + + + + Example: + + MAC=00:04:4c:dc:e2:28:00:b0:8e:cf:3c:4c:08:00 + + + + Destination MAC address = 00:04:4c:dc:e2:28 + + + + Source MAC address = 00:b0:8e:cf:3c:4c + + + + Ethernet Frame Type = 08:00 (IP Version 4) + + + +
+
+ +
+ Shorewall is writing log messages all over my console making it + unusable! + + Answer: 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 + LOGLEVEL variable. +
+ +
+ How do I find out why this traffic is getting logged? + + Answer: Logging occurs out of a + number of chains (as indicated in the log message) in Shorewall: + + + + man1918 or logdrop + + + The destination address is listed in /etc/shorewall/rfc1918 + with a logdrop target -- see + /etc/shorewall/rfc1918. + + + + + rfc1918 or logdrop + + + The source address is listed in /etc/shorewall/rfc1918 with + a logdrop target -- see /etc/shorewall/rfc1918. + + + + + all2<zone>, <zone>2all or all2all + + + You have a policy + that specifies a log level and this packet is being logged under + that policy. If you intend to ACCEPT this traffic then you need a + rule to that effect. + + + + + <zone1>2<zone2> + + + Either you have a policy + for <zone1> to <zone2> that specifies a log level + and this packet is being logged under that policy or this packet + matches a rule that + includes a log level. + + + + + <interface>_mac + + + The packet is being logged under the maclist + interface option. + + + + + logpkt + + + The packet is being logged under the logunclean + interface option. + + + + + badpkt + + + The packet is being logged under the dropunclean + interface option + as specified in the LOGUNCLEAN + setting in /etc/shorewall/shorewall.conf. + + + + + blacklst + + + The packet is being logged because the source IP is + blacklisted in the /etc/shorewall/blacklist + file. + + + + + newnotsyn + + + The packet is being logged because it is a TCP packet that + is not part of any current connection yet it is not a syn packet. + Options affecting the logging of such packets include NEWNOTSYN and LOGNEWNOTSYN + in /etc/shorewall/shorewall.conf. + + + + + INPUT or FORWARD + + + The packet has a source IP address that isn't in any of + 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 + in the FORWARD chain. + + + + + logflags + + + The packet is being logged because it failed the checks + implemented by the tcpflags + interface option. + + + + + + Here is an example: + + Jun 27 15:37:56 gateway kernel: Shorewall:all2all:REJECT:IN=eth2 OUT=eth1 +SRC=192.168.2.2 DST=192.168.1.3 LEN=67 TOS=0x00 PREC=0x00 TTL=63 ID=5805 DF +PROTO=UDP SPT=1803 DPT=53 LEN=47 + + Let's look at the important parts of this message: + + + + all2all:REJECT + + + This packet was REJECTed out of the all2all + chain -- the packet was rejected under the + "all"->"all" REJECT policy ( above). + + + + + IN=eth2 + + + the packet entered the firewall via eth2. If you see + "IN=" with no interface name, the packet originated on + the firewall itself. + + + + + OUT=eth1 + + + if accepted, the packet would be sent on eth1. If you see + "OUT=" with no interface name, the packet would be + processed by the firewall itself. + + + + + SRC=192.168.2.2 + + + the packet was sent by 192.168.2.2 + + + + + DST=192.168.1.3 + + + the packet is destined for 192.168.1.3 + + + + + PROTO=UDP + + + UDP Protocol + + + + + DPT=53 + + + The destination port is 53 (DNS) + + + + + 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 + +
+ +
+ I see these strange log entries occasionally; what are they? + + Nov 25 18:58:52 linux kernel: Shorewall:net2all:DROP:IN=eth1 OUT= MAC=00:60:1d:f0:a6:f9:00:60:1d:f6:35:50:08:00 + SRC=206.124.146.179 DST=192.0.2.3 LEN=56 TOS=0x00 PREC=0x00 TTL=110 ID=18558 PROTO=ICMP TYPE=3 CODE=3 + [SRC=192.0.2.3 DST=172.16.1.10 LEN=128 TOS=0x00 PREC=0x00 TTL=47 ID=0 DF PROTO=UDP SPT=53 DPT=2857 LEN=108 ] + + 192.0.2.3 is external on my firewall... 172.16.0.0/24 is my + internal LAN + + Answer: While most people + associate the Internet Control Message Protocol (ICMP) with + 'ping', ICMP is a key piece of the internet. ICMP is used to + report problems back to the sender of a packet; this is what is + happening here. Unfortunately, where NAT is involved (including SNAT, + DNAT and Masquerade), there are a lot of broken implementations. That is + what you are seeing with these messages. + + Here is my interpretation of what is happening -- to confirm this + analysis, one would have to have packet sniffers placed a both ends of + the connection. + + Host 172.16.1.10 behind NAT gateway 206.124.146.179 sent a UDP DNS + query to 192.0.2.3 and your DNS server tried to send a response (the + response information is in the brackets -- note source port 53 which + marks this as a DNS reply). When the response was returned to to + 206.124.146.179, it rewrote the destination IP TO 172.16.1.10 and + forwarded the packet to 172.16.1.10 who no longer had a connection on + UDP port 2857. This causes a port unreachable (type 3, code 3) to be + generated back to 192.0.2.3. As this packet is sent back through + 206.124.146.179, that box correctly changes the source address in the + packet to 206.124.146.179 but doesn't reset the DST IP in the + original DNS response similarly. When the ICMP reaches your firewall + (192.0.2.3), your firewall has no record of having sent a DNS reply to + 172.16.1.10 so this ICMP doesn't appear to be related to anything + that was sent. The final result is that the packet gets logged and + dropped in the all2all chain. I have also seen cases where the source IP + in the ICMP itself isn't set back to the external IP of the remote + NAT gateway; that causes your firewall to log and drop the packet out of + the rfc1918 chain because the source IP is reserved by RFC 1918. +
+
+ +
+ Routing + +
+ My firewall has two connections to the internet from two + different ISPs. How do I set this up in Shorewall? + + Setting this up in Shorewall is easy; setting up the routing is a + bit harder. + + Assuming that eth0 and eth1 are the interfaces to the two ISPs + then: + + /etc/shorewall/interfaces: + + + + + + ZONE + + INTERFACE + + BROADCAST + + OPTIONS + + + + + + net + + eth0 + + detect + + ... + + + + net + + eth1 + + detect + + ... + + + + + + /etc/shorewall/policy: + + + + + + SOURCE + + DESTINATION + + POLICY + + LIMIT:BURST + + + + + + net + + net + + DROP + + + + + + + + The following information regarding setting up routing + for this configuration is reproduced from the LARTC HOWTO and has not been verified + by the author. If you have questions or problems with the instructions + given below, please post to the LARTC mailing list. + + + A common configuration is the following, in which there are two + providers that connect a local network (or even a single machine) to + the big Internet. + + ________ + +------------+ / + | | | + +-------------+ Provider 1 +------- + __ | | | / + ___/ \_ +------+-------+ +------------+ | + _/ \__ | if1 | / + / \ | | | +| Local network -----+ Linux router | | Internet + \_ __/ | | | + \__ __/ | if2 | \ + \___/ +------+-------+ +------------+ | + | | | \ + +-------------+ Provider 2 +------- + | | | + +------------+ \________ + + There are usually two questions given this setup. + + Split access + + The first is how to route answers to packets coming in over a + particular provider, say Provider 1, back out again over that same + provider. + + Let us first set some symbolical names. Let $IF1 be the name of the first interface (if1 in + the picture above) and $IF2 the name + of the second interface. Then let $IP1 + be the IP address associated with $IF1 + and $IP2 the IP address associated + with $IF2. Next, let $P1 be the IP address of the gateway at + Provider 1, and $P2 the IP address of + the gateway at provider 2. Finally, let $P1_NET + be the IP network $P1 is in, and + $P2_NET the IP network $P2 is in. + + One creates two additional routing tables, say T1 and T2. + These are added in /etc/iproute2/rt_tables. Then you set up routing in + these tables as follows: + + ip route add $P1_NET dev $IF1 src $IP1 table T1 +ip route add default via $P1 table T1 +ip route add $P2_NET dev $IF2 src $IP2 table T2 +ip route add default via $P2 table T2 + + Nothing spectacular, just build a route to the gateway and build + a default route via that gateway, as you would do in the case of a + single upstream provider, but put the routes in a separate table per + provider. Note that the network route suffices, as it tells you how to + find any host in that network, which includes the gateway, as + specified above. + + Next you set up the main routing table. It is a good idea to + route things to the direct neighbour through the interface connected + to that neighbour. Note the `src' arguments, they make sure the + right outgoing IP address is chosen. + + ip route add $P1_NET dev $IF1 src $IP1 +ip route add $P2_NET dev $IF2 src $IP2 + + Then, your preference for default route: + + ip route add default via $P1 + + Next, you set up the routing rules. These actually choose what + routing table to route with. You want to make sure that you route out + a given interface if you already have the corresponding source + address: + + ip rule add from $IP1 table T1 +ip rule add from $IP2 table T2 + + This set of commands makes sure all answers to traffic coming in + on a particular interface get answered from that interface. + + + 'If $P0_NET is the local network and $IF0 is its + interface, the following additional entries are desirable: + + ip route add $P0_NET dev $IF0 table T1 +ip route add $P2_NET dev $IF2 table T1 +ip route add 127.0.0.0/8 dev lo table T1 +ip route add $P0_NET dev $IF0 table T2 +ip route add $P1_NET dev $IF1 table T2 +ip route add 127.0.0.0/8 dev lo table T2 + + + Now, this is just the very basic setup. It will work for all + processes running on the router itself, and for the local network, if + it is masqueraded. If it is not, then you either have IP space from + both providers or you are going to want to masquerade to one of the + two providers. In both cases you will want to add rules selecting + which provider to route out from based on the IP address of the + machine in the local network. + + Load balancing + + The second question is how to balance traffic going out over the + two providers. This is actually not hard if you already have set up + split access as above. + + Instead of choosing one of the two providers as your default + route, you now set up the default route to be a multipath route. In + the default kernel this will balance routes over the two providers. It + is done as follows (once more building on the example in the section + on split-access): + + ip route add default scope global nexthop via $P1 dev $IF1 weight 1 \ +nexthop via $P2 dev $IF2 weight 1 + + This will balance the routes over both providers. The weight parameters can be tweaked to favor one + provider over the other. + + + balancing will not be perfect, as it is route based, and + routes are cached. This means that routes to often-used sites will + always be over the same provider. + + + Furthermore, if you really want to do this, you probably also + want to look at Julian Anastasov's patches at http://www.ssi.bg/~ja/#routes + , Julian's route patch page. They will make things nicer to work + with. + +
+
+ +
+ Starting and Stopping + +
+ When I stop Shorewall using 'shorewall stop', I can't + connect to anything. Why doesn't that command work? + + The 'stop' command is intended to place your firewall into + a safe state whereby only those hosts listed in + /etc/shorewall/routestopped' are activated. If you want to totally + open up your firewall, you must use the 'shorewall clear' + command. +
+ +
+ When I try to start Shorewall on RedHat, I get messages about + insmod failing -- what's wrong? + + Answer: The output you will see + looks something like this: + + /lib/modules/2.4.17/kernel/net/ipv4/netfilter/ip_tables.o: init_module: Device or resource busy +Hint: insmod errors can be caused by incorrect module parameters, including invalid IO or IRQ parameters +/lib/modules/2.4.17/kernel/net/ipv4/netfilter/ip_tables.o: insmod +/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. + + This is usually cured by the following sequence of commands: + + service ipchains stop +chkconfig --delete ipchains +rmmod ipchains + + Also, be sure to check the errata + for problems concerning the version of iptables (v1.2.3) shipped with + RH7.2. + +
+ When I try to start Shorewall on RedHat I get a message + referring me to FAQ #8 + + Answer: This is usually cured + by the sequence of commands shown above in . +
+
+ +
+ Why can't Shorewall detect my interfaces properly at startup? + + I just installed Shorewall and when I issue the start command, I + see the following: + + Processing /etc/shorewall/params ... +Processing /etc/shorewall/shorewall.conf ... +Starting Shorewall... +Loading Modules... +Initializing... +Determining Zones... +Zones: net loc +Validating interfaces file... +Validating hosts file... +Determining Hosts in Zones... +Net Zone: eth0:0.0.0.0/0 +Local Zone: eth1:0.0.0.0/0 +Deleting user chains... +Creating input Chains... +... + + Why can't Shorewall detect my interfaces properly? + + Answer: The above output is + perfectly normal. The Net zone is defined as all hosts that are + connected through eth0 and the local zone is defined as all hosts + connected through eth1 +
+ +
+ I have some iptables commands that I want to run when Shorewall + starts. Which file do I put them in? + + You can place these commands in one of the Shorewall Extension Scripts. + Be sure that you look at the contents of the chain(s) that you will be + modifying with your commands to be sure that the commands will do what + they are intended. Many iptables commands published in HOWTOs and other + 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. +
+
+ +
+ About Shorewall + +
+ What Distributions does it work with? + + Shorewall works with any GNU/Linux distribution that includes the + proper prerequisites. +
+ +
+ What Features does it have? + + Answer: See the Shorewall Feature List. +
+ +
+ Is there a GUI? + + Answer: Yes. Shorewall support is + included in Webmin 1.060 and later versions. See http://www.webmin.com +
+ +
+ Why do you call it "Shorewall"? + + Answer: Shorewall is a + concatenation of "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. +
+ +
+ Why do you use such ugly fonts on your web site? + + The Shorewall web site is almost font neutral (it doesn't + explicitly specify fonts except on a few pages) so the fonts you see are + largely the default fonts configured in your browser. If you don't + like them then reconfigure your browser. +
+ +
+ How to I tell which version of Shorewall I am running? + + At the shell prompt, type: + + /sbin/shorewall version +
+ +
+ Does Shorewall provide protection against.... + + + + IP Spoofing: Sending packets over the WAN interface using an + internal LAP IP address as the source address? + + + Answer: Yes. + + + + + Tear Drop: Sending packets that contain overlapping fragments? + + + Answer: This is the responsibility of the IP stack, not the + Netfilter-based firewall since fragment reassembly occurs before + the stateful packet filter ever touches each packet. + + + + + Smurf and Fraggle: Sending packets that use the WAN or LAN + broadcast address as the source address? + + + Answer: Shorewall can be configured to do that using the + blacklisting + facility. + + + + + Land Attack: Sending packets that use the same address as the + source and destination address? + + + Answer: Yes, if the routefilter interface option + is selected. + + + + + DOS: - SYN Dos - ICMP Dos - Per-host Dos protection + + + Answer: Shorewall has facilities for limiting SYN and ICMP + packets. Netfilter as included in standard Linux kernels + doesn't support per-remote-host limiting except by explicit + rule that specifies the host IP address; that form of limiting is + supported by Shorewall. + + + +
+
+ +
+ RFC 1918 + +
+ I'm connected via a cable modem and it has an internal web + server that allows me to configure/monitor it but as expected if I + enable rfc1918 blocking for my eth0 interface (the internet one), it + also blocks the cable modems web server. + + Is there any way it can add a rule before the rfc1918 blocking + that will let all traffic to and from the 192.168.100.1 address of the + modem in/out but still block all other rfc1918 addresses? + + Answer: If you are running a + version of Shorewall earlier than 1.3.1, create /etc/shorewall/start and + in it, place the following: + + run_iptables -I rfc1918 -s 192.168.100.1 -j ACCEPT + + If you are running version 1.3.1 or later, simply add the + following to /etc/shorewall/rfc1918: + + Be sure that you add the entry ABOVE the entry for 192.168.0.0/16. + + + + + + SUBNET + + TARGET + + + + + + 192.168.100.1 + + RETURN + + + + + + + If you add a second IP address to your external firewall + interface to correspond to the modem address, you must also make an + entry in /etc/shorewall/rfc1918 for that address. For example, if you + configure the address 192.168.100.2 on your firewall, then you would + add two entries to /etc/shorewall/rfc1918: + + + + + + SUBNET + + TARGET + + + + + + 192.168.100.1 + + RETURN + + + + 192.168.100.2 + + RETURN + + + + + + +
+ Even though it assigns public IP addresses, my ISP's DHCP + server has an RFC 1918 address. If I enable RFC 1918 filtering on my + external interface, my DHCP client cannot renew its lease. + + The solution is the same as above. + Simply substitute the IP address of your ISPs DHCP server. +
+
+
+ +
+ Alias IP Addresses/Virtual Interfaces + +
+ Is there any way to use aliased ip addresses with Shorewall, and + maintain separate rulesets for different IPs? + + Answer: Yes. See Shorewall and Aliased + Interfaces. +
+
+ +
+ MISCELLANEOUS + +
+ I have added entries to /etc/shorewall/tcrules but they don't + seem to do anything. Why? + + You probably haven't set TC_ENABLED=Yes in + /etc/shorewall/shorewall.conf so the contents of the tcrules file are + simply being ignored. +
+ +
+ I have just set up a server. Do I have to change Shorewall to + allow access to my server from the internet? + + Yes. Consult the QuickStart + guide that you used during your initial setup for information + about how to set up rules for your server. +
+ +
+ 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. + + net:<ip1>,<ip2>,... + + + Example: + + ACCEPT net:192.0.2.16/28,192.0.2.44 fw tcp 22 + +
+ +
+ 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?" + + Edit /etc/shorewall/shorewall.conf and change + "NEWNOTSYN=No" to "NEWNOTSYN=Yes" then restart + Shorewall. + +
+ 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? + + Add this command to your /etc/shorewall/start file: + + run_iptables -D OUTPUT -p ! icmp -m state --state INVALID -j DROP +
+
+ +
+ I'm compiling a new kernel for my firewall. What should I + look out for? + + 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. + Otherwise, DNAT rules with your firewall as the source zone won't + work with your new kernel. +
+ +
+ How do I use Shorewall as a Bridging Firewall? + + Basically, you don't. While there are kernel patches that + 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". +
+
+
\ No newline at end of file