On one machine, I have a web server running (apache) and responding on ports 80 and 443. On this machine, I have a firewall (shorewall) that blocks everything except what I authorize, and I therefore have the following rules (I have many others, but which are off topic here, so I keep it simple):

?SECTION NEW
Web(ACCEPT) net fw
Web(ACCEPT) fw net

Everything works perfectly. EXCEPT that in the firewall logs, I realize that I have lots of outgoing requests rejected with SOURCE ports 80 and 443. And I don't understand why these requests are sent or why rejecting them is not at all blocking the operation of the web server. Note that I have exactly the same question with the mail server and ports 25,110,143,465,993,995. I'm trying to understand, not necessarily to correct something if it's not useful. **EDIT:** Question asked on the shorewall mailing list and it is confirmed that everything is normal, that this corresponds to connections already closed, and that to no longer see these lines appear in the logs, I just need to add dropInvalid to the

REJECT_DEFAULT="Broadcast(DROP),Multicast(DROP)"

configured by default in Shorewall But that doesn't work at all. Whatever I put in REJECT_DEFAULT, I always have these lines in my logs. **EDIT2:** iptables-save -c asked in comments (I removed all fail2ban rules):

# Generated by iptables-save v1.8.9 on Fri Oct 27 16:43:40 2023
*mangle
:PREROUTING ACCEPT [294959:300247330]
:INPUT ACCEPT [294959:300247330]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [271994:270207145]
:POSTROUTING ACCEPT [271932:270200193]
[0:0] -A FORWARD -j MARK --set-xmark 0x0/0xff
COMMIT
# Completed on Fri Oct 27 16:43:40 2023
# Generated by iptables-save v1.8.9 on Fri Oct 27 16:43:40 2023
*nat
:PREROUTING ACCEPT [22019:1019969]
:INPUT ACCEPT [10536:410458]
:OUTPUT ACCEPT [9493:687413]
:POSTROUTING ACCEPT [9493:685796]
COMMIT
# Completed on Fri Oct 27 16:43:40 2023
# Generated by iptables-save v1.8.9 on Fri Oct 27 16:43:40 2023
*raw
:PREROUTING ACCEPT [294959:300247330]
:OUTPUT ACCEPT [271994:270207145]
COMMIT
# Completed on Fri Oct 27 16:43:40 2023
# Generated by iptables-save v1.8.9 on Fri Oct 27 16:43:40 2023
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
:dynamic - [0:0]
:eth0_fwd - [0:0]
:eth0_in - [0:0]
:fw-net - [0:0]
:logdrop - [0:0]
:logflags - [0:0]
:logreject - [0:0]
:reject - [0:0]
:sfilter - [0:0]
:sha-lh-1550d655e9a1cad182eb - [0:0]
:sha-rh-dee8631b410018e6f7d8 - [0:0]
:shorewall - [0:0]
:sshok-fw - [0:0]
:tcpflags - [0:0]
:~log0 - [0:0]
:~log1 - [0:0]
:~log2 - [0:0]
:~log3 - [0:0]
:~log4 - [0:0]
[287639:299139087] -A INPUT -i eth0 -j eth0_in
[1702:777139] -A INPUT -m iface --dev-in --loopback  -j ACCEPT
[0:0] -A INPUT -m conntrack --ctstate INVALID -g ~log2
[0:0] -A INPUT -m hashlimit --hashlimit-upto 1/sec --hashlimit-burst 10 --hashlimit-mode srcip --hashlimit-name lograte -j LOG --log-prefix "INPUT REJECT " --log-level 6
[0:0] -A INPUT -g reject
[0:0] -A FORWARD -i eth0 -j eth0_fwd
[0:0] -A FORWARD -m conntrack --ctstate INVALID -g ~log4
[0:0] -A FORWARD -m hashlimit --hashlimit-upto 1/sec --hashlimit-burst 10 --hashlimit-mode srcip --hashlimit-name lograte -j LOG --log-prefix "FORWARD REJECT " --log-level 6
[0:0] -A FORWARD -g reject
[270273:269429246] -A OUTPUT -o eth0 -j fw-net
[1721:777899] -A OUTPUT -m iface --dev-out --loopback  -j ACCEPT
[0:0] -A OUTPUT -m conntrack --ctstate INVALID -g ~log3
[0:0] -A OUTPUT -m hashlimit --hashlimit-upto 1/sec --hashlimit-burst 10 --hashlimit-mode srcip --hashlimit-name lograte -j LOG --log-prefix "OUTPUT REJECT " --log-level 6
[0:0] -A OUTPUT -g reject
[0:0] -A eth0_fwd -o eth0 -g sfilter
[0:0] -A eth0_fwd -m conntrack --ctstate INVALID,NEW,UNTRACKED -j dynamic
[0:0] -A eth0_fwd -p tcp -j tcpflags
[16554:699778] -A eth0_in -m conntrack --ctstate INVALID,NEW,UNTRACKED -j dynamic
[261014:296956611] -A eth0_in -p tcp -j tcpflags
[148579:24762560] -A eth0_in -m set --match-set sshok src -j sshok-fw
[123729:273762557] -A eth0_in -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
[1120:52679] -A eth0_in -m geoip --source-country CN,RU  -g ~log1
[651:51460] -A eth0_in -s MyIP -j ACCEPT
[8233:263993] -A eth0_in -p icmp -m icmp --icmp-type 8 -m comment --comment Ping -j ACCEPT
[1139:63657] -A eth0_in -p tcp -m multiport --dports 25,465,587,143,993,110,995,80,443 -m comment --comment "Mail, IMAP, IMAPS, POP3, POP3S, Web" -j ACCEPT
[0:0] -A eth0_in -s MyIP -p tcp -m multiport --dports 9418,8000,9101:9102 -j ACCEPT
[0:0] -A eth0_in -m addrtype --dst-type BROADCAST -j DROP
[0:0] -A eth0_in -m addrtype --dst-type ANYCAST -j DROP
[0:0] -A eth0_in -m addrtype --dst-type MULTICAST -j DROP
[4837:233521] -A eth0_in -m hashlimit --hashlimit-upto 1/sec --hashlimit-burst 10 --hashlimit-mode srcip --hashlimit-name lograte -j LOG --log-prefix "net-fw DROP " --log-level 6
[4837:233521] -A eth0_in -j DROP
[253629:268207796] -A fw-net -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
[0:0] -A fw-net -m geoip --destination-country CN,RU  -g ~log0
[1:60] -A fw-net -d MyIP -p tcp -m multiport --dports 9101:9103,19101:19103,19112,19122 -j ACCEPT
[0:0] -A fw-net -p icmp -m icmp --icmp-type 2 -j ACCEPT
[0:0] -A fw-net -p udp -m udp --dport 33434:33524 -m comment --comment Trcrt -j ACCEPT
[138:11592] -A fw-net -p icmp -m icmp --icmp-type 8 -m comment --comment Trcrt -j ACCEPT
[14996:1113778] -A fw-net -p udp -m udp --dport 53 -m comment --comment DNS -j ACCEPT
[1311:78660] -A fw-net -p tcp -m multiport --dports 53,22,80,443,21,25,465,587 -m comment --comment "DNS, SSH, HTTP, HTTPS, FTP, Mail" -j ACCEPT
[118:8968] -A fw-net -p udp -m udp --dport 123 -m comment --comment NTP -j ACCEPT
[4:240] -A fw-net -p tcp -m multiport --dports 43,4321,2703 -m comment --comment "Whois and others, Razor" -j ACCEPT
[2:384] -A fw-net -d 154.61.86.89/32 -p udp -m udp --dport 24441 -j ACCEPT
[12:816] -A fw-net -p udp -m udp --dport 6277 -m comment --comment DCC -j ACCEPT
[0:0] -A fw-net -p tcp -m tcp --dport 873 -m comment --comment Rsync -j ACCEPT
[0:0] -A fw-net -d 187.33.4.179/32 -j ACCEPT
[0:0] -A fw-net -p tcp -m multiport --dports 8000,8001,8080,8276 -j ACCEPT
[43:1804] -A fw-net -m conntrack --ctstate INVALID -g ~log0
[19:5148] -A fw-net -m hashlimit --hashlimit-upto 1/sec --hashlimit-burst 10 --hashlimit-mode srcip --hashlimit-name lograte -j LOG --log-prefix "fw-net REJECT " --log-level 6
[19:5148] -A fw-net -g reject
[0:0] -A logdrop -j DROP
[2:120] -A logflags -m hashlimit --hashlimit-upto 1/sec --hashlimit-burst 10 --hashlimit-mode srcip --hashlimit-name lograte -j LOG --log-prefix "logflags DROP " --log-level 6 --log-ip-options
[2:120] -A logflags -j DROP
[0:0] -A logreject -j reject
[0:0] -A reject -m addrtype --src-type BROADCAST -j DROP
[0:0] -A reject -s 224.0.0.0/4 -j DROP
[0:0] -A reject -p igmp -j DROP
[19:5148] -A reject -p tcp -j REJECT --reject-with tcp-reset
[0:0] -A reject -p udp -j REJECT --reject-with icmp-port-unreachable
[0:0] -A reject -p icmp -j REJECT --reject-with icmp-host-unreachable
[0:0] -A reject -j REJECT --reject-with icmp-host-prohibited
[0:0] -A sfilter -m hashlimit --hashlimit-upto 1/sec --hashlimit-burst 10 --hashlimit-mode srcip --hashlimit-name lograte -j LOG --log-prefix "sfilter DROP " --log-level 6
[0:0] -A sfilter -j DROP
[0:0] -A shorewall -m recent --set --name %CURRENTTIME --mask 255.255.255.255 --rsource
[147356:24676752] -A sshok-fw -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
[572:34348] -A sshok-fw -p tcp -m tcp --dport 22 -m comment --comment SSH -j ACCEPT
[0:0] -A tcpflags -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,PSH,URG -g logflags
[1:60] -A tcpflags -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -g logflags
[1:60] -A tcpflags -p tcp -m tcp --tcp-flags SYN,RST SYN,RST -g logflags
[0:0] -A tcpflags -p tcp -m tcp --tcp-flags FIN,RST FIN,RST -g logflags
[0:0] -A tcpflags -p tcp -m tcp --tcp-flags FIN,SYN FIN,SYN -g logflags
[0:0] -A tcpflags -p tcp -m tcp --tcp-flags FIN,PSH,ACK FIN,PSH -g logflags
[0:0] -A tcpflags -p tcp -m tcp --sport 0 --tcp-flags FIN,SYN,RST,ACK SYN -g logflags
[43:1804] -A ~log0 -m hashlimit --hashlimit-upto 1/sec --hashlimit-burst 10 --hashlimit-mode srcip --hashlimit-name lograte -j LOG --log-prefix "fw-net DROP " --log-level 6
[43:1804] -A ~log0 -j DROP
[1120:52679] -A ~log1 -m hashlimit --hashlimit-upto 1/sec --hashlimit-burst 10 --hashlimit-mode srcip --hashlimit-name lograte -j LOG --log-prefix "net-fw DROP " --log-level 6
[1120:52679] -A ~log1 -j DROP
[0:0] -A ~log2 -m hashlimit --hashlimit-upto 1/sec --hashlimit-burst 10 --hashlimit-mode srcip --hashlimit-name lograte -j LOG --log-prefix "INPUT DROP " --log-level 6
[0:0] -A ~log2 -j DROP
[0:0] -A ~log3 -m hashlimit --hashlimit-upto 1/sec --hashlimit-burst 10 --hashlimit-mode srcip --hashlimit-name lograte -j LOG --log-prefix "OUTPUT DROP " --log-level 6
[0:0] -A ~log3 -j DROP
[0:0] -A ~log4 -m hashlimit --hashlimit-upto 1/sec --hashlimit-burst 10 --hashlimit-mode srcip --hashlimit-name lograte -j LOG --log-prefix "FORWARD DROP " --log-level 6
[0:0] -A ~log4 -j DROP
COMMIT
# Completed on Fri Oct 27 16:43:40 2023

I See that the rules that I am adding in /etc/shorewall/rules are setup fine but DOCKER filter rules are being applied before the ones that I set up in shorewall rules. I have seen that DOCKER-USER can be used to setup docker related rules in iptables. Is there a way to get shorewall to add rules in DOCKER-USER table?

I am trying to configure openvpn and shorewall to be able to connect to virtual machines without SSH tunnels. VMs are KVM with with default NAT networking. VPN Client -> VM HOST -> VM GUESTS (22,80,443, etc.) VPN Client IP 10.8.0.6 VM Guest IP 192.168.20.10 I have followed the tutorial on https://www.digitalocean.com/community/tutorials/how-to-set-up-an-openvpn-server-on-debian-9 Only difference is that I'm using shorewall instead of ufw and seems I have problems with shorewall configuration. VM Guest is able to connect to VPN Client, but VPN client cannot reach any virtual machine. In the shorewall logs I do not see that anything is blocked, so the question is how one way communication works and vice versa does not. Client routes: 10.8.0.1 via 10.8.0.5 dev tun0 10.8.0.5 dev tun0 proto kernel scope link src 10.8.0.6 192.168.20.0/24 via 10.8.0.5 dev tun0 VPN server / VM HOST routes: 10.8.0.0/24 via 10.8.0.2 dev tun0 10.8.0.2 dev tun0 proto kernel scope link src 10.8.0.1 192.168.20.0/24 dev guest proto kernel scope link src 192.168.20.1 Tcpdump on the client (client -> vm guest), connection refused: 12:46:54.981923 IP eclipse.46456 > 192.168.20.10.ssh: Flags [S], seq 1605744015, win 64240, options [mss 1460,sackOK,TS val 2676138055 ecr 0,nop,wscale 7], length 0 12:46:55.011195 IP 10.8.0.1 > eclipse: ICMP 192.168.20.10 tcp port ssh unreachable, length 68 Tcpdump on the client (vm guest -> client), everything OK: 12:50:15.733952 IP 10.8.0.1.46950 > eclipse.ssh: Flags [S], seq 2778177135, win 29200, options [mss 1358,sackOK,TS val 1743090490 ecr 0,nop,wscale 6], length 0 12:50:15.734087 IP eclipse.ssh > 10.8.0.1.46950: Flags [S.], seq 3341641521, ack 2778177136, win 65160, options [mss 1460,sackOK,TS val 3210526372 ecr 1743090490,nop,wscale 7], length 0 12:50:15.763552 IP 10.8.0.1.46950 > eclipse.ssh: Flags [.], ack 1, win 457, options [nop,nop,TS val 1743090497 ecr 3210526372], length 0 12:50:15.763788 IP 10.8.0.1.46950 > eclipse.ssh: Flags [P.], seq 1:41, ack 1, win 457, options [nop,nop,TS val 1743090498 ecr 3210526372], length 40 12:50:15.763816 IP eclipse.ssh > 10.8.0.1.46950: Flags [.], ack 41, win 509, options [nop,nop,TS val 3210526401 ecr 1743090498], length 0 Any help is appreciated.

I have a Debian 9.1 installation I'm using as a NAT router. Shorewall version 5.0.15.6-1, linux kernel version 4.9+80+deb9u1. There are two network interfaces. The routing functions are all working correctly. I would like to log connections and rejections to a log file, but not via syslog, as *everything* else goes there. I've read http://shorewall.org/shorewall_logging.html and followed it as well as I may, and other documents I've found are all about peripheral cases. However, my ulog log file is empty, and netfilter msgs are still going to /var/log/kern.log. here are some excerpts from relevant config files: /etc/shorewall/params ETH1=br1 LOG="NFLOG(1,,)" /etc/shorewall/shorewall.conf LOGFILE=/var/log/shorewall-run.log LOGFORMAT="Shorewall:%s:%s:" MACLIST_LOG_LEVEL=$LOG RPFILTER_LOG_LEVEL=$LOG SFILTER_LOG_LEVEL=$LOG SMURF_LOG_LEVEL=$LOG STARTUP_LOG=/var/log/shorewall-init.log TCP_FLAGS_LOG_LEVEL=$LOG /etc/shorewall/rules ACCEPT:$LOG loc $FW tcp 5509 ACCEPT:$LOG net $FW tcp 5509 ACCEPT loc $FW udp 53 ACCEPT loc $FW tcp 53 the /etc/ulogd.conf is stock, it's the same as from /usr/share/doc/ulogd2/examples/ulogd.conf.gz I'm not getting any compilation errors when I run shorewall restart, and, as in the rules sample above, I am getting syslog messages for connections to 5509, but not 53. The log entries are just going to the wrong place. What am I doing wrong ?

Assume that shorewall rules config contain ACCEPT net:1.234.5.253 all tcp 3306 ACCEPT net:1.234.5.2 all tcp 80 ACCEPT net:1.234.5.2 all tcp 80 ACCEPT net:1.2.3.4,1.234.5.22,1.1.1.1 all tcp 3306 I want replace them with ansible - name: Replace old ips in /etc/shorewall/rules replace: path: /etc/shorewall/rules regexp: '{{ oldip }}' replace: '{{ newip }}' backup: 'yes' Variables are vars: oldip: 1.234.5.2 newip: 100.100.100.100 Im getting output which is correct, but im expecting replace EXACT match of ip not this output ACCEPT net:100.100.100.10053 all tcp 3306 ACCEPT net:100.100.100.100 all tcp 80 ACCEPT net:100.100.100.100 all tcp 80 ACCEPT net:1.2.3.4,100.100.100.1002,1.1.1.1 all tcp 3306 Is there any way how to solve it ?

Running Debian unstable with shorewall for the firewall and fail2ban. Was getting "shorewall not running errors" upon boot up in the fail2ban log, but that was fixed with After=network.target in /lib/systemd/system/fail2ban.service. However, I still get these errors on shutdown or reboot. How do I tell shorewall to wait to shutdown until fail2ban is done?

I'm shaping my traffic such that VoIP calls have highest priority, followed by, VPN, then general network surfing, and lastly, large downloads. [tcclasses] lw 1 200kbit full 1 tos=0x68/0xfc,tos=0xb8/0xfc lw 2 full/4 full 2 tcp-ack,tos-minimize-delay lw 3 full/6 full 3 default lw 4 full/12 full*8/10 4 [tcdevices] lw 0mbit 500mbit [mangle] MARK(4) 0.0.0.0/0 0.0.0.0/0 - - - - - - - 504857:5048570:B:B # general web browsing MARK(3) 0.0.0.0/0 0.0.0.0/0 tcp http,https # general UDP MARK(2) 0.0.0.0/0 0.0.0.0/0 udp MARK(2) 0.0.0.0/0 $WORK_VPN tcp https MARK(2) $WORK_VPN 0.0.0.0/0 tcp https # asterisk MARK(1) 0.0.0.0/0 0.0.0.0/0 udp $ASTERISK_RTP_PORTS # google voice (this effectively makes everything equal, only include Google servers here) MARK(1) 0.0.0.0/0 $GOOGLE_CIDR udp $GOOGLE_VOICE_UDP_PORTS MARK(1) 0.0.0.0/0 $GOOGLE_CIDR tcp $GOOGLE_VOICE_TCP_PORTS # tmobile wifi calling MARK(1) 0.0.0.0/0 $TMOBILE_UDP_CIDR udp $TMOBILE_UDP_PORTS MARK(1) 0.0.0.0/0 $TMOBILE_TCP_CIDR tcp $TMOBILE_TCP_PORTS # facetime MARK(1) 0.0.0.0/0 $APPLE_CIDR udp $APPLE_FACETIME_UDP MARK(1) 0.0.0.0/0 $APPLE_CIDR tcp $APPLE_FACETIME_TCP When I set the upload bandwidth to some insanely high value, I can notice the bandwidth I'm measuring is what I expect. If I put it to what it should be (50Mbps) the actual bandwidth I measure on speedtest sites is much, much lower (2-3Mbps). But, my tcclasses is showing that all traffic can make use of the fast connection when it is available as I have "full" in the configuration for all except *#4*. What am I missing? [EDIT] 1. I swapped interfaces to ensure that the driver / device I'm using supports BQL: https://www.bufferbloat.net/projects/bloat/wiki/BQL_enabled_drivers/

I have two Ubuntu 16.04 servers, one on a little intel atom itx box on my local network and one hosted as a VPS. Both were installed fresh within the last week. Both are generally the same configuration except more efforts have gone into hardening the publicly accessible VPS. Neither have had the kernel recompiled. both have generally the same set of packages installed. And yet... one of them, the VPS, rather insists that it's netfilters can't match against ipsets. wolferz@unipuma ~ $ sudo shorewall check Checking using Shorewall 5.1.6.1... Processing /etc/shorewall/params ... Processing /etc/shorewall/shorewall.conf... Loading Modules... Checking /etc/shorewall/zones... Checking /etc/shorewall/interfaces... Determining Hosts in Zones... Locating Action Files... Checking /etc/shorewall/policy... Adding Anti-smurf Rules Checking TCP Flags filtering... Checking Kernel Route Filtering... Checking Martian Logging... Checking MAC Filtration -- Phase 1... Checking /etc/shorewall/blrules... ERROR: ipset names in Shorewall configuration files require Ipset Match in your kernel and iptables /etc/shorewall/blrules (line 39) The configuration I intend to use depends heavily on ipsets for dynamic blacklisting and whitelisting of large sets of IPs. Because netfilter doesn't lend itself well to being altered often or having massive lists of rules (one for each ip... often thousands). Without ipset matching, there is no moving forward here. Despite the fact that I'm using Shorewall to manage netfilter and ipsets this does not appear to be a Shorewall problem. Unless it's detection is askew somehow... but I'm not sure how to confirm it's output. Here's what Shorewall detects as the kernel's netfilter capability on the VPS. wolferz@unipuma ~ $ sudo shorewall version 5.1.6.1 wolferz@unipuma ~ $ sudo shorewall show -f capabilities | grep IPSET IPSET_MATCH= unipuma_sorted_modules.list ... scp it to the other host ... wolferz@khaos ~ $ sudo ls -R -D /lib/modules/4.4.0-93-generic/kernel/ | grep -P '\.ko$' | sort > khaos_sorted_modules.list wolferz@khaos ~ $ diff --brief --report-identical-files khaos_sorted_modules.list unipuma_sorted_modules.list Files khaos_sorted_modules.list and unipuma_sorted_modules.list are identical Then I checked the actual config for the kernel I'm using: wolferz@unipuma ~ $ sudo cat /boot/config-4.4.0-93-generic | grep -P '(?:NETFILTER|IPSET)' | sort > unipuma_kernel_config.list wolferz@khaos ~ $ sudo cat /boot/config-4.4.0-93-generic | grep -P '(?:NETFILTER|IPSET)' | sort > khaos_kernel_config.list wolferz@khaos ~ $ diff --brief --report-identical-files khaos_kernel_config.list unipuma_kernel_config.list Files khaos_kernel_config.list and unipuma_kernel_config.list are identical Well ok then. Color me confused. Same kernel. Same modules. Same Config. Different capabilities. Wut? And... just to cut this line of thinking off at the pass... it's not the vhost either. I have a third server running CentOS6 with this same version of shorewall (and older versions of netfilter/iptables/ipset) which does not have this problem. It's hosted on the same physical machine using the same virtualization (KVM) as the Ubuntu 16.04 vps above. ...Help?

I am using shorewall as my firewall and traffic shaping platform; however, I'm wondering what more I can do to help mitigate upstream jitter issues. I have a fair amount of bandwidth, but the connection is not stable and enough so that jitter causes VoIP calls to be choppy. I am already shaping the VoIP traffic and assigning it the highest priority. I am planning to switch from guaranteeing 80% of the bandwidth to a set limit of 1Mb/s which should be more than sufficient. Is there something more I can do, if so, at which level? The problem with the call quality happens at both ends. If I implement some sort of buffer on my end, that will fix the call choppiness when I attempt to hear others, but what can I do to fix others hearing me?

I'm getting an error that I'm not sure how to debug. Any thoughts on the matter? Here are the contents of the shorewall.spec file %global mainver 5.0.4 %global baseurl http://www.shorewall.net/pub/shorewall/5.0/shorewall-%{mainver}/ # A very helpful document for packaging Shorewall is "Anatomy of Shorewall 4.0" # which is found at http://www.shorewall.net/Anatomy.html Name: shorewall Version: %{mainver} Release: 1%{?dist} Summary: An iptables front end for firewall configuration Group: Applications/System License: GPLv2+ URL: http://www.shorewall.net/ Provides: shorewall(firewall) = %{version}-%{release} Source0: %{baseurl}/%{name}-%{version}.tar.bz2 Source1: %{baseurl}/%{name}-lite-%{version}.tar.bz2 Source2: %{baseurl}/%{name}6-%{version}.tar.bz2 Source3: %{baseurl}/%{name}6-lite-%{version}.tar.bz2 Source4: %{baseurl}/%{name}-init-%{version}.tar.bz2 Source5: %{baseurl}/%{name}-core-%{version}.tar.bz2 BuildRequires: perl BuildRequires: perl(Digest::SHA) BuildArch: noarch Requires: shorewall-core = %{version}-%{release} Requires: iptables iproute Requires(post): /sbin/chkconfig Requires(post): sed %description The Shoreline Firewall, more commonly known as "Shorewall", is a Netfilter (iptables) based firewall that can be used on a dedicated firewall system, a multi-function gateway/ router/server or on a standalone GNU/Linux system. %package -n shorewall6 Summary: Files for the IPV6 Shorewall Firewall Group: Applications/System Provides: shorewall(firewall) = %{version}-%{release} Requires: shorewall-core = %{version}-%{release} Requires: iptables-ipv6 iproute Requires(post): /sbin/chkconfig %description -n shorewall6 This package contains the files required for IPV6 functionality of the Shoreline Firewall (shorewall). %package lite Group: Applications/System Summary: Shorewall firewall for compiled rulesets Provides: shorewall(firewall) = %{version}-%{release} Requires: shorewall-core = %{version}-%{release} Requires: iptables-ipv6 iproute Requires(post): /sbin/chkconfig %description lite Shorewall Lite is a companion product to Shorewall that allows network administrators to centralize the configuration of Shorewall-based firewalls. Shorewall Lite runs a firewall script generated by a machine with a Shorewall rule compiler. A machine running Shorewall Lite does not need to have a Shorewall rule compiler installed. %package -n shorewall6-lite Group: Applications/System Summary: Shorewall firewall for compiled IPV6 rulesets Provides: shorewall(firewall) = %{version}-%{release} Requires: shorewall-core = %{version}-%{release} Requires: iptables-ipv6 iproute Requires(post): /sbin/chkconfig %description -n shorewall6-lite Shorewall6 Lite is a companion product to Shorewall6 (the IPV6 firewall) that allows network administrators to centralize the configuration of Shorewall-based firewalls. Shorewall Lite runs a firewall script generated by a machine with a Shorewall rule compiler. A machine running Shorewall Lite does not need to have a Shorewall rule compiler installed. %package core Group: Applications/System Summary: Core libraries for Shorewall %description core This package contains the core libraries for Shorewall. %package init Group: Applications/System Summary: Initialization functionality and NetworkManager integration for Shorewall Requires: shorewall(firewall) = %{version}-%{release} Requires: NetworkManager Requires: shorewall = %{version}-%{release} Requires: iptables-ipv6 iproute logrotate Requires(post): /sbin/chkconfig %description init This package adds additional initialization functionality to Shorewall in two ways. It allows the firewall to be closed prior to bringing up network devices. This insures that unwanted connections are not allowed between the time that the network comes up and when the firewall is started. It also integrates with NetworkManager and distribution ifup/ifdown systems to allow for 'event-driven' startup and shutdown. %prep %setup -q -c -n %{name}-%{version} -T -a0 -a1 -a2 -a3 -a4 -a5 # Remove hash-bang from files which are not directly executed as shell # scripts. This silences some rpmlint errors. find . -name "lib.*" -exec sed -i -e 'm:\#\!/bin/sh:d' {} \; %build %install # removes any line that has /SYSTEMD on it from shorewallrc.redhat # then runs ./install.sh script for target in shorewall shorewall-core shorewall-lite shorewall6 shorewall6-lite shorewall-init; do pushd ${target}-%{version} sed -i -e '/SYSTEMD/d' shorewallrc.redhat ./configure vendor=redhat DESTDIR=$RPM_BUILD_ROOT ./install.sh popd done # Fix up file permissions chmod 644 $RPM_BUILD_ROOT%{_datadir}/shorewall-lite/{helpers,modules} chmod 644 $RPM_BUILD_ROOT%{_datadir}/shorewall6-lite/{helpers,modules} chmod 755 $RPM_BUILD_ROOT/sbin/shorewall-lite chmod 755 $RPM_BUILD_ROOT/sbin/shorewall6-lite chmod 644 $RPM_BUILD_ROOT%{_sysconfdir}/shorewall-lite/shorewall-lite.conf chmod 644 $RPM_BUILD_ROOT%{_sysconfdir}/shorewall6-lite/shorewall6-lite.conf chmod 755 $RPM_BUILD_ROOT%{_sysconfdir}/NetworkManager/dispatcher.d/01-shorewall %clean rm -rf $RPM_BUILD_ROOT %post if [ $1 = 1 ]; then /sbin/chkconfig --add shorewall fi %preun if [ $1 = 0 ]; then /sbin/service shorewall stop >/dev/null 2>&1 /sbin/chkconfig --del shorewall rm -f /var/lib/shorewall/* fi %post -n shorewall6 if [ $1 = 1 ]; then /sbin/chkconfig --add shorewall6 fi %preun -n shorewall6 if [ $1 = 0 ]; then /sbin/service shorewall6 stop >/dev/null 2>&1 /sbin/chkconfig --del shorewall6 rm -f /var/lib/shorewall6/* fi %post -n shorewall-lite if [ $1 = 1 ]; then /sbin/chkconfig --add shorewall-lite fi %preun -n shorewall-lite if [ $1 = 0 ]; then /sbin/service shorewall stop >/dev/null 2>&1 /sbin/chkconfig --del shorewall-lite rm -f /var/lib/shorewall-lite/* fi %post -n shorewall6-lite if [ $1 = 1 ]; then /sbin/chkconfig --add shorewall6-lite fi %preun -n shorewall6-lite if [ $1 = 0 ]; then /sbin/service shorewall6-lite stop >/dev/null 2>&1 /sbin/chkconfig --del shorewall6-lite rm -f /var/lib/shorewall6-lite/* fi %post -n shorewall-init if [ $1 = 1 ]; then /sbin/chkconfig --add shorewall-init fi %preun -n shorewall-init if [ $1 = 0 ]; then /sbin/service shorewall-init stop >/dev/null 2>&1 /sbin/chkconfig --del shorewall-init fi %files %doc shorewall-%{version}/{COPYING,changelog.txt,releasenotes.txt,Samples} /sbin/shorewall %dir %{_sysconfdir}/shorewall %config(noreplace) %{_sysconfdir}/shorewall/* %config(noreplace) %{_sysconfdir}/logrotate.d/shorewall %config(noreplace) %{_sysconfdir}/sysconfig/shorewall %{_datadir}/shorewall/action.* %{_datadir}/shorewall/actions.std %{_datadir}/shorewall/configfiles/ %{_datadir}/shorewall/configpath %{_datadir}/shorewall/helpers %{_datadir}/shorewall/lib.cli-std %{_datadir}/shorewall/lib.core %{_datadir}/shorewall/macro.* %{_datadir}/shorewall/modules* %{_datadir}/shorewall/prog.* %{_datadir}/shorewall/version %{_libexecdir}/shorewall/compiler.pl %{_libexecdir}/shorewall/getparams %{perl_vendorlib}/Shorewall %{_mandir}/man5/shorewall* %exclude %{_mandir}/man5/shorewall6* %exclude %{_mandir}/man5/shorewall-lite* %{_mandir}/man8/shorewall* %exclude %{_mandir}/man8/shorewall6* %exclude %{_mandir}/man8/shorewall-lite* %exclude %{_mandir}/man8/shorewall-init* %{_initrddir}/shorewall %dir %{_localstatedir}/lib/shorewall %doc shorewall-%{version}/{COPYING,changelog.txt,releasenotes.txt,Samples} /sbin/shorewall-init %dir %{_datadir}/shorewall/ %{_datadir}/shorewall/coreversion %{_datadir}/shorewall/functions %{_datadir}/shorewall/lib.base %{_datadir}/shorewall/lib.cli %{_datadir}/shorewall/lib.common %{_datadir}/shorewall/shorewallrc %dir %{_libexecdir}/shorewall %{_libexecdir}/shorewall/wait4ifup %files init %doc shorewall-%{version}/{COPYING,changelog.txt,releasenotes.txt,Samples} %{_sysconfdir}/NetworkManager/dispatcher.d/01-shorewall %config(noreplace) %{_sysconfdir}/sysconfig/shorewall-init %{_sysconfdir}/logrotate.d/shorewall-init %{_mandir}/man8/shorewall-init.8.* %{_datadir}/shorewall-init %{_libexecdir}/shorewall-init %{_initrddir}/shorewall-init Here is some of the output of the command rpmbuild -bi shorewall.spec Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.wXhGIf + umask 022 + cd /home/username/rpmbuild/BUILD + '[' /home/username/rpmbuild/BUILDROOT/shorewall-5.0.4-1.el6.x86_64 '!=' / ']' + rm -rf /home/username/rpmbuild/BUILDROOT/shorewall-5.0.4-1.el6.x86_64 ++ dirname /home/username/rpmbuild/BUILDROOT/shorewall-5.0.4-1.el6.x86_64 + mkdir -p /home/username/rpmbuild/BUILDROOT + mkdir /home/username/rpmbuild/BUILDROOT/shorewall-5.0.4-1.el6.x86_64 + cd shorewall-5.0.4 + LANG=C + export LANG + unset DISPLAY /var/tmp/rpm-tmp.wXhGIf: line 68: syntax error: unexpected end of file error: Bad exit status from /var/tmp/rpm-tmp.wXhGIf (%install) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.wXhGIf (%install)

I am trying to use shorewall on Arch to manage a setup with 2 local networks and 2 ISP connections. Ultimately I want traffic from local network 1 (192.168.1.0/24 interface enp5s0) to use ISP 1 (76. ... interface enp6s0) and traffic from local 2 (192.168.0.0/24 interface enp7s0) to use ISP 2 (99. ... interface enp3s0). Currently, I can make one or the other work, but not both, depending on which default route comes first: output of ip route ls with sensitive information redacted: default via 76.[rd].1 dev enp6s0 src 76.[rd].78 metric 203 mtu 576 default via 99.[rd].1 dev enp3s0 src 99.[rd].190 metric 205 76.[rd].0/24 dev enp6s0 proto kernel scope link src 76.[rd].78 metric 203 mtu 576 76.[rd].78 dev enp6s0 scope link src 76.[rd].78 99.194.48.0/21 dev enp3s0 proto kernel scope link src 99.[rd].190 metric 205 99.[rd].190 dev enp3s0 scope link src 99.[rd].190 192.168.0.0/24 dev enp7s0 proto kernel scope link src 192.168.0.1 metric 204 192.168.1.0/24 dev enp5s0 proto kernel scope link src 192.168.1.1 metric 202 With the above output, local 1 would be able to reach the outside, but local 2 would not. Vice-versa if the first line were gone. I'm pretty sure multiple default routes is a no-no, even with multiple ISPs, but this is how shorewall did it. Since there was no example for this anywhere, I based it off of shorewall's three-interface example. To avoid making this post insanely long, here are links to pastes of each relevant shorewall configs: - interfaces: http://pastebin.com/u7w3YJdx - mangle: http://pastebin.com/1X2hrLCZ - masq: http://pastebin.com/bi9EEtwD - policy: http://pastebin.com/mBBZQ0wg - rtrules: http://pastebin.com/ySSLpMWd - providers: http://pastebin.com/YjDfKZzg - zones: http://pastebin.com/XVgYz3dn Shorewall's pages on the matter are unhelpful because the goal in their example is very different from my goal. Any pointers in the right direction would be much appreciated.

I am planning to use Shorewall to filter traffic that originates from a virtual interface created by OpenVPN (lets call it tap0). If OpenVPN did not successfully create this interface before Shorewall started, but the interface was defined in /etc/shorewall/interfaces, would traffic be filtered if the interface was successfully created later? Would this depend on a script hook, or does Shorewall pre-create rules for interfaces that are defined in the configuration, but do not exist?

I am having difficulty setting up chromecast on my local network. The chromecast device is successfully connected to my network, but reports it cannot access the Internet. That is not true, because I see that it successfully resolved google's servers and is communicating over HTTPS. I also see that multicast is working such that my tablet is able to connect to it. My router is running shorewall 5 (which is essentially an iptables wrapper). And, for wireless, I'm running hostapd, I don't have AP isolation enabled (the default setting in hostapd). I ran tcpdump, but didn't see anything being blocked other than I am rejecting google's DNS for my own. Is there something I'm missing, why can't the device access the "Internet".

I am trying to do a similar exercise to shorewall FAQ 2a but with public IP addresses. I have traffic that I am trying to route via an IPSEC connection but once I turn on shorewall I get the following

:FORWARD:REJECT:IN=eth1 OUT=eth1 MAC=52:54:00:90:e3:a9:00:25:90:ae:0a:c3:08:00 SRC=196.38.X.X DST=196.11.X.X LEN=60 TOS=0x10 PREC=0x00 TTL=63 ID=54294 DF PROTO=TCP SPT=50594 DPT=35101 WINDOW=27200 RES=0x00 SYN URGP=0

Routeback is enabled and net net traffic is set to accept in the policy Any ideas how to sort this out? Routing etc is perfect when shorewall is disabled. Edit below. I've added the config. It turns out that it works perfectly if I remove

all     REJECT  info

so it may be that my I don't have the correct rule defined to match the traffic. /etc/shorewall/rules

net:196.38.YY.XX       vpn   tcp 35101
ACCEPT                  net:196.38.YY.XX       net:196.11.YY.XX       tcp 35101

/etc/shorewall/tunnels

net	a.b.c.d

/etc/shorewall/policy

$FW     all     ACCEPT
net     all     DROP    info 
vpn   all     ACCEPT  info
all     vpn   ACCEPT  info
all     all     REJECT  info

/etc/shorewall/zones

ipv4

/etc/shorewall/hosts

eth1:a.b.c.d              ipsec

/etc/shorewall/interfaces

eth1            detect          tcpflags,nosmurfs,routeback

Will VyOS still work right if I install Shorewall-lite on it? Shorewall seems like an easier way to setup a network, but VyOS seems pretty great for day-to-day management of a router / firewall. So I was wondering if they are compatible. From what I understand about Shorewall, it just generates a bunch of iptables rules, and VyOS is a Linux dirstro with iptables, so it seems to me that it should work, but I thought I would just check if there were any other caveats about why they are not compatible that I should know about before putting the research into setting something like this up.