PGNd | 20 Aug 17:05 2014

overriding traffic DROP:P'd in /conntrack. when/where to ACCEPT?

I use IPSETs in SW for mass access blocking.  The block's in /conntrack

		DROP:P      +IPPESTS_IP              -
		DROP:P      +IPPESTS_NET             -

Those blacklists are populated by exernal feeds.  I do not edit/modify individual elements; simply
retrieve the data and load the IPSETs.

It works as expected.

I want to punch a specific hole for accessing webcontent, from my LAN,  <at>  a specific IP range that's been
blanket-included in the above blacklist.

I create a hash:ip & hash:ip IPSETs containing the ip range to be whitelisted, and allow the traffic in /rules


This does NOT open the access; it remains blocked.

I suspect it's because the DROP:P is in pre-routing chain, and I'm not ACCEPTing early enough.

(Continue reading)

Tom Eastep | 20 Aug 02:29 2014

Shorewall 4.6.3

The Shorewall team is happy to announce the availability of Shorewall 4.6.3.

Problems Corrected:

1)  This release contains defect repair up through release

2)  The SAVE_IPSETS option in the Debian version of Shorewall-init now
    works correctly. Thomas D.
New Features:

1)  A new 'run' command has been implemented. This command allows you
    to run an arbitrary command in the context of the generated

       shorewall[6][-lite] run <command> [ <parameter> ... ]

    Normally, <command> will be a function declared in lib.private.

2)  A DNSAmp action has been added. This action matches recursive UDP
    DNS queries. The default disposition is DROP which can be
    overridden by the single action parameter (e.g, 'DNSAmp(REJECT)'
    will reject these queries). Recursive DNS queries are the basis for
    'DNS Amplification' attacks; hence the action name.

Thank you for using Shorewall,


Tom Eastep        \ When I die, I want to go like my Grandfather who
Shoreline,         \ died peacefully in his sleep. Not screaming like
(Continue reading)

Emiliano Vazquez | 19 Aug 13:41 2014

Best way to block

Hi guys.

I'm reading how is the best way to block some IPs on the network to get 
http/https access. I will send all the traffic trough proxy and need to 
block those users who eliminate the proxy setting.

In Shorewall Blacklist [1] says: "The use of this file is deprecated and 
beginning with Shorewall 4.5.7, the file is no longer installed"

I want ask what is the best way to do this today.

Best regards.



Emiliano Vazquez | PcCentro Informatica & CCTV
Office: +54 (11) 4635-3218 y Rotativas
Movil: 011-15-6253-7165
Mail: emilianovazquez <at>

PGNd | 18 Aug 02:10 2014

shorewall-init usage with centrally-administered firewall mgmt? which PRODUCTS, and where to install?

Reading at 

	"Closing the Firewall before the Network Interfaces are brought up"

The docs include

	There are two settings in the file:
	    Lists the Shorewall packages that you want to integrate with Shorewall-init.
	    Example: PRODUCTS="shorewall shorewall6"

That param is to be def'd, for opensuse, in


I'm using a central administrative system, running shorewall/shorewall6, and pushing to remotes
running shorewall-lite/shorewall6-lite.

Which PRODUCTS should be defined?

	PRODUCTS="shorewall shorewall6"

since I'm 'integrating' with the compiler on the administrative system running those?

(Continue reading)

PGNd | 16 Aug 20:28 2014

Best practices for daemon dependency management & dynamic IP handling?

On my linux/64 edge router/firewall, I run


shorewall-lite is configured as MultiISP with 2 providers:

	* a StaticIP broadband ISP
	* an OpenVPN connection

That StaticIP will change soon to a non-static, dynamically (as defined by the ISP) allocated IP.

I'd appreciate 2 bits of help:

	(1) a review of my startup dependencies
	(2) best practice for dealing with Dynamic IP -- in shorewall-lite (and elsewhere?) is it still 'lsm'?

Nothing's broken, and I'm not looking to fix an immediate problem; I'm looking for a 2nd set of eyes, and some
chat about best practices.

Re: Startup Dependencies ...

All services are managed by systemd.

I've set up a 'jungle' of dependencies to try to make sure that startup  <at>  boot is functional & efficient.  I've
3 criteria that I'm trying to meet:

(Continue reading)

Tom Eastep | 14 Aug 17:00 2014


Shorewall is now available for download.

Problems Corrected:

1)  Previously, when an interface specified the 'physical=' option and
    the physical interface name was specified in the INTERFACES column
    of the providers file, compilation would fail with diagnostics
    similar to the following:

	Use of uninitialized value $physical in pattern match
	  (m//) at /usr/lib/perl5/vendor_perl/5.18.1/
          Shorewall/ line 463, <$currentfile> line 2.
 	 ERROR: A provider interface must have at least one
	        associated zone /opt/etc/shorewall/providers (line 2)

2)  Shorewall-init now works correctly on systems with systemd.
    By Louis Lagendijk.

Thank you for using Shorewall,

Tom Eastep        \ When I die, I want to go like my Grandfather who
Shoreline,         \ died peacefully in his sleep. Not screaming like
Washington, USA     \ all of the passengers in his car \________________________________________________

(Continue reading)

Mark D. Montgomery II | 14 Aug 00:06 2014

nfcapd with shorewall?

I'm trying to get nfsen setup on my router/firewall box and I'm  
running into the issue where nfcapd is not generating any data.
All my searching around basically seems to come down to people saying  
firewalls sometimes block it from working (without much more data than  
that or any resolutions).
The only other thing I found was someone saying to disable rp_filter  
on the interfaces, but that is already disabled on all mine (it's only  
enabled on eth0 via shorewall).

Does anyone have any experience with nfsen/nfcapd that could point me  
in the right direction to getting it to play happy with shorewall and  
actually see my network traffic?

For those not familiar with nfsen it is a management tool/interface  
that launches nfcapd and uses nfdump to generate rrd graphs and such  
nice things.

In case it is relevant: eth0 is my external interface and eth1-eth5  
and tun0 are the internal interfaces on the machine.



Mark D. Montgomery II

Attachment: application/pgp-keys, 3323 bytes
(Continue reading)

PGNd | 13 Aug 23:26 2014

after upgrade of distro-shorewall ->, compile "ERROR: Invalid/Unknown leaf-1 port/service (tcp) "

After an upgrade from Opensuse_13.1-packaged shorewall ->

	grep "shorewall|" * | tail -n 2
		2014-08-08 07:30:05|install|shorewall||noarch||Netfilter|8a7f834d22683013aba57ba4548d97fc53eb64e0b562cbdf65e716544aba45ba|
		2014-08-12 11:09:47|install|shorewall||noarch||Netfilter|d7401c67c1d548fdcacde9ab9b3de94a7d87ed45e248aeef49a02e6b40da7193|

When I simply recompile my previously working rulesets etc, I now get an error

   ERROR: Invalid/Unknown leaf-1 port/service (tcp) /usr/local/etc/shorewall/IPv4/masq (line 20)


	cat /masq
20			EXTIF  $MX_INT  $MX_EXT  tcp  25,587

This works prior to the upgrade.

The recent local changelog includes,

	rpm -q --changelog shorewall
		* Mon Aug 11 2014 toganm <at>
		- Backported PHYSICALNAME.patch
		* Fri Aug 08 2014 toganm <at>
		- Update to version For more details see changelog.txt and
		  + Previously, inline matches were not allowed in action files, even
		    though the documentation stated that they were allowed.
(Continue reading)

CACook | 12 Aug 21:53 2014

FTP Stopped Working

For some reason my ftp no longer works. (Ubuntu Raring, kernel 3.14-1-amd64, Sw

I can clearly see that Shorewall is blocking passive ftp attempts, but I don't know what to do about it.  Connexion tracking doesn't seem to be working.

I've gone through but I see nothing I'm doing wrong.  I do have nf_conntrack_ftp and nf_nat_ftp loaded.  In rules:
ACCEPT    $FW    net        tcp    ...,ftp,ftps,...    -

$ ftp 192.154.143.???                                                                   
Connected to 192.154.143.???.                                                                       
220---------- Welcome to Pure-FTPd [privsep] [TLS] ----------                                       
220-You are user number 8 of 50 allowed.                                                            
220-Local time is now 12:05. Server port: 21.                                                       
220-This is a private system - No anonymous login                                                   
220-IPv6 connections are also welcome on this server.                                               
220 You will be disconnected after 15 minutes of inactivity.                                        
Name (192.154.143.???:geo): delb                                                               
331 User delb OK. Password required                                                             
230 OK. Current restricted directory is /
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> debug
Debugging on (debug=1).
ftp> passive
Passive mode on.
ftp> ls
ftp: setsockopt (ignored): Permission denied
---> PASV
227 Entering Passive Mode (192,154,143,???,41,87)
ftp: connect: Connection refused
ftp> ls
ftp: setsockopt (ignored): Permission denied
---> PASV
227 Entering Passive Mode (192,154,143,???,227,234)
ftp: connect: Connection refused
ftp> passive
Passive mode off.
ftp> ls
ftp: setsockopt (ignored): Permission denied
---> PORT 192,168,1,9,218,2
421 Timeout - try typing a little faster next time

huh?  That was instant.
Costantino | 12 Aug 17:01 2014


While getting the Shorewall dump for previous issue I got some errors


   # shorewall  dump > dump.txt

   cat: /proc/sys/net/netfilter/nf_conntrack_count: No such file or directory

   cat: /proc/sys/net/netfilter/nf_conntrack_max: No such file or directory


Blogs on the internet explain that it's because I’m using the older IP_CONNTRACK modules instead of the newer NF_CONNTRACK.


So, is there any plus in replacing the older with the newer and what’s the impact on what’s already installed should I choose to do it?





PGNd | 11 Aug 19:02 2014

Firewall optimization -- tweak as-written rules and/or depend on OPTIMIZE= ?

Given the simple /rules example

 #                             PORT
 ACCEPT   net    $FW    tcp    1234
 ACCEPT   net    $FW    udp    5678

Is there additional/further Shorewall 'shorthand' that should 'better' consolidate. Something
equivalent to,

 ACCEPT   net    $FW    tcp:1234,udp:5678

perhaps ?

My understanding suggests that it may not be worth worrying about, as the written rules might only effect

The RUNTIME performance of the firewall would be dictated by the OPTIMIZE level.  In my case I've set it in
shorewall.conf to


How dependent is runtime performance on config file 'style'?  Just ignore it, and depend on the OPTIMIZEr to
do its best?