PGNd | 3 Sep 06:00 2014
Picon

implementing lsm, per 'MultiISP' example, "device=" spec not propagating from lib.private to lsm config include

I'm setting up intfc monitoring using lsm in a 2-intfc MultiISP config.

Following

	http://shorewall.net/MultiISP.html#lsm

I've created 

	cat /lib.private
		...
		start_lsm() {
			killall lsm 2> /dev/null
		cat <<EOF > /usr/local/etc/lsm/shorewall.conf
		connection {
			name=Prov1
			checkip=XX.XX.XX.XX
			device=$EXTIF
			ttl=2
		}
		connection {
			name=Prov1
			checkip=YY.YY.YY.YY
			device=$VPNIF
			ttl=2
		}
		EOF
			rm -f /usr/local/etc/shorewall/*.status
			/usr/local/sbin/lsm \
			 -c /usr/local/etc/lsm/lsm.conf \
			 -p /var/run/lsm/lsm.pid >> /var/log/lsm.log
(Continue reading)

Steve Wray | 3 Sep 03:34 2014
Picon

firewalld support?

Hi,
I've been hearing about firewalld and how this will become the default in future releases of Redhat and therefore CentOS. Its possible it might show up in other places like Ubuntu, maybe even Debian.

https://fedoraproject.org/wiki/FirewallD

Shorewall has been great, we use Puppet and an excellent Shorewall module which makes managing a distributed firewall configuration very easy.

I didn't find anything regarding Shorewall support. Is there any plan to support this?

Thanks!


------------------------------------------------------------------------------
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
------------------------------------------------------------------------------
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
PGNd | 2 Sep 21:23 2014
Picon

please clarify `shorewall run` usage with shorewall{, 6}-lite

I've compiled and deployed to a remote instance

	shorewall-lite version
		4.6.3.1

my firewall config includes a number of  <at> lib.private declared functions

they're seen  <at>  the remote instance in the pushed fw script; for example,

	cat /var/lib/shorewall-lite/firewall
		...
		load_ipsets4() {
		        SH="/bin/sh"
		        IPSET="/usr/sbin/ipset"
		...

v4.6.3's new `shorewall run ...` support
(https://www.mail-archive.com/shorewall-users <at> lists.sourceforge.net/msg17241.html) is quite
useful.  in a centrally-managed scheme, the runnable scripts need be in the context of the remote
instance.  i.e,. using 'shorewall{,6}-lite' to exec.

fyi, checking on the remote, there are duplicate/different usage docs  <at>  `help`

	shorewall-lite help
		Usage: shorewall-lite [debug|trace] [nolock] [ -q ] [ -v[-1|{0-2}] ] [ -t ] <command>
		where <command> is one of:
		...
		   run <command> [ <parameter> ... ]
		...
		   run <function> [ function ... ]
		...

and if I try to exec it

	shorewall-lite run load_ipsets4

I get an odd return

	Usage: /var/lib/shorewall-lite/firewall [ options ] <command>

	<command> is one of:
	   start
	   stop
	   clear
	   disable <interface>
	   down <interface>
	   enable <interface>
	   reset
	   refresh
	   restart
	   status
	   up <interface>
	   version

	Options are:

	   -v and -q        Standard Shorewall verbosity controls
	   -n               Don't update routing configuration
	   -p               Purge Conntrack Table
	   -t               Timestamp progress Messages
	   -V <verbosity>   Set verbosity explicitly
	   -R <file>        Override RESTOREFILE setting

and the function, itself, is not executed

can correct usage be clarified further?  or is it likely a bug?

------------------------------------------------------------------------------
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
Steve | 2 Sep 17:25 2014
Picon

A (hopefully simple) question about logging...

I have a Shorewall installation which works (almost) perfectly... it 
implements a firewall bridging an OpenVPN interface, and services on the 
host running Shorewall - traffic is permitted from the OpenVPN interface 
to a minimal set of ports - each corresponding to a specific service 
running on the server running Shorewall.

My problem is that my syslog is filling with messages of the form:

> Sep  2 15:37:31 server kernel: [52835.565836]
> Shorewall:pub2fw:DROP:IN=tun0 OUT= MAC= SRC=SS.SS.SS.SS
> DST=DD.DD.DD.DD LEN=143 TOS=0x00 PREC=0x00 TTL=64 ID=8370 DF PROTO=UDP
> SPT=17500 DPT=17500 LEN=123

SS.SS.SS.SS is the public IP address of the server that runs the remote 
OpenVPN endpoint.

DD.DD.DD.DD is the IP address of the local end-point for the OpenVPN link.

The source port identifies the traffic as from the Dropbox Lansync 
protocol.  I know this to be run on the remote server - and I am not in 
a position to influence the configuration of the remote server. The 
local server does not support/use the Dropbox Lansync protocol. I am 
very happy that these packets are dropped... but I'd prefer not to fill 
my syslog with notifications about this benign dropped packet.

Please can someone point me towards some minimal change I can make to my 
Shorewall configuration that will eliminate this recurring syslog 
message - but otherwise leave Shorewall behaviour as is?

------------------------------------------------------------------------------
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
PGNd | 2 Sep 08:10 2014
Picon

after 4.6.2.5 -> 4.6.3.1 upgrade, `show routing` no longer displays provider's routing tables

running Shorewall 4.6.2.5, with a provider defined, in routing I'd see (e.g.)

	shorewall show routing
		...
		Routing Rules

		0:      from all lookup local 
		10000:  from all fwmark 0x100/0xff00 lookup Prov1 
		20000:  from xx.xx.xx.xx lookup Prov1 
		32766:  from all lookup main 
		32767:  from all lookup default 

		Table Prov1:
		...

after upgrading from Shorewall 4.6.2.5 -> 4.6.3.1, I no longer see the providers' routing tables

	shorewall show routing
		...
		Routing Rules

		0:      from all lookup local 
		32766:  from all lookup main 
		32767:  from all lookup default 

		Table default:
		...

yet packet marking and routing to providers works as always, whether for one, or multiple, providers.

Has 'show routing' function/display been changed?  Looking at most recent changelog, I've missed any;
diggeing further back ...

------------------------------------------------------------------------------
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
Tom Eastep | 28 Aug 03:22 2014
Picon

Shorewall 4.6.3.1

Shorewall 4.6.3.1 is now available for download.

Problems Corrected:

1)  The DNSAmp action released in 4.6.3 matched more packets than it
    should have. That has now been corrected.

2)  The handling of REJECT in IP[6]TABLES rules has been clarified in
    the shorewall-rules(5) and shorewall6-rules(5) manpages.

3)  The following misleading error message has now been corrected:

      ERROR: The xxx TARGET is now allowed in the filter table

    The message now reads:

      ERROR: The xxx TARGET is not allowed in the filter table

Thank you for using Shorewall,
-Tom
--

-- 
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
http://shorewall.net \________________________________________________

------------------------------------------------------------------------------
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
------------------------------------------------------------------------------
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
Eric Teeter | 22 Aug 17:14 2014
Picon

Macro for Citrix Goto-Meeting

Tom:

Macro you can add for Citrix Goto Meeting

#
# Shorewall version 4 - Citrix/Goto Meeting macro
#
# /usr/share/shorewall/macro.Goto-Meeting
#          by Eric Teeter
#       This macro handles Citrix/Goto Meeting
#       Assumed that ports 80 and 443 are already open
#       If need use those macros that open Http and Https to reduce redundancy
####################################################################################
#ACTION SOURCE  DEST    PROTO   DEST    SOURCE  RATE    USER/
#                                        PORT(S) PORT(S) LIMIT   GROUP
PARAM      -               -           tcp        8200    # Goto Meeting only needed (TCP outbound)

--
Eric Teeter


------------------------------------------------------------------------------
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
------------------------------------------------------------------------------
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
PGNd | 22 Aug 03:05 2014
Picon

mangle chain created in /tcstart-invoked QoS script is cleared by end of complete 'firewall' reload?

I've cleaned up my variable naming in my external QoS tc-script.

It's defined in 'lib.private', and in process creates a new mangle table chain, 'SHAPER_EGRESS'.

	/lib.private
		qos_control() {
			...
			function define_rules_up() {
				...
				/usr/sbin/iptables -t mangle -N SHAPER_EGRESS
				...
			}
			...
			case "$1" in
			...
			start)
				define_rules_up
			;;
			esac
		}

and invoked in

	/tcstart
		qos_control start

Ater `firewall start`, the firewall's up, with no apparent errors

But when I check with

	shorewall show mangle

I do NOT see the SHAPER_EGRESS mangle chain.

If I modify the 'qos+control()' script with an 'exit',

	/lib.private
		qos_control() {
			...
			function define_rules_up() {
				...
				/usr/sbin/iptables -t mangle -N SHAPER_EGRESS
				...
			}
			...
			case "$1" in
			...
			start)
				define_rules_up
++		exit
			;;
			esac
		}

and then check

	shorewall show mangle

I *do* see the SHAPER_EGRESS chain, and all the rules I've added to it.

But, the firewall itself isn't up

	Shorewall Lite isn't started

'Something' between the exec of /tcstart, and the complete firewall (re)load is clearing that
SHAPER_EGRESS mangle chain.

I'll single-step if I have to, but --

-- any ideas as to what step in the execution flow might be clearing that chain, and where I configure to
prevent it -- i.e., to preserve my defined/populated chain through fw (re)start?

------------------------------------------------------------------------------
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
PGNd | 21 Aug 16:28 2014
Picon

SW segfault on 'tcstart' exec of external QoS/tc script; debug?

I'm adapting an external ToS script I've used previously, standalone,

	https://github.com/k0smik0/e-hfsc

for use in Shorewall (4.6.2.5).

I've modified its vars to use values from /params, changed use of 'tc' -> 'tun_tc', etc, and added it to
lib.private as

	qos_control() {
		...
		case "$1" in
		status)
		  status
		  exit
		  ;;
		stop)
		  delete_for_uplink
		  delete_for_downlink
		  exit
		  ;;
		start)
		  set_rules_for_uplink
		  set_rules_for_downlink
		  exit
		  ;;
		restart)
		  delete_for_uplink
		  delete_for_downlink

		  set_rules_for_uplink
		  set_rules_for_downlink
		  exit
		  ;;
		*)
		  echo "$(basename $0) start|stop|status|restart"
		  exit
		  ;;
		esac
	}

I mod'd SW conf to use an external script

	/shorewall.conf
		...
		CLEAR_TC=Yes
		TC_ENABLED=Yes
		TC_EXPERT=No
		...

and invoke it as

	/tcstart
		qos_control start

	/tcstop
		qos_control stop

On local-compile/remote-push of the script,  <at> tcstart segfaults

	...
	Adding Providers...
	Setting up Traffic Control...
	Processing /usr/local/etc/shorewall/tcstart user exit ...
	/usr/share/shorewall/lib.common: line 113: 30099 Segmentation fault      $SHOREWALL_SHELL $script
$options $ <at> 

where

	cat /usr/share/shorewall/lib.common
		#
		# Do required exports or create the required option string and run the passed script using
		# $SHOREWALL_SHELL
		#
113		run_it() {
		    local script
		    local options

The unmodified script works outside of SW; the mod'd script segfaults when exec'd from inside of SW.

How do I get at the right SW debug info *locally* to determine what's causing that segfault on the *remote*  <at> tcstart?

------------------------------------------------------------------------------
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
PGNd | 20 Aug 17:05 2014
Picon

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

	/conntrack
		?FORMAT 3
		NOTRACK     +IPBLACKLIST_IP    -
		NOTRACK     +IPBLACKLIST_NET   -
		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

	/rules
		...
		ACCEPT    $FW    net:+IPWHITELIST_IP,+IPWHITELIST_NET    tcp
		ACCEPT    lan    net:+IPWHITELIST_IP,+IPWHITELIST_NET    tcp
		...

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.

Given the global block in /conntrack should stay as is, what's the right way to punch specific, whitelisted
holes in the blacklists?

------------------------------------------------------------------------------
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
Tom Eastep | 20 Aug 02:29 2014
Picon

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

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

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

-- 
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
http://shorewall.net \________________________________________________

------------------------------------------------------------------------------
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
------------------------------------------------------------------------------
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/

Gmane