[Shorewall-users] shorewall reload / restart
Hi, I read the shorewall man page regarding the "reload" and "restart" commands. From a practical point of view and with default shorewall.conf settings in 5.1, if I change/add/delete entries in the "rules" file, and issue the "reload" command then I should expect the following: - existing connections will not be affected - the "new rules" will be processed and applied Same thing should happen when changing entries in snat, mangle, routes, rtrules. The params file should also be re-read. Correct? So, with shorewall >=5.0.15, when would it be useful to issue the "restart" command? The only scenario I can think of is if I wanted to interrupt active connections (or at least preserve only those in "stoppedrules"). Regards, Vieri -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] traffic issues through firewall router
I can see the light at the end of the tunnel, but I'm not quite there yet. A reminder of my current network: Internet providers --- gw1 --- fw2 --- lan, dmz, caib, ibs I replaced the old fw1 with the new fw2 this morning, and everything seemed to work until I found that some lan hosts could not access hosts in the caib and ibs zones. They could however access hosts in the wan zone, as well as fw2 itself. The strange thing is that two hosts with apparently the same access rules do not behave the same way. One can ping, the other can't. Let's just take one example: - ping dest IP address 10.215.134.196 in "ibs" zone from "lan" host with IP address 10.215.144.48 is OK - ping dest IP address 10.215.134.196 in "ibs" zone from "lan" host with IP address 10.215.246.47 FAILS Same thing happens with dest IP address 10.215.9.172 in "caib" zone. Please note that host at 10.215.246.47 can ping fw2 and 8.8.8.8 in "wan" zone just fine. This is the "rule" that should match: ACCEPTlan:10.215.246.0/23caib:10.215.0.0-10.215.143.255all ACCEPTlan:10.215.246.0/23ibs:10.215.0.0-10.215.143.255all While performing the first test, I see this on fw2: # tcpdump -nni enp10s0 host 10.215.246.47 07:41:23.433865 ARP, Request who-has 10.215.134.196 tell 10.215.246.47, length 46 07:41:28.933987 ARP, Request who-has 10.215.134.196 tell 10.215.246.47, length 46 07:41:34.434102 ARP, Request who-has 10.215.134.196 tell 10.215.246.47, length 46 07:41:39.934164 ARP, Request who-has 10.215.134.196 tell 10.215.246.47, length 46 My current "interfaces" file on fw2 is as follows: lan $IF_LAN routeback,arp_filter=1 wan $IF_WAN routeback,arp_filter=1 caib$IF_CAIBarp_filter=1 ibs $IF_IBS arp_filter=1 dmz $IF_DMZ routeback,dhcp - lo - I unsuccessfully tried adding proxyarp=1 to IF_IBS, but not IF_LAN. Here's the link to the shorewall dump while doing this test (I added logging to the lan-ibs and lan-caib policies): https://drive.google.com/file/d/0B-tpkY1LkI67LXBXSTlaV1FOeEE/view?usp=sharing (More) help appreciated. Vieri -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
[Shorewall-users] ProFtpd Shorewall DROP net-fw TLS connection from client ftp
Hi friends, On Debian Jessie, I've configured ProFtpd to connect by tls (SSLv3 TLSv1 -> Letsencypt certificate) on port but with Shorewall up, it DROP the connection: Aug 8 18:50:10 server kernel: [16438563.572121] Shorewall:net-fw:DROP:IN=eth0 OUT= MAC=00:50:56:3c:a8:50:00:08:e3:ff:fd:90:08:00 SRC=132.142.22.10 DST=44.320.032.111 LEN=60 TOS=0x00 PREC=0x00 TTL=56 ID=63283 DF PROTO=TCP SPT=33175 DPT=55298 WINDOW=29200 RES=0x00 SYN URGP=0 My rules.conf: PORTPORT(S) DESTLIMIT GROUP ?SECTION ALL ?SECTION ESTABLISHED ?SECTION RELATED ?SECTION INVALID ?SECTION UNTRACKED ?SECTION NEW Invalid(DROP) net $FW tcp Ping(DROP) net $FW ACCEPT $FW net icmp Web(ACCEPT) net $FW ACCEPT net $FW tcp 443 #HTTPS ACCEPT net $FW tcp 60319 #SSH ACCEPT net $FW tcp 587 #SUBMISSION SERVICE DOVECOT ACCEPT net $FW tcp 995 #SUBMISSION SERVICE DOVECOT SSL/TSL ACCEPT net $FW tcp 993 #SUBMISSION SERVICE DOVECOT SSL/TSL ACCEPT net $FW tcp 110 #SUBMISSION SERVICE DOVECOT STARTTLS ACCEPT net $FW tcp 143 #DOVECOT POSTFIX ACCEPT net $FW tcp 25 #POSTFIX ACCEPT net $FW tcp 21 #PROFTP ACCEPT net $FW tcp 22 #PROSFTP SSH(ACCEPT) net $FW tcp #PROSFTP Now I wondering where is the problem, I've Fail2ban installed too and I've already clarified in its ML that this is not a problem that concerns F2B A thanks to all those who want to help me better understand this issue! Davide Italy -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] ProFtpd Shorewall DROP net-fw TLS connection from client ftp
On 08/09/2017 01:28 AM, Davide Marchi wrote: > Hi friends, > > On Debian Jessie, > I've configured ProFtpd to connect by tls (SSLv3 TLSv1 -> Letsencypt > certificate) on port but with Shorewall up, it DROP the connection: > > > Aug 8 18:50:10 server kernel: [16438563.572121] > Shorewall:net-fw:DROP:IN=eth0 OUT= > MAC=00:50:56:3c:a8:50:00:08:e3:ff:fd:90:08:00 SRC=132.142.22.10 > DST=44.320.032.111 LEN=60 TOS=0x00 PREC=0x00 TTL=56 ID=63283 DF > PROTO=TCP SPT=33175 DPT=55298 WINDOW=29200 RES=0x00 SYN URGP=0 > > > My rules.conf: > > PORTPORT(S)DEST > LIMITGROUP > ?SECTION ALL > ?SECTION ESTABLISHED > ?SECTION RELATED > ?SECTION INVALID > ?SECTION UNTRACKED > ?SECTION NEW > > Invalid(DROP) net$FWtcp > > Ping(DROP)net$FW > > ACCEPT$FWneticmp > > Web(ACCEPT) net $FW > ACCEPT net $FW tcp 443 > #HTTPS > ACCEPT net $FWtcp60319 #SSH > ACCEPT net $FW tcp 587 > #SUBMISSION SERVICE DOVECOT > ACCEPT net $FW tcp 995 > #SUBMISSION SERVICE DOVECOT SSL/TSL > ACCEPT net $FW tcp 993 > #SUBMISSION SERVICE DOVECOT SSL/TSL > ACCEPT net $FW tcp 110 > #SUBMISSION SERVICE DOVECOT STARTTLS > ACCEPT net $FW tcp 143 > #DOVECOT POSTFIX > ACCEPT net $FW tcp 25 > #POSTFIX > ACCEPT net $FW tcp 21 > #PROFTP > ACCEPT net $FW tcp 22 > #PROSFTP > SSH(ACCEPT)net$FWtcp #PROSFTP > > > > Now I wondering where is the problem, > > I've Fail2ban installed too and I've already clarified in its ML that > this is not a problem that concerns F2B > > > A thanks to all those who want to help me better understand this issue! To handle a protocol like FTP, Netfilter must inspect each packet of the control connection in order to be able to automatically open data connections. When the control connection is encrypted, it can't do that and hence data connections are rejected. To work around this, you will need to specify a range of passive ports in the ProFtpd configuration, then open that port range in Shorewall. To handle active mode connections, you would also need to open outbound connections whose source port is 20 (that is the default, anyway). SFTP is the preferred way to do Secure file transfer, as it is SSH-based and does not use separate control and data connections. With SFTP, you simply open the incoming connection in your Shorewall configuration. -Tom -- Tom Eastep\ Q: What do you get when you cross a mobster with Shoreline, \ an international standard? Washington, USA \ A: Someone who makes you an offer you can't http://shorewall.org \ understand \___ signature.asc Description: OpenPGP digital signature -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] shorewall reload / restart
On 08/09/2017 12:56 AM, Vieri Di Paola via Shorewall-users wrote: > Hi, > > I read the shorewall man page regarding the "reload" and "restart" commands. > From a practical point of view and with default shorewall.conf settings in > 5.1, if I change/add/delete entries in the "rules" file, and issue the > "reload" command then I should expect the following: > > - existing connections will not be affected > - the "new rules" will be processed and applied > > Same thing should happen when changing entries in snat, mangle, routes, > rtrules. The params file should also be re-read. > > Correct? > > So, with shorewall >=5.0.15, when would it be useful to issue the "restart" > command? The only scenario I can think of is if I wanted to interrupt active > connections (or at least preserve only those in "stoppedrules"). > With ADMINISABSENTMINDED=Yes, active connections are not interrupted during restart. New connections not allowed by stoppedrules are denied during the time that the firewall is stopped. With RESTART=restart, doing a 'restart' allows the 'stop' and 'stopped' extension scripts to be executed whereas 'reload' does not. So if you have something in those scripts that you want done, then 'restart' is appropriate. -Tom -- Tom Eastep\ Q: What do you get when you cross a mobster with Shoreline, \ an international standard? Washington, USA \ A: Someone who makes you an offer you can't http://shorewall.org \ understand \___ signature.asc Description: OpenPGP digital signature -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] DOCKER issue
On 08/08/2017 08:42 PM, Roland Schmid wrote: > Hi Tom, > > Thanks for the response, sadly didn't work. > Please find the 2 requested shorewall dumps attached > Docker isn't installing any meaningful rules. From the first dump: In the filter table, both the DOCKER and DOCKER-ISOLATION chains are empty. Chain DOCKER (0 references) pkts bytes target prot opt in out source destination Chain DOCKER-ISOLATION (0 references) pkts bytes target prot opt in out source destination In the nat table: Chain PREROUTING (policy ACCEPT 49 packets, 2913 bytes) pkts bytes target prot opt in out source destination 105 6506 DOCKER all -- * * 0.0.0.0/0 0.0.0.0/0ADDRTYPE match dst-type LOCAL That sends all incoming connection requests that have a LOCAL destination (address on the firewall) to the DOCKER chain. Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 DOCKER all -- * * 0.0.0.0/0 !127.0.0.0/8 ADDRTYPE match dst-type LOCAL 0 0 DOCKER all -- * * 0.0.0.0/0 !127.0.0.0/8 ADDRTYPE match dst-type LOCAL 0 0 DOCKER all -- * * 0.0.0.0/0 !127.0.0.0/8 ADDRTYPE match dst-type LOCAL 0 0 DOCKER all -- * * 0.0.0.0/0 !127.0.0.0/8 ADDRTYPE match dst-type LOCAL 0 0 DOCKER all -- * * 0.0.0.0/0 !127.0.0.0/8 ADDRTYPE match dst-type LOCAL 0 0 DOCKER all -- * * 0.0.0.0/0 !127.0.0.0/8 ADDRTYPE match dst-type LOCAL 0 0 DOCKER all -- * * 0.0.0.0/0 !127.0.0.0/8 ADDRTYPE match dst-type LOCAL 0 0 DOCKER all -- * * 0.0.0.0/0 !127.0.0.0/8 ADDRTYPE match dst-type LOCAL 0 0 DOCKER all -- * * 0.0.0.0/0 !127.0.0.0/8 ADDRTYPE match dst-type LOCAL 0 0 DOCKER all -- * * 0.0.0.0/0 !127.0.0.0/8 ADDRTYPE match dst-type LOCAL 0 0 DOCKER all -- * * 0.0.0.0/0 !127.0.0.0/8 ADDRTYPE match dst-type LOCAL 0 0 DOCKER all -- * * 0.0.0.0/0 !127.0.0.0/8 ADDRTYPE match dst-type LOCAL Same for outgoing connection to a local destination other than the loopback network. For some unknown reason, that rule is repeated 12 times. Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 MASQUERADE all -- * !docker0 172.17.0.0/16 0.0.0.0/0 After routing, all connection requests from 172.17.0.0/16 whose destination is not the docker0 bridge, are masqueraded. Chain DOCKER (13 references) pkts bytes target prot opt in out source destination 0 0 RETURN all -- docker0 * 0.0.0.0/0 0.0.0.0/0 The DOCKER chain does nothing but return for connections originating in a container. All of that nonsense is preserved when Shorewall starts, which is what Shorewall attempts to do when DOCKER=Yes. In addition, Shorewall creates many rules in the DOCKER-ISOLATION chain, but since Docker isn't generating any jumps to that chain, those rules are ignored. This is totally unlike anything I've seen from Docker. I've changed the Subject in this response in the hope that someone who knows more about Docker than I do can help. In the meantime, I suspect that this will work if you add DNAT rules for the traffic that you wish to forward from the wan zone to the dock zone. I normally see those rules generated by Docker itself. -Tom -- Tom Eastep\ Q: What do you get when you cross a mobster with Shoreline, \ an international standard? Washington, USA \ A: Someone who makes you an offer you can't http://shorewall.org \ understand \___ signature.asc Description: OpenPGP digital signature -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] ProFtpd Shorewall DROP net-fw TLS connection from client ftp
[..] To handle a protocol like FTP, Netfilter must inspect each packet of the control connection in order to be able to automatically open data connections. When the control connection is encrypted, it can't do that and hence data connections are rejected. To work around this, you will need to specify a range of passive ports in the ProFtpd configuration, then open that port range in Shorewall. To handle active mode connections, you would also need to open outbound connections whose source port is 20 (that is the default, anyway). Well, I confirm that the problem was "only" the enabling of the ProFtpd passive ports and the relative shorewall ports: ProFtpd (sftp.conf-> that could be now tls.conf or ftps.conf) : PassivePorts49152 65534 Shorewall (rules): ACCEPT net $FW tcp 49152:65534 #PROSFTP PASSIVE PORT SFTP is the preferred way to do Secure file transfer, as it is SSH-based and does not use separate control and data connections. With SFTP, you simply open the incoming connection in your Shorewall configuration. -Tom I opted for FTPS because I preferred to use the Letsencrypt certificates instead of self signed. I was wrong? :-) Thanks Tom for your very appreciated help! Davide -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
[Shorewall-users] Shorewall 5.1.6 Beta 2
Shorewall 5.1.6 Beta 2 is now available for testing. Problems Corrected since Beta 1: 1) http://www.shorewall.net/shorewall_extension_scripts.htm states that $SHAREDIR and $CONFDIR can be used in extension scripts, that has not been true for some time. Beginning with this release, those variables are once again available in the generated script. 2) Under very rare circumstances, when OPTIMIZE level 8 was used, messages such as the following could be issued during compilation: Use of uninitialized value in hash element at /usr/share/shorewall/Shorewall/Rules.pm line 818. Use of uninitialized value in concatenation (.) or string at /usr/share/shorewall/Shorewall/Rules.pm line 823. That has been corrected. New Features since Beta 1: 1) The two new run-time extensions scripts (enabled and disabled) have been enhanced Like all run-time extension scripts, the contents of each script are placed in a function body. In the case of these new scripts, the function is passed arguments: $1 = the physical name of the interface $2 = the logical name of the interface $3 = the name of the Provider, if any, associated with the interface. Thank you for testing, -Tom -- Tom Eastep\ Q: What do you get when you cross a mobster with Shoreline, \ an international standard? Washington, USA \ A: Someone who makes you an offer you can't http://shorewall.org \ understand \___ signature.asc Description: OpenPGP digital signature -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
[Shorewall-users] Documentation error?
Trying to set up a transparent proxy I'm slightly confused by the following towards the end of http://shorewall.net/Shorewall_Squid_Usage.html : |/etc/shorewall/mangle| (assume loc interface is eth1 and net interface is eth0): #ACTION SOURCE DESTPROTO DPORT SPORT DIVERT eth00.0.0.0/0 tcp- 80 TPROXY(3129)eth10.0.0.0/0 tcp80 Corresponding |/etc/shorewall/mangle| are: #MARK SOURCE DESTPROTO DPORT SPORT DIVERT eth00.0.0.0/0 tcp- 80 TPROXY(3129)eth10.0.0.0/0 tcp80 I presume "Corresponding..." down to the end of the quote is an unintentional duplicate. If not, I'm even more confused as mangle doesn't have a MARK column. Regards - Philip -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] Documentation error?
From: Philip Le Riche > > I presume "Corresponding..." down to the end of the quote is an unintentional > duplicate. It is. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] Documentation error?
On 08/09/2017 03:03 PM, Philip Le Riche wrote: > Trying to set up a transparent proxy I'm slightly confused by the > following towards the end of > http://shorewall.net/Shorewall_Squid_Usage.html : > > |/etc/shorewall/mangle| (assume loc interface is eth1 and net interface > is eth0): > > #ACTION SOURCE DESTPROTO DPORT SPORT > DIVERT eth00.0.0.0/0 tcp- 80 > TPROXY(3129)eth10.0.0.0/0 tcp80 > > Corresponding |/etc/shorewall/mangle| are: > > #MARK SOURCE DESTPROTO DPORT SPORT > DIVERT eth00.0.0.0/0 tcp- 80 > TPROXY(3129)eth10.0.0.0/0 tcp80 > > I presume "Corresponding..." down to the end of the quote is an unintentional > duplicate. If not, I'm even more confused as mangle doesn't have a MARK > column. > > That should read: Corrseponding /etc/shorewall/tcrules are: The tcrules file DID have a MARK column. -Tom -- Tom Eastep\ Q: What do you get when you cross a mobster with Shoreline, \ an international standard? Washington, USA \ A: Someone who makes you an offer you can't http://shorewall.org \ understand \___ signature.asc Description: OpenPGP digital signature -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users