
				SuSEfirewall2

		F R E Q U E N T   A S K E D   Q U E S T I O N S


Q: I have a problem setting up the config file
A: read the files
	/etc/sysconfig/SuSEfirewall2
	/usr/share/doc/packages/SuSEfirewall2/EXAMPLES
	/usr/share/doc/packages/SuSEfirewall2/FAQ
	/usr/share/doc/packages/SuSEfirewall2/SuSEfirewall2.conf.EXAMPLE
   if you have any problems. And read them carefully.

Q: I still don't know how to set up the SuSEfirewall2
A: Read some good books about TCP/IP and firewalls

Q: What changed from SuSEfirewall(1) to SuSEfirewall2
A: Many things. Most important: it uses iptables (which is especially for
   2.4 kernels) instead of ipchains.
   Visible changes:
	New command line option "debug" which prints out the iptables commands,
	 great to print the rules, and them modify them for you liking!
	Added the new options:
	 FW_ALLOW_CLASS_ROUTING - allow routing between interfaces of the same
		class, e.g. two internal networks
	 FW_ALLOW_FW_BROADCAST - allow broadcast packets to reach the firewall
	 FW_IGNORE_FW_BROADCAST - drop but don't log broadcast packets
	 FW_ALLOW_PING_EXT - allow internal and dmz to ping the internet
	 FW_SERVICE_AUTODETECT - autodetect START_{NAMED,SMB,DHCPD} and DHCLIENT
	Renamed the variables:
	 FW_DEV_WORLD to FW_DEV_EXT
	 FW_REDIRECT_{TCP,UDP} to FW_REDIRECT
	 FW_FORWARD_MASQ_{TCP,UDP} to FW_FORWARD_MASQ
	 FW_FORWARD_{TCP,UDP,IP} to FW_FORWARD
	 FW_AUTOPROTECT_GLOBAL_SERVICES to FW_AUTOPROTECT_SERVICES
	 FW_SERVICES_{EXTERNAL,INTERNAL}_{TCP,UDP,IP} to FW_SERVICES_{EXT,INT}_{TCP,UDP,IP}
	Removed the variables:
	 FW_TRUSTED_ACL - now combined in FW_TRUSTED_NETS
	Changed configuration/behaviour:
	 The FW_FORWARD, FW_FORWARD_MASQ, FW_REDIRECT, FW_TRUSTED_NETS and
	  FW_MASQ_NETS now all support an extended syntax with optional
	  parameters. So you can make everything as fine-grained as you want!
	 The logging looks different - hell this is iptables :-(
	And of course the appearance changed a bit.
	It takes a bit longer to create the complex rule set :-(
   Invisible changes:
	A packet has to traverse much less rules, so packet processing is
	 faster.
	Stateful packet checking is present now (thanks to the 2.4 kernel)
	 and activated.
	More intelligent ICMP filtering and identd rejection

Q: Please name me some good books about TCP/IP and Firewalls.
 -or-
Q: What the hell is a "DMZ"?
A: Here are the most important books about the topics:
      Chapman/Zwicky: Building Internet Firewalls 2nd Ed., O'Reilly
      Bellovin/Cheswick: Firewalls and Internet Security, Addison Wesley
      Stevens: TCP/IP Illustrated I, Addison Wesley

Q: I want to allow access to my application XYZ on my firewall
A: These need to be set in FW_SERVICES_EXT_TCP
   The common problem is about what port the application uses.
   Let's say you are running an irc daemon and want to allow this service.
   Execute "lsof -i -n -P" and look for irc. You will see a line like this:
   ircd       1275 irc     5u  IPv4   3097       TCP *:6667 (LISTEN)
   This 6667 is the number you are looking for. Put this into e.g.
   FW_SERVICES_EXT_TCP and execute SuSEfirewall2 again.

Q: I want to allow access to application XYZ on my internal windows machine
   For this you have to use FW_FORWARD_MASQ and again, you need to find out
   the port numbers to put in there. Read the documentation of the application
   or run something like tcpdump to find this out.
   If you still have got problems - sorry, you are on your own here. Ask
   your friends. The EXAMPLES file shows you the syntax and some uses.

Q: I want to do IPSEC - what do I have to configure?
A: a) put the ipsec* devices into the same interface group (e.g. FW_DEV_EXT)
      where the real ipsec traffic ends on.
   b) you might want to set FW_FORWARD rules to allow access

Q: How can I reduce the generated rule set as most as possible?
A: 1. Only put in the network interfaces you really need.
   2. Disable Logging
   3  Set FW_PROTECT_FROM_INTERNAL to no
   4. Disable the service autoprotecting feature
   5. Set all FW_ALLOW_* and FW_SERVICE_* to no
   6. Do not use routing or masquerading :-)
   7. Only enable routing/services you really need and make the statements
      as general as possible to reduce the number of definitions.
   Then you will have got much less rules, but also a lesser security.
   Better spend 50$ on an old pentium processor + board and don't use an old
   486 as firewall!

Q: How can I be sure that after I dial-in to the internet, that the firewall
   rules are active?
A: If you have SuSE 7.3+, the /etc/ppp/ip-up will take care of this, however
   the INSTALL file of SuSEfirewall2 exchanges the ip-up anyway if no
   SuSEfirewall2 support is detected. so don't care.

Q: I'm still not feeling sure if my SuSEfirewall2 setup really protects me!
A: Run a port scanner against your firewall from the internet.

Q: How many interfaces are supported for each region (EXTERNAL/DMZ/INTERNAL)?
A: Any number you want

Q: But if I enter two internal network cards, communication between the two
   networks connected to the firewall is not possible. However both can
   access the internet. The SuSEfirewall2 must have a bug!
A: This works as designed. For security reasons, no network may communicate
   to another until configured otherwise. Even if both are "trusted"
   internal networks. You can allow full traffic with FW_ALLOW_CLASS_ROUTING
   or specifying all allowed traffic with FW_FORWARD

Q: I have set a web server in my DMZ. How do I configure SuSEfirewall2 to let
   people on the internet access my pages?
A: Same principle as above. Lets say your web server has got an official
   IP address of 1.1.1.1 which you received from your ISP. You would just
   configure FW_FORWARD_TCP like this:
    FW_FORWARD="0/0,1.1.1.1,tcp,80"

Q: Nice, but I don't have got an official IP address for the web server. I
   have only one, and thats my external Firewall IP address. What can I do?
A: You can use backward masquerading.
   For this you need to set FW_ROUTE and FW_MASQUERADE to "yes", and
   additionally FW_FORWARD_MASQ for the web servers private IP (lets say
   it is 10.0.0.1):
    FW_FORWARD_MASQ="0/0,10.0.0.1,tcp,80"

Q: When I connect to the internet via dial-on-demand (e.g. diald, or
   ippp0/ISDN) the command which activated the dial-on-demand feature
   fails (e.g. ping www.suse.com) with an error message, however the next
   try succeeds. Why?
A: Most time this is because it's the DNS lookup which fails. It fails
   because <expert talk on> your local resolver opens a UDP port to wait for
   a UDP answer from DNS servers it asks. When the feature
   FW_AUTOPROTECT_SERVICES is turned on, this will bite you, because after the
   dial-in is completed, the SuSEfirewall2 will protect that UDP port. hence
   no DNS answers can be processed, hence the initial command (e.g. ping)
   fails. <expert talk off>
   Solution: Set FW_AUTOPROTECT_SERVICES to "no" (BAD!!) or better set up
   a DNS server on the firewall which just acts as a cache or forwarder.

Q: I get some service not working. However it works if I disable the firewall.
A: Run SuSEfirewall2 in test mode: "SuSEfirewall2 test". Then try to connect
   to the service in a way which failed before. It will work because
   SuSEfirewall2 will *not* filter any packets. However, it will log all
   packets to syslog it normally would have filtered.
   So just check out the last lines in /var/log/firewall to see which ports
   you have to open/forward to get the service running with SuSEfirewall2.

Q: This is cool. All my problems are solved.
A: fine.

