diff --git a/Shorewall-docs/FAQ.htm b/Shorewall-docs/FAQ.htm deleted file mode 100644 index 053895cc6..000000000 --- a/Shorewall-docs/FAQ.htm +++ /dev/null @@ -1,1383 +0,0 @@ - - - - - - - - Shorewall FAQ - - - -

Shorewall FAQs
-

-

Looking for Step by Step Configuration Instructions? Check out the QuickStart Guides.
-

-

PORT FORWARDING
-

-

1. 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.

-

1a. Ok -- I followed those -instructions but it doesn't work.
-

-

1b. I'm still having problems -with port forwarding

-

1c. 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?
-

-

30. I'm confused -about when -to use DNAT rules and when to use ACCEPT rules.

-

DNS and PORT FORWARDING/NAT
-

-

2. 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.

-

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 -(non-RFC1918 addresses) so they can't access -each other using their DNS names.

-

NETMEETING/MSN
-

-

3. I want to use Netmeeting -or MSN Instant Messenger with Shorewall. What do I do?

-

OPEN PORTS
-

-

4. I just used an online port -scanner to check my firewall and it shows some ports as 'closed' -rather than 'blocked'. Why?

-

4a. I just ran an nmap UDP -scan of my firewall and it showed 100s of ports as open!!!!
-

-4b. I have a port that I can't close no matter -how I change my rules.
-
-4c. How to I use Shorewall with PortSentry?
-

CONNECTION PROBLEMS

-

5. I've installed Shorewall and -now I can't ping through the firewall
-
-15. My local systems can't see out to the net
-

-29. FTP Doesn't Work
-

LOGGING
-

-

6. Where are the log -messages written and how do I change the destination?

-

6a. Are there any log -parsers that work with Shorewall?

-

6b. 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?
-

-

6c. 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?
-

-

6d. Why is the MAC address -in Shorewall log messages so long? I thought MAC addresses were -only 6 bytes in length.
-

-

16. Shorewall is writing log -messages all over my console making it unusable!
-

-17. How do I find out why this traffic is -getting logged?
-
-21. I see these strange log entries occasionally; -what are they?
-

ROUTING

-32. My -firewall has two connections to the -internet from two different ISPs. How do I set this up in -Shorewall?
-

STARTING AND STOPPING
-

-

7. When I stop Shorewall using -'shorewall stop', I can't connect to anything. Why doesn't that -command work?

-

8. When I try to start -Shorewall on RedHat I get messages about insmod failing -- what's -wrong?
-

-

8a. When I try to start -Shorewall on RedHat I get a message referring me to FAQ #8
-

-

9. Why can't Shorewall detect -my interfaces properly at startup?

-22. I have some iptables commands that -I want to run when Shorewall starts. Which file do I put them -in?
-

ABOUT SHOREWALL
-

-

10. What distributions -does it work with?

-

11. What features does -it -support?

-

12. Is there a GUI?

-

13. Why do you call it "Shorewall"?

-23. Why do you use such ugly fonts on -your web site?
-
-25. How to I tell which version of Shorewall -I am running?
-
-31. Does -Shorewall provide protection against...
-

RFC 1918
-

-

14. I'm connected via a cable -modem and it has an internel web server that -allows me to configure/monitor it but as expected -if I enable rfc1918 blocking for my eth0 interface, it also -blocks the cable modems web server.

-

14a. 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.

-

ALIAS IP ADDRESSES/VIRTUAL INTERFACES
-

-18. Is there any way to use aliased ip -addresses with Shorewall, and maintain separate rulesets for -different IPs?
-

MISCELLANEOUS
-

-19. I have added entries to -/etc/shorewall/tcrules but they don't seem to do -anything. Why?
-
-20. I have just set up a server. Do I have -to change Shorewall to allow access to my server from the internet?
-
-24. How -can I allow conections to let's say the ssh port -only from specific IP Addresses on the internet?
-
-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?"
-
-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?
-
-27. I am compiling a new kernel -for my -firewall. What should I look out for?
-
-28. How do I use Shorewall as a Bridging -Firewall?
-
-
-

1. 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:

-
- - - - - - - - - - - - - - - - - - - - - -
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIG. DEST.
DNATnetloc:<local IP address>[:<local port>]<protocol><port #>
-
-
-
-

So to forward UDP port 7777 to internal system -192.168.1.5, the rule is:

-
- - - - - - - - - - - - - - - - - - - - - -
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIG. DEST.
DNATnetloc:192.168.1.5udp7777
-
-
-
-
If you want to -forward requests directed to a particular address ( <external -IP> ) on your firewall to an internal system:
-
- - - - - - - - - - - - - - - - - - - - - -
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIG. DEST.
DNATnetloc:<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.
-

1a. Ok -- I followed those -instructions but it doesn't work

-

Answer: That is usually the result of one of -three things:

- -

1b. I'm still having problems with -port forwarding

-Answer: To further diagnose this problem:
- -

1c. 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:
-
-
- - - - - - - - - - - - - - - - - - - - - -
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIG. DEST.
DNATnet
- 		loc:192.168.1.3:22tcp1022
-
-
-
-
-
-

2. 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.

- -

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:
-

- - - -
- - - - - - - - - - - - - - - -
ZONE
- 		INTERFACE
- 		BROADCAST
- 		OPTIONS
-
loc
- 		eth1
- 		detect
- 		routeback
-
-
- - -
- - - - - - - - - - - - - - - - - - - - - -
ACTIONSOURCEDEST PROTODEST
-PORT(S)		SOURCE
-PORT(S)		ORIGINAL
-DEST
DNAT
- 		locweb:192.168.1.5
- 		tcpwww -
- 		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:

-
-
-
- - - - - - - - - - - - - - - - - - - - - -
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIG. DEST.
DNATlocweb:192.168.1.5tcpwww-$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.

-
-

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 (non-RFC1918 addresses) so they can't access each other using -their DNS names.

-Note: 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:

-a) Set the Z->Z policy to ACCEPT.
-b) -Masquerade Z to itself.
-c) Set the routeback option on the interface to Z.
-d) 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:

-
- - - - - - - - - - - - - - - -
ZONEINTERFACEBROADCASTOPTIONS
dmzeth2192.168.2.255routeback
-
-
-

In /etc/shorewall/policy:

-
- - - - - - - - - - - - - - - -
SOURCE DESTINATIONPOLICYLIMIT:BURST
dmzdmzACCEPT
-
-
-

In /etc/shorewall/masq:

-
- - - - - - - - - - - - - -
INTERFACE SUBNETADDRESS
eth2192.168.2.0/24
-
-
-In /etc/shorewall/nat, be sure that you have "Yes" in the ALL -INTERFACES column.
-

3. 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.

-

4. 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.

-

4a. 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.
-

-

4b. 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.
-

4c. How to I use Shorewall -with PortSentry?

-Here's -a writeup on a nice integration of Shorewall and PortSentry.
-

5. 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",

-

a) Create /etc/shorewall/common if it doesn't already -exist.
-b) -Be sure that the first command in the file is ". -/etc/shorewall/common.def"
-c) -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. -

6. 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.
-
-

6a. 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. -

6b. 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
-

6c. 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:
-
    -
  1. They are late-arriving replies to DNS queries.
    2. -
  2. They are corrupted reply packets.
    3. -
-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.
-

6d. 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:
- -Example:
-
-MAC=00:04:4c:dc:e2:28:00:b0:8e:cf:3c:4c:08:00
- -

7. 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.

-

8. 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.
-

-

8a. 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 FAQ #8
-

9. 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

-
-

10. What Distributions does it -work with?

-

Shorewall works with any GNU/Linux distribution that -includes the proper prerequisites.

-

11. What Features does it have?

-

Answer: See the Shorewall Feature List.

-

12. Is there a GUI?

-

Answer: Yes. Shorewall support is included in -Webmin 1.060 and later versions. See http://www.webmin.com -

-

13. 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.

-

14. 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:

-
-
-
- - - - - - - - - - - -
SUBNET TARGET
192.168.100.1RETURN
-
-
-
-

Be sure that you add the entry ABOVE the entry for -192.168.0.0/16.
-

-

Note: 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
-
-
-
-
-

14a. 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 FAQ 14 above. Simply -substitute the IP address of your ISPs DHCP server.

-
-

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 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:

-
    -
  1. -

    The default gateway on each local system isn't set -to the IP address of the local firewall -interface.

    -
    2. -
  2. -

    The entry for the local network in the -/etc/shorewall/masq file is wrong or missing.

    -
    3. -
  3. -

    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.

    -
    4. -
-

16. 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.
-

-

17. 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:
-
    -
  1. man1918 or logdrop - The destination address is -listed in /etc/shorewall/rfc1918 with a logdrop target -- see /etc/shorewall/rfc1918.
    2. -
  2. rfc1918 or logdrop - The source address is listed -in /etc/shorewall/rfc1918 with a logdrop target -- see /etc/shorewall/rfc1918.
    3. -
  3. 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.
    -
    4. -
  4. <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.
    5. -
  5. <interface>_mac - The packet is being logged under -the maclist interface -option.
    -
    6. -
  6. logpkt - The packet is being logged under the logunclean - interface option.
    7. -
  7. badpkt - The packet is being logged under the dropunclean - interface option as -specified in the LOGUNCLEAN setting in /etc/shorewall/shorewall.conf.
    8. -
  8. blacklst - The packet is being logged because the source -IP is blacklisted in the -/etc/shorewall/blacklist file.
    9. -
  9. 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.
    10. -
  10. 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 FAQ 2a for another -cause of packets being logged in the FORWARD chain.
    -
    11. -
  11. logflags - The packet is being logged because it failed -the checks implemented by the tcpflags interface option.
    12. -
-

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:

- -

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 -

18. 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. -

19. 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.
-

20. 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.
-

21. 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.
-

22. 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.
-

23. 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.
-

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.
-
    net:<ip1>,<ip2>,...
-Example:
-
    ACCEPT	net:192.0.2.16/28,192.0.2.44	fw	tcp	22
-
-

25. How to I tell which version of -Shorewall I am running?
-

-At the shell prompt, type:
-
- /sbin/shorewall -version
- -

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?"

-Edit /etc/shorewall/shorewall.conf and change "NEWNOTSYN=No" to -"NEWNOTSYN=Yes" then restart Shorewall.
-
-

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?

-Add this command to your /etc/shorewall/start file:
-
run_iptables -D OUTPUT -p ! icmp -m state --state INVALID -j DROP
-

27. 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.
-

28. 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".
-

29. FTP Doesn't Work
-

-See the Shorewall and FTP page.
-

30. 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.
-

31. Does Shorewall provide protection -against....

-
    -
  1. IP Spoofing: Sending packets over the WAN interface using an -internal LAP IP address as the source address? Answer: Yes.
    2. -
  2. 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.
    3. -
  3. 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.
    4. -
  4. Land Attack: Sending packets that use the same address as the -source and destination address? Answer: - Yes, if the routefilter -interface option is selected.
    5. -
  5. 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.
    6. -
-

32. 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:
-
- - - - - - - - - - - - - - - - - - - - - -
ZONEINTERFACEBROADCASTOPTIONS
net
- 		eth0detect
- 		...
-
net
- 		eth1
- 		detect
- 		...
-
-
-/etc/shorewall/policy:
-
- - - - - - - - - - - - - - - -
SOURCE DESTINATIONPOLICYLIMIT: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. -

-
- - - - - - - -
Warning -

Reader Rod Roark notes: '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. -

Note that 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.

-
-
End of information reproduced -from the LARTC HOWTO. If you have -questions or problems with the instructions given above, please post to -the LARTC mailing list. -
Last updated -11/20/2003 - Tom -Eastep -

Copyright © 2001, 2002, 2003 Thomas M. Eastep.
-

- -