I would like to start off by saying how much i love these howto's, they have helped me out more than anyone could know. Here is my problem that i have i just went through the whole setup of the Ubuntu-Server 6.10 As A Firewall/Gateway and for some reason i cannot connect to my vpn server. Here is the log file for then i try ty connect. Jan 18 10:57:05 fireviper pptpd[14298]: MGR: Manager process started Jan 18 10:57:05 fireviper pptpd[14298]: MGR: Maximum of 10 connections available Jan 18 10:57:11 fireviper kernel: [42952565.860000] Shorewall:net2fwROP:IN=eth0 OUT= MAC=00:07:95:de:47:5e:00:d0:b7:0e:70:f1:08:00 SRC=12.169.23.5 DST=192.168.2.1 LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=38144 DF PROTO=TCP SPT=45112 DPT=1723 WINDOW=65535 RES=0x00 SYN URGP=0 Jan 18 10:57:14 fireviper kernel: [42952568.820000] Shorewall:net2fwROP:IN=eth0 OUT= MAC=00:07:95:de:47:5e:00:d0:b7:0e:70:f1:08:00 SRC=12.169.23.5 DST=192.168.2.1 LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=38173 DF PROTO=TCP SPT=45112 DPT=1723 WINDOW=65535 RES=0x00 SYN URGP=0 Jan 18 10:57:20 fireviper kernel: [42952574.860000] Shorewall:net2fwROP:IN=eth0 OUT= MAC=00:07:95:de:47:5e:00:d0:b7:0e:70:f1:08:00 SRC=12.169.23.5 DST=192.168.2.1 LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=38195 DF PROTO=TCP SPT=45112 DPT=1723 WINDOW=65535 RES=0x00 SYN URGP=0 Thank You
Seems like a shorewall misconfiguration. Can you tell us a little more about your network setup? What's in shorewall's configuration file?
Vpn Connection Problems My network has a static outside ip address and a internal static of 192.168.1.1. Here is a copy of the syslog when i try to connect either with the firewall on or off. Jan 24 09:14:10 mathesfire steveo: Shorewall Stopped Jan 24 09:14:10 mathesfire steveo: Shorewall Cleared Jan 24 09:14:21 mathesfire pptpd[16966]: CTRL: Client 12.169.XXX.XXX control connection started Jan 24 09:14:21 mathesfire pptpd[16966]: CTRL: Starting call (launching pppd, opening GRE) Jan 24 09:14:21 mathesfire pppd[16967]: pppd 2.4.4 started by root, uid 0 Jan 24 09:14:21 mathesfire pppd[16967]: using channel 7 Jan 24 09:14:21 mathesfire pppd[16967]: Using interface ppp0 Jan 24 09:14:21 mathesfire pppd[16967]: Connect: ppp0 <--> /dev/pts/1 Jan 24 09:14:21 mathesfire pppd[16967]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <auth chap MS-v2> <magic 0x6f0aa0af> <pcomp> <accomp>] Jan 24 09:14:21 mathesfire pptpd[16966]: GRE: read(fd=7,buffer=80505a0,len=8260) from network failed: status = -1 error = Protocol not available Jan 24 09:14:21 mathesfire pptpd[16966]: CTRL: GRE read or PTY write failed (gre,pty)=(7,6) Jan 24 09:14:21 mathesfire pptpd[16966]: CTRL: Reaping child PPP[16967] Jan 24 09:14:22 mathesfire pppd[16967]: Modem hangup Jan 24 09:14:22 mathesfire pppd[16967]: Connection terminated. Jan 24 09:14:22 mathesfire pppd[16967]: Exit. Jan 24 09:14:22 mathesfire pptpd[16966]: CTRL: Client 12.169.XXX.XXX control connection finished root@mathesfire:/etc/shorewall# /etc/init.d/shorewall start Starting "Shorewall firewall": done. root@mathesfire:/etc/shorewall# tail -f /var/log/syslog Jan 24 09:14:35 mathesfire pppd[18749]: Using interface ppp0 Jan 24 09:14:35 mathesfire pppd[18749]: Connect: ppp0 <--> /dev/pts/1 Jan 24 09:14:35 mathesfire pppd[18749]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <auth chap MS-v2> <magic 0xbb8ac80b> <pcomp> <accomp>] Jan 24 09:14:35 mathesfire pptpd[18748]: GRE: xmit failed from decaps_hdlc: Operation not permitted Jan 24 09:14:35 mathesfire pptpd[18748]: CTRL: PTY read or GRE write failed (pty,gre)=(6,7) Jan 24 09:14:35 mathesfire pptpd[18748]: CTRL: Reaping child PPP[18749] Jan 24 09:14:35 mathesfire pppd[18749]: Modem hangup Jan 24 09:14:35 mathesfire pppd[18749]: Connection terminated. Jan 24 09:14:35 mathesfire pppd[18749]: Exit. Jan 24 09:14:35 mathesfire pptpd[18748]: CTRL: Client 12.169.XXX.XXX control connection finished AND HERE IS THE SHOREWALL CONFIG FILE ############################################################################### # /etc/shorewall/shorewall.conf V3.0 - Change the following variables to # match your setup # # This program is under GPL [http://www.gnu.org/copyleft/gpl.htm] # # This file should be placed in /etc/shorewall # # (c) 1999,2000,2001,2002,2003,2004,2005 - Tom Eastep ([email protected]) # # >>>>>>>>>>>>> NOTE TO USERS UPGRADING FROM 2.x <<<<<<<<<<<<<<<<<< # # Most problems associated with upgrades come from two causes: # # - The user didn't read and follow the migration considerations in the # release notes. # # - The user mis-handled the /etc/shorewall/shorewall.conf file during # upgrade. Shorewall is designed to allow the default behavior of # the product to evolve over time. To make this possible, the design # assumes that you will not replace your current shorewall.conf file # during upgrades. If you feel absolutely compelled to have the latest # comments and options in your shorewall.conf then you must proceed # carefully. # # The new/changed options in shorewall 3.0 are listed below. If you don't # want to convert to the new 3.0 format for /etc/shorewall/zones and you # don't want to replace your current rules that use 2.x builtin actions, # then if you plan to use this copy of shorewall.conf file then you must # change it as follows: # # - SPECFILE # # This file has IPSECFILE=zones. You want to set it to IPSECFILE=ipsec. # This will indicate that your /etc/shorewall/zones file is in the # pre-3.0 format. # # - FW # # This file has FW undefined. If you have named your firewall zone # something other than 'fw' then you must set FW accordingly. # # - MAPOLDACTIONS # # This file has MAPOLDACTIONS=No. You want to set it to # MAPOLDACTIONS=Yes in order to permit rules that use the 2.x builtin # actions such as AllowPing to continue to work. ############################################################################### # S T A R T U P E N A B L E D ############################################################################### # # Once you have configured Shorewall, you may change the setting of # this variable to 'Yes' # STARTUP_ENABLED=Yes ############################################################################### # L O G G I N G ############################################################################### # # General note about log levels. Log levels are a method of describing # to syslog (8) the importance of a message and a number of parameters # in this file have log levels as their value. # # These levels are defined by syslog and are used to determine the destination # of the messages through entries in /etc/syslog.conf (5). The syslog # documentation refers to these as "priorities"; Netfilter calls them "levels" # and Shorewall also uses that term. # # Valid levels are: # # 7 debug # 6 info # 5 notice # 4 warning # 3 err # 2 crit # 1 alert # 0 emerg # # For most Shorewall logging, a level of 6 (info) is appropriate. Shorewall # log messages are generated by NetFilter and are logged using facility # 'kern' and the level that you specifify. If you are unsure of the level # to choose, 6 (info) is a safe bet. You may specify levels by name or by # number. # # If you have built your kernel with ULOG target support, you may also # specify a log level of ULOG (must be all caps). Rather than log its # messages to syslogd, Shorewall will direct netfilter to log the messages # via the ULOG target which will send them to a process called 'ulogd'. # ulogd is available with most Linux distributions (although it probably isn't # installed by default). Ulogd is also available from # http://www.gnumonks.org/projects/ulogd and can be configured to log all # Shorewall message to their own log file ############################################################################### # # LOG FILE LOCATION # # This variable tells the /sbin/shorewall program where to look for Shorewall # log messages. If not set or set to an empty string (e.g., LOGFILE="") then # /var/log/messages is assumed. # # WARNING: The LOGFILE variable simply tells the 'shorewall' program where to # look for Shorewall messages.It does NOT control the destination for # these messages. For information about how to do that, see # # http://www.shorewall.net/shorewall_logging.html # LOGFILE=/var/log/messages # # LOG FORMAT # # Shell 'printf' Formatting template for the --log-prefix value in log messages # generated by Shorewall to identify Shorewall log messages. The supplied # template is expected to accept either two or three arguments; the first is # the chain name, the second (optional) is the logging rule number within that # chain and the third is the ACTION specifying the disposition of the packet # being logged. You must use the %d formatting type for the rule number; if # your template does not contain %d then the rule number will not be included. # # If you want to integrate Shorewall with fireparse, then set LOGFORMAT as: # # LOGFORMAT="fp=%s:%d a=%s " # # If not specified or specified as empty (LOGFORMAT="") then the value # "Shorewall:%s:%s:" is assumed. # # CAUTION: /sbin/shorewall uses the leading part of the LOGFORMAT string (up # to but not including the first '%') to find log messages in the 'show log', # 'status' and 'hits' commands. This part should not be omitted (the # LOGFORMAT should not begin with "%") and the leading part should be # sufficiently unique for /sbin/shorewall to identify Shorewall messages. # LOGFORMAT="Shorewall:%s:%s:" # # LOG FORMAT Continued # # Using the default LOGFORMAT, chain names may not exceed 11 characters or # truncation of the log prefix may occur. Longer chain names may be used with # log tags if you set LOGTAGONLY=Yes. With LOGTAGONLY=Yes, if a log tag is # specified then the tag is included in the log prefix in place of the chain # name. # LOGTAGONLY=No # # LOG RATE LIMITING # # The next two variables can be used to control the amount of log output # generated. LOGRATE is expressed as a number followed by an optional # `/second', `/minute', `/hour', or `/day' suffix and specifies the maximum # rate at which a particular message will occur. LOGBURST determines the # maximum initial burst size that will be logged. If set empty, the default # value of 5 will be used. #
# If BOTH variables are set empty then logging will not be rate-limited. # # Example: # # LOGRATE=10/minute # LOGBURST=5 # LOGRATE=10/minute # LOGBURST=5 # # For each logging rule, the first time the rule is reached, the packet # will be logged; in fact, since the burst is 5, the first five packets # will be logged. After this, it will be 6 seconds (1 minute divided by # the rate of 10) before a message will be logged from the rule, regardless # of how many packets reach it. Also, every 6 seconds which passes without # matching a packet, one of the bursts will be regained; if no packets hit # the rule for 30 seconds, the burst will be fully recharged; back where # we started. # LOGRATE= LOGBURST= # # LOG ALL NEW # # This option should only be used when you are trying to analyze a problem. # It causes all packets in the Netfilter NEW state to be logged as the # first rule in each builtin chain. To use this option, set LOGALLNEW to # the log level that you want these packets logged at (e.g., # LOGALLNEW=debug). # LOGALLNEW= # # BLACKLIST LOG LEVEL # # Set this variable to the syslogd level that you want blacklist packets logged # (beware of DOS attacks resulting from such logging). If not set, no logging # of blacklist packets occurs. # # See the comment at the top of this section for a description of log levels # BLACKLIST_LOGLEVEL= # # MAC List Log Level # # Specifies the logging level for connection requests that fail MAC # verification. If set to the empty value (MACLIST_LOG_LEVEL="") then # such connection requests will not be logged. # # See the comment at the top of this section for a description of log levels # MACLIST_LOG_LEVEL=info # # TCP FLAGS Log Level # # Specifies the logging level for packets that fail TCP Flags # verification. If set to the empty value (TCP_FLAGS_LOG_LEVEL="") then # Specifies the logging level for packets that fail TCP Flags # verification. If set to the empty value (TCP_FLAGS_LOG_LEVEL="") then # such packets will not be logged. # # See the comment at the top of this section for a description of log levels # TCP_FLAGS_LOG_LEVEL=info # # RFC1918 Log Level # # Specifies the logging level for packets that fail RFC 1918 # verification. If set to the empty value (RFC1918_LOG_LEVEL="") then # RFC1918_LOG_LEVEL=info is assumed. # # See the comment at the top of this section for a description of log levels # RFC1918_LOG_LEVEL=info # # SMURF Log Level # # Specifies the logging level for smurf packets dropped by the #'nosmurfs' interface option in /etc/shorewall/interfaces and in # /etc/shorewall/hosts. If set to the empty value ( SMURF_LOG_LEVEL="" # ) then dropped smurfs are not logged. # # See the comment at the top of this section for a description of log levels # SMURF_LOG_LEVEL=info # # MARTIAN LOGGING # # Setting LOG_MARTIANS=Yes will enable kernel logging of all received packets # that have impossible source IP addresses. This logging may be enabled # on individual interfaces by using the 'logmartians' option in # /etc/shorewall/interfaces. # LOG_MARTIANS=No ############################################################################### # L O C A T I O N O F F I L E S A N D D I R E C T O R I E S ############################################################################### # # IPTABLES # # Full path to iptables executable Shorewall uses to build the firewall. If # not specified or if specified with an empty value (e.g., IPTABLES="") then # the iptables executable located via the PATH setting below is used. # IPTABLES= IPTABLES= # # PATH - Change this if you want to change the order in which Shorewall # searches directories for executable files. # PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin # # SHELL # # The firewall script is normally interpreted by /bin/sh. If you wish to change # the shell used to interpret that script, specify the shell here. # SHOREWALL_SHELL=/bin/sh # SUBSYSTEM LOCK FILE # # Set this to the name of the lock file expected by your init scripts. For # RedHat, this should be /var/lock/subsys/shorewall. If your init scripts don't # use lock files, set this to "". # SUBSYSLOCK="" # # KERNEL MODULE DIRECTORY # # If your netfilter kernel modules are in a directory other than # /lib/modules/$(uname -r)/kernel/net/ipv4/netfilter then specify that # directory in this variable. Example: MODULESDIR=/etc/modules. # MODULESDIR= # # CONFIGURATION SEARCH PATH # # This option holds a list of directory names separated by colons # (":"). Shorewall will search each directory in turn when looking for a # configuration file. When processing a 'try' command or a command # containing the "-c" option or that specifies a configuration directory, # Shorewall will automatically add the directory specified in the command # to the front of this list. # # If not specified or specified as null ("CONFIG_PATH=""), # CONFIG_PATH=/etc/shorewall:/usr/share/shorewall is assumed. # CONFIG_PATH=/etc/shorewall:/usr/share/shorewall # # RESTORE SCRIPT # # RESTORE SCRIPT # # This option determines the script to be run in the following cases: # # shorewall -f start # shorewall restore # shorewall save # shorewall forget # Failure of shorewall start or shorewall restart # # The value of the option must be the name of an executable file in the # directory /var/lib/shorewall. If this option is not set or if it is # set to the empty value (RESTOREFILE="") then RESTOREFILE=restore is # assumed. # RESTOREFILE= # # OLD ZONE FILE FORMAT # # Previous versions of Shorewall had both a 'zones' file and an 'ipsec' file. # Beginning with 2.5.0, those files were combined. For users who haven't # converted, we offer this variable that sets the name of the file for ipsec # information. This option must take the value "zones" or "ipsec". If the # option is not set or is set to the empty value (IPSECFILE="") then "ipsec" # is assumed. # IPSECFILE=zones ############################################################################### # F I R E W A L L O P T I O N S ############################################################################### # NAME OF THE FIREWALL ZONE # # Name of the firewall zone -- if not set or if set to an empty string, then # you must include a definition of the firewall zone in /etc/shorewall/zones. # # Note: If IPSECFILE=zones above then you must NOT set FW and you must define # the firewall zone in /etc/shorewall/zones. FW= # # ENABLE IP FORWARDING # # If you say "On" or "on" here, IPV4 Packet Forwarding is enabled. If you # say "Off" or "off", packet forwarding will be disabled. You would only want # to disable packet forwarding if you are installing Shorewall on a # standalone system or if you want all traffic through the Shorewall system # to be handled by proxies. # # If you set this variable to "Keep" or "keep", Shorewall will neither # enable nor disable packet forwarding. # # enable nor disable packet forwarding. # IP_FORWARDING=On # # AUTOMATICALLY ADD NAT IP ADDRESSES # # If you say "Yes" or "yes" here, Shorewall will automatically add IP addresses # for each NAT external address that you give in /etc/shorewall/nat. If you say # "No" or "no", you must add these aliases youself. # # WARNING: Addresses added by ADD_IP_ALIASES=Yes are deleted and re-added # during processing of the "shorewall restart" command. As a consequence, # connections using those addresses may be severed. # ADD_IP_ALIASES=Yes # # AUTOMATICALLY ADD SNAT IP ADDRESSES # # If you say "Yes" or "yes" here, Shorewall will automatically add IP addresses # for each SNAT external address that you give in /etc/shorewall/masq. If you # say "No" or "no", you must add these aliases youself. LEAVE THIS SET TO "No" # unless you are sure that you need it -- most people don't!!! # # WARNING: Addresses added by ADD_SNAT_ALIASES=Yes are deleted and re-added # during processing of the "shorewall restart" command. As a consequence, # connections using those addresses may be severed. # ADD_SNAT_ALIASES=No # # RETAIN EXISTING ALIASES/IP ADDRESSES # # Normally, when ADD_IP_ALIASES=Yes and/or ADD_SNAT_ALIASES=Yes then Shorewall # will first delete the address then re-add it. This is to ensure that the # address is added with the specified label. Unfortunately, this can cause # problems if it results in the deletion of the last IP address on an # interface because then all routes through the interface are automatically # removed. # # You can cause Shorewall to retain existing addresses by setting # RETAIN_ALIASES=Yes. #
RETAIN_ALIASES=No # # ENABLE TRAFFIC SHAPING # # If you say "Yes" or "yes" here, Shorewall will use a script that you # supply to configure traffic shaping. The script must be named 'tcstart' # and must be placed in a directory on your CONFIG_PATH. # # and must be placed in a directory on your CONFIG_PATH. # # If you say "No" or "no" then traffic shaping is not enabled. # # If you set TC_ENABLED=Internal or internal or leave the option empty then # Shorewall will use its builtin traffic shaper (tc4shorewall written by # Arne Bernin). # # See http://shorewall.net/traffic_shaping.htm for more information. TC_ENABLED=Internal # # Clear Traffic Shapping/Control # # If this option is set to 'No' then Shorewall won't clear the current # traffic control rules during [re]start. This setting is intended # for use by people that prefer to configure traffic shaping when # the network interfaces come up rather than when the firewall # is started. If that is what you want to do, set TC_ENABLED=No and # CLEAR_TC=No and do not supply an /etc/shorewall/tcstart file. That # way, your traffic shaping rules can still use the 'fwmark' # classifier based on packet marking defined in /etc/shorewall/tcrules. # # If omitted, CLEAR_TC=Yes is assumed. # CLEAR_TC=Yes # # Mark Packets in the forward chain # # When processing the tcrules file, Shorewall normally marks packets in the # PREROUTING chain. To cause Shorewall to use the FORWARD chain instead, set # this to "Yes". If not specified or if set to the empty value (e.g., # MARK_IN_FORWARD_CHAIN="") then MARK_IN_FORWARD_CHAIN=No is assumed. # # Marking packets in the FORWARD chain has the advantage that inbound # packets destined for Masqueraded/SNATed local hosts have had their # destination address rewritten so they can be marked based on their # destination. When packets are marked in the PREROUTING chain, packets # destined for Masqueraded/SNATed local hosts still have a destination address # corresponding to the firewall's external interface. # # Note: Older kernels do not support marking packets in the FORWARD chain and # setting this variable to Yes may cause startup problems. # MARK_IN_FORWARD_CHAIN=No # # MSS CLAMPING # # Set this variable to "Yes" or "yes" if you want the TCP "Clamp MSS to PMTU" # option. This option is most commonly required when your internet # interface is some variant of PPP (PPTP or PPPoE). Your kernel must # have CONFIG_IP_NF_TARGET_TCPMSS set. # interface is some variant of PPP (PPTP or PPPoE). Your kernel must # have CONFIG_IP_NF_TARGET_TCPMSS set. # # [From the kernel help: # # This option adds a `TCPMSS' target, which allows you to alter the # MSS value of TCP SYN packets, to control the maximum size for that # connection (usually limiting it to your outgoing interface's MTU # minus 40). # # This is used to overcome criminally braindead ISPs or servers which # block ICMP Fragmentation Needed packets. The symptoms of this # problem are that everything works fine from your Linux # firewall/router, but machines behind it can never exchange large # packets: # 1) Web browsers connect, then hang with no data received. # 2) Small mail works fine, but large emails hang. # 3) ssh works fine, but scp hangs after initial handshaking. # ] # # If left blank, or set to "No" or "no", the option is not enabled. # # You may also set this option to a numeric value in which case Shorewall will # set up a rule to modify the MSS value in SYN packets to the value that # you specify. # # Example: # # CLAMPMSS=1400 # CLAMPMSS=No # # ROUTE FILTERING # # Set this variable to "Yes" or "yes" if you want kernel route filtering on all # interfaces started while Shorewall is started (anti-spoofing measure). # # If this variable is not set or is set to the empty value, "No" is assumed. # Regardless of the setting of ROUTE_FILTER, you can still enable route # filtering on individual interfaces using the 'routefilter' option in the # /etc/shorewall/interfaces file. # ROUTE_FILTER=Yes # # DNAT IP ADDRESS DETECTION # # Normally when Shorewall encounters the following rule: # # DNAT net loc:192.168.1.3 tcp 80 # # it will forward TCP port 80 connections from the net to 192.168.1.3 # REGARDLESS OF THE ORIGINAL DESTINATION ADDRESS. This behavior is # convenient for two reasons: # REGARDLESS OF THE ORIGINAL DESTINATION ADDRESS. This behavior is # convenient for two reasons: # # a) If the the network interface has a dynamic IP address, the # firewall configuration will work even when the address # changes. # # b) It saves having to configure the IP address in the rule # while still allowing the firewall to be started before the # internet interface is brought up. # # This default behavior can also have a negative effect. If the # internet interface has more than one IP address then the above # rule will forward connection requests on all of these addresses; # that may not be what is desired. # # By setting DETECT_DNAT_IPADDRS=Yes, rules such as the above will apply # only if the original destination address is the primary IP address of # one of the interfaces associated with the source zone. Note that this # requires all interfaces to the source zone to be up when the firewall # is [re]started. # DETECT_DNAT_IPADDRS=No # # MUTEX TIMEOUT # # The value of this variable determines the number of seconds that programs # will wait for exclusive access to the Shorewall lock file. After the number # of seconds corresponding to the value of this variable, programs will assume # that the last program to hold the lock died without releasing the lock. # # If not set or set to the empty value, a value of 60 (60 seconds) is assumed. # # An appropriate value for this parameter would be twice the length of time # that it takes your firewall system to process a "shorewall restart" command. # MUTEX_TIMEOUT=60 # # FOR ADMINS THAT REPEATEDLY SHOOT THEMSELVES IN THE FOOT # # Normally, when a "shorewall stop" command is issued or an error occurs during # the execution of another shorewall command, Shorewall puts the firewall into # a state where only traffic to/from the hosts listed in # /etc/shorewall/routestopped is accepted. # # When performing remote administration on a Shorewall firewall, it is # therefore recommended that the IP address of the computer being used for # administration be added to the firewall's /etc/shorewall/routestopped file. # # Some administrators have a hard time remembering to do this with the result # that they get to drive across town in the middle of the night to restart # a remote firewall (or worse, they have to get someone out of bed to drive # across town to restart a very remote firewall). # a remote firewall (or worse, they have to get someone out of bed to drive # across town to restart a very remote firewall). # # For those administrators, we offer ADMINISABSENTMINDED=Yes. With this # setting, when the firewall enters the 'stopped' state: # # All traffic that is part of or related to established connections is still # allowed and all OUTPUT traffic is allowed. This is in addition to traffic # to and from hosts listed in /etc/shorewall/routestopped. # # If this variable is not set or it is set to the null value then # ADMINISABSENTMINDED=No is assumed. # ADMINISABSENTMINDED=Yes
# # BLACKLIST Behavior # # Shorewall offers two types of blacklisting: # # - static blacklisting through the /etc/shorewall/blacklist file # together with the 'blacklist' interface option. # - dynamic blacklisting using the 'drop', 'reject' and 'allow' commands. # # The following variable determines whether the blacklist is checked for each # packet or for each new connection. # # BLACKLISTNEWONLY=Yes Only consult blacklists for new connection # requests # # BLACKLISTNEWONLY=No Consult blacklists for all packets. # # If the BLACKLISTNEWONLY option is not set or is set to the empty value then # BLACKLISTNEWONLY=No is assumed. # BLACKLISTNEWONLY=Yes # # Users with a large blacklist find that "shorwall [re]start" takes a long # time and that new connections are disabled during that time. By setting # DELAYBLACKLISTLOAD=Yes, you can cause Shorewall to enable new connections # before loading the blacklist. # DELAYBLACKLISTLOAD=No # MODULE NAME SUFFIX # # When loading a module named in /etc/shorewall/modules, Shorewall normally # looks in the MODULES DIRECTORY (see MODULESDIR above) for files whose names # end in ".o", ".ko", ".gz", "o.gz" or "ko.gz" . If your distribution uses a # different naming convention then you can specify the suffix (extension) for # module names in this variable. # # To see what suffix is used by your distribution: # # To see what suffix is used by your distribution: # # ls /lib/modules/$(uname -r)/kernel/net/ipv4/netfilter # # All of the file names listed should have the same suffix (extension). Set # MODULE_SUFFIX to that suffix. # # Examples: # # If all file names end with ".kzo" then set MODULE_SUFFIX="kzo" # If all file names end with ".kz.o" then set MODULE_SUFFIX="kz.o" # MODULE_SUFFIX= # # DISABLE IPV6 # # Distributions (notably SuSE) are beginning to ship with IPV6 # enabled. If you are not using IPV6, you are at risk of being # exploited by users who do. Setting DISABLE_IPV6=Yes will cause # Shorewall to disable IPV6 traffic to/from and through your # firewall system. This requires that you have ip6tables installed. DISABLE_IPV6=Yes # # BRIDGING # # If you wish to restrict connections through a bridge # (see http://bridge.sf.net), then set BRIDGING=Yes. Your kernel must have # the physdev match option enabled; that option is available at the above URL # for 2.4 kernels and is included as a standard part of the 2.6 series # kernels. If not specified or specified as empty (BRIDGING="") then "No" is # assumed. # BRIDGING=No # # DYNAMIC ZONES # # If you need to be able to add and delete hosts from zones dynamically then # set DYNAMIC_ZONES=Yes. Otherwise, set DYNAMIC_ZONES=No. DYNAMIC_ZONES=No # # USE PKTTYPE MATCH # # Some users have reported problems with the PKTTYPE match extension not being # able to match certain broadcast packets. If you set PKTTYPE=No then Shorewall # will use IP addresses to detect broadcasts rather than pkttype. If not given # or if given as empty (PKTTYPE="") then PKTTYPE=Yes is assumed. # # PKTTYPE=Yes # # RFC 1918 BEHAVIOR # # Traditionally, the RETURN target in the 'rfc1918' file has caused 'norfc1918' # processing to cease for a packet if the packet's source IP address matches # the rule. Thus, if you have: # # SUBNETS TARGET # 192.168.1.0/24 RETURN # # then traffic from 192.168.1.4 to 10.0.3.9 will be accepted even though you # also have: # # SUBNETS TARGET # 10.0.0.0/8 logdrop # # Setting RFC1918_STRICT=Yes will cause such traffic to be logged and dropped # since while the packet's source matches the RETURN rule, the packet's # destination matches the 'logdrop' rule. # # If not specified or specified as empty (e.g., RFC1918_STRICT="") then # RFC1918_STRICT=No is assumed. # # WARNING: RFC1918_STRICT=Yes requires that your kernel and iptables support # 'conntrack state' match. # RFC1918_STRICT=No # # MAC List Table # # Normally, MAC verification occurs in the filter table (INPUT and FORWARD) # chains. When forwarding a packet from an interface with MAC verification # to a bridge interface, that doesn't work. # # This problem can be worked around by setting MACLIST_TABLE=mangle which # will cause Mac verification to occur out of the PREROUTING chain. Because # REJECT isn't available in that environment, you may not specify # MACLIST_DISPOSITION=REJECT with MACLIST_TABLE=mangle. MACLIST_TABLE=filter # # MACLIST caching # # If your iptables and kernel support the "Recent Match" (see the output of # "shorewall check" near the top), you can cache the results of a 'maclist' # file lookup and thus reduce the overhead associated with MAC Verification # (/etc/shorewall/maclist). # # When a new connection arrives from a 'maclist' interface, the packet passes # through the list of entries for that interface in /etc/shorewall/maclist. If # When a new connection arrives from a 'maclist' interface, the packet passes # through the list of entries for that interface in /etc/shorewall/maclist. If # there is a match then the source IP address is added to the 'Recent' set for # that interface. Subsequent connection attempts from that IP address occuring # within $MACLIST_TTL seconds will be accepted without having to scan all of # the entries. After $MACLIST_TTL from the first accepted connection request, # the next connection request from that IP address will be checked against # the entire list. # # If MACLIST_TTL is not specified or is specified as empty (e.g, # MACLIST_TTL="" or is specified as zero then 'maclist' lookups will not # be cached. # MACLIST_TTL= # # Save/Restore IPSETS # # If SAVE_IPSETS=Yes then Shorewall will: # # Restore the last saved ipset contents during "shorewall [re]start" # Save the current ipset contents during "shorewall save" # # Regardless of the setting of SAVE_IPSETS, if ipset contents were # saved during a "shorewall save" then they will be restored during # a subsequent "shorewall restore". # SAVE_IPSETS=No # # Map Old Actions # # Previously, Shorewall included a large number of standard actions (AllowPing, # AllowFTP, ...). These have been replaced with parameterized macros. For # compatibility, Shorewall can map the old names into invocations of the new # macros if you set MAPOLDACTIONS=Yes. If this option is not set or is set to # the empty value (MAPOLDACTIONS="") then MAPOLDACTIONS=Yes is assumed # MAPOLDACTIONS=No # # Fast ESTABLISHED/RELATED handling # # Normally, Shorewall accepting ESTABLISHED/RELATED packets until these packets # reach the chain in which the original connection was accepted. So for packets # going from the 'loc' zone to the 'net' zone, ESTABLISHED/RELATED packets are # ACCEPTED in the 'loc2net' chain. # # If you set FASTACCEPT=Yes, then ESTABLISHED/RELEATED packets are accepted # early in the INPUT, FORWARD and OUTPUT chains. If you set # FASTACCEPT=Yes then you may not include rules in the ESTABLISHED and # RELATED sections of the rules file. FASTACCEPT=No FASTACCEPT=No ############################################################################### # P A C K E T D I S P O S I T I O N ############################################################################### # # BLACKLIST DISPOSITION # # Set this variable to the action that you want to perform on packets from # Blacklisted systems. Must be DROP or REJECT. If not set or set to empty, # DROP is assumed. # BLACKLIST_DISPOSITION=DROP # # MAC List Disposition # # This variable determines the disposition of connection requests arriving # on interfaces that have the 'maclist' option and that are from a device # that is not listed for that interface in /etc/shorewall/maclist. Valid # values are ACCEPT, DROP and REJECT. If not specified or specified as # empty (MACLIST_DISPOSITION="") then REJECT is assumed # MACLIST_DISPOSITION=REJECT # # TCP FLAGS Disposition # # This variable determins the disposition of packets having an invalid # combination of TCP flags that are received on interfaces having the # 'tcpflags' option specified in /etc/shorewall/interfaces or in # /etc/shorewall/hosts. If not specified or specified as empty # (TCP_FLAGS_DISPOSITION="") then DROP is assumed. # TCP_FLAGS_DISPOSITION=DROP #LAST LINE -- DO NOT REMOVE
Hi, I'm glad you like my article, sorry for the late response. if I'm not mistaken your eth1 is at 192.168.1.1 But the firewall drops a request to 192.168.2.1 Thats obviously a clou. What's the content of your /etc/network/interfaces?
