Re: [Shorewall-users] shorewall multi-isp snat with 3 ppp interfaces
On 10/08/2018 06:01 AM, Vieri Di Paola via Shorewall-users wrote: > > > On Friday, October 5, 2018, 6:42:46 PM GMT+2, Tom Eastep > wrote: > >>> >>> However, all 3 providers are up and running, ie., I can successfully ping >>> to a remote host through their interfaces. >>> I need to manually run "shorewall enable INTERFACE" and restart shorewall. >>> No issues from this point onwards. >>> So why is Shorewall complaining about the interfaces? How does it decide if >>> it's "usable"? >> >> You can read the code for yourself. It is contained in the shell >> function interface_is_usable(). Note that with the standard >> /etc/shorewall/isusable script, once a persistent interface is >> determined to be unusable, the only way to make it usable again is to >> use the 'enable' (or reenable) command. > > By the way, here's what I've noticed: > > # ip -4 link list dev ppp3 > 11: ppp3: mtu 1492 qdisc fq_codel > state UNKNOWN mode DEFAULT group default qlen 3 > link/ppp > > # ip -4 link list dev ppp2 > 8: ppp2: mtu 1492 qdisc fq_codel > state UNKNOWN mode DEFAULT group default qlen 3 link/ppp > > # ip -4 link list dev ppp1 > 7: ppp1: mtu 1492 qdisc fq_codel > state UNKNOWN mode DEFAULT group default qlen 3 > link/ppp > > > The "state" is UNKNOWN instead of UP, but the links are "really up"... > The code in interface_is_usable() is only checking for 'state DOWN', so UNKNOWN is considered to be UP. -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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] shorewall multi-isp snat with 3 ppp interfaces
On 10/08/2018 05:53 AM, Vieri Di Paola via Shorewall-users wrote: > On Friday, October 5, 2018, 6:51:04 PM GMT+2, Tom Eastep > wrote: > >>> >>> Finally, a shorewall restart (full stop and start) actually DID solve the >>> issue. I magically got my ppp3 link working again. >>> So, of course, I'm worried that if there's a power outage or if someone >>> reboots the modems then the gateway might get cut off from the Internet if >>> shorewall doesn't restart. >> >> I can't comment without seeing the difference between the ruleset after > '> reenable' and the ruleset after 'restart'. > > Here's the dump after "reenable ppp3" (no traffic through provider): > > https://drive.google.com/open?id=13MOhqHX7Im6uu8khr5DQTNuMypxQG8U3 It is remarkable that there was no traffic via ppp3, given that ppp3 was the ONLY interface that should have been working. > > And here's the dump after "restart" (traffic OK through provider): > > https://drive.google.com/open?id=1GKOjtcEzc8H7JLI1V7hgPwMe3n6ECiXg There are two significant differences between the two dumps: - Given that you specify 'defaultroute' in your ppp configuraton, the following route appears in the 'main' table after you have brought ppp3 back up: default via 192.168.144.1 dev ppp3 metric 4009 'reenable' does not delete that route, but 'restart' and 'reload' do delete the route. This issue will be corrected by omitting 'defaultroute' from your ppp configuration. - In the 'balance' table, we have this route after 'reenable': default dev ppp3 After 'restart', we have: default nexthop dev ppp1 weight 1 nexthop dev ppp2 weight 1 nexthop dev ppp3 weight 1 I'm not sure what to make of this: - 'reenable' is the same as 'disable' then 'enable' - After the 'disable', there was apparently no default route in the 'balance' table, but we don't know what was there before the 'disable'. At the next opportunity that you have to disrupt the firewall, it would be instructive to do the following: shorewall show routing > routing1 shorewall disable ppp3 shorewall show routing > routing2 shorewall enable ppp3 shorewall show routing > routing3 If you don't feel that traffic is being sent via ppp3, then shorewall reload shorewall show routing > routing4 Thanks! > >>>> 10003: enp6s0: mtu 1500 qdisc tbf state >>>> UP group default qlen >>> 3: enp6s0: mtu 1500 qdisc fq_codel state >>> UP group default qlen 1000 >>> I still don't know why some interfaces are set to use pfifo_fast, or if >>> it's recommended or not for a gateway/router. >> >> Which has nothing to do with Shorewall... > > OK, I was just asking because the tbf qdisc is set by Shorewall when enabling > traffic shaping. Also , /usr/share/shorewall/Shorewall/Tc.pm seems to deal > with fq_codel, and there's documentation referencing fq_codel here: > > http://shorewall.net/manpages4/manpages/shorewall-tcclasses.html > http://shorewall.org/traffic_shaping.htm > > Anyway, I'll study that later on if time permits. > What I really meant was that setting fq_codel as the default queuing discipline has nothing to do with Shorewall, and I can't comment on whether that is a good idea or not. -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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] shorewall multi-isp snat with 3 ppp interfaces
On 10/09/2018 02:10 AM, Vieri Di Paola via Shorewall-users wrote:
>
>
> On Monday, October 8, 2018, 7:30:45 PM GMT+2, Tom Eastep
> wrote:
>> default via 192.168.144.1 dev ppp3 metric 4009
>>
>> 'reenable' does not delete that route, but 'restart' and 'reload' do
>> delete the route.
>>
>> This issue will be corrected by omitting 'defaultroute' from your
>> ppp configuration.
> I removed that option. Now my ppp options are as follows:
>
> noauth
> persist
> holdoff 0
> maxfail 0
> noaccomp noccp nobsdcomp nodeflate nopcomp novj novjccomp
>
> Restarting both the ppp links and shorewall works as expected (this
> contradicts one of my previous findings that I required the default route,
> but at this point it's better to just look forward).
>
> So let's move on to the test. Just to make things a tad more exciting, I
> found out that my pppoe links do not re-sync at all after rebooting my
> modems, ie., nothing in syslog indicates that pppd has tried to reconnect to
> my providers. I don't know if it's due to the "UNKNOWN state" of all my ppp
> links, or if I'm not setting up my ppp options appropriately. In any case, I
> am required to manually restart my ppp script each time I reboot a modem...
> So here's the script I ran today:
>
> ping -c 5 -n -I ppp3 8.8.8.8
> shorewall show routing > routing0
> echo "Reboot modem (ISP3), and wait until it's back up again (check ppp
> ip-up.d script), then press ENTER"
> read
> shorewall show routing > routing1
> shorewall disable ppp3
> shorewall show routing > routing2
> shorewall enable ppp3
> shorewall show routing > routing3
> ping -c 5 -n -I ppp3 8.8.8.8
> echo "Press ENTER if ping fails"
> read
> shorewall reload
> ping -c 5 -n -I ppp3 8.8.8.8
> shorewall show routing > routing4
> echo "Press ENTER if ping fails again"
> read
> /etc/init.d/net.ppp3 restart
> echo "Check ppp ip-up.d script and press ENTER"
> read
> shorewall show routing > routing1b
> shorewall disable ppp3
> shorewall show routing > routing2b
> shorewall enable ppp3
> shorewall show routing > routing3b
> ping -c 5 -n -I ppp3 8.8.8.8
> echo "Press ENTER if ping fails"
> read
> shorewall reload
> ping -c 5 -n -I ppp3 8.8.8.8
> shorewall show routing > routing4b
>
>
> The ping test above starts working ONLY after the last shorewall reload -- so
> routing4b is the working config (routing0 too, of course).
>
> In the link below you will find the routing* files and a custom ppp ip-up.d
> script (99-custom.sh) with the related output in ppp_up_data which was
> obtained only after restarting the net.ppp3 init script.
>
> https://drive.google.com/open?id=1Ly445Qzx9RXICMeC5UdQ9YK5Hcgywtf2
>
> The only difference between the dump after reenabling ppp3 (routing3b) and
> reloading shorewall (routing4b) is:
>
> -default dev ppp3
> +default nexthop dev ppp1 weight 1 nexthop dev ppp2 weight 1 nexthop dev ppp3
> weight 1
>
> Just one last test... I decided to restart the ppp3 init script without
> rebooting the modem or restarting shorewall.
>
> # ping -n -I ppp3 8.8.8.8
> 64 bytes from 8.8.8.8: icmp_seq=1 ttl=121 time=14.0 ms
> ping: sendmsg: Network is unreachable
> ping: sendmsg: Network is unreachable
> ping: sendmsg: Network is unreachable
> ^C
>
> Please find the routing data here:
>
> https://drive.google.com/open?id=1K8DB5Xs05MuMG1botQ3htLlsh3MrPB4F
>
> In this case "shorewall reenable ppp3" DOES restore proper traffic through
> ppp3.
> Please note that when I reboot the modem the local public ppp-assigned IP
> address may have changed. It was the case in my routing{1-4}{,b} test above,
> but not in this one.
>
> Still don't quite get why I'm getting the "Network is unreachable" message
> before reenabling in the last test.
Okay -- lets go through the routing* files one by one:
a) routing0 and routing1 are identical.
b) Disabling ppp3 results in it being removed from the balanced route
and in the removal of the fwmark rule for that provider which is correct.
--- routing1 2018-10-09 01:04:53.0 -0700
+++ routing2 2018-10-09 01:04:53.0 -0700
@@ -7,7 +7,6 @@
999: from all lookup main
1: from all fwmark 0x1/0xff lookup ISP1
10001: from all fwmark 0x2/0xff lookup ISP2
-10002: from all fwmark 0x3/0xff lookup ISP3
2: from 83.61.3.216 lookup ISP1
2: from 79.148.120.225 lookup ISP2
2: from 83.50.142.116 lookup ISP3
@@ -28,7 +27,7 @@
Table balance:
-default nexthop dev ppp1 weight 1 nexthop
Re: [Shorewall-users] shorewall6: How to match packets that would leave through same interface but are rejected since forwading/routing back is prohibited?
On 10/09/2018 01:34 PM, Timo Sigurdsson wrote: > Hi, > > I use shorewall 5.0.15.6 on Debian Stretch in a dual stack setup. On a > reugular basis, I get a bunch of the following messages in my log files (my > shorewall log prefix is just FW): > kernel: [102654.492757] FW:FORWARD:REJECT:IN=ppp0 OUT=ppp0 MAC= > SRC=2001:4ca0:0108:0042::0080:0006:0009 > DST=2001:14c9:1131:1320:8b80:2765:3c6a:2f19 LEN=80 TC=0 HOPLIMIT=244 > FLOWLBL=0 PROTO=TCP SPT=50625 DPT=80 WINDOW=65535 RES=0x00 SYN URGP=0 > The destination ports and protocols vary, but these packets actually all come > from the same network. > > Now, can understand why these packets are rejected. The prefix in DST > actually matches my IPv6 prefix which is assigned to the interface ppp0, but > the interface identifier doesn't. And routing back through the same interface > is neither desired nor allowed on my network: > > The relevant lines in shorewall6/interfaces and shorewall6/policy look like > this: > shorewall6/interfaces: > net ppp0 > dhcp,accept_ra=2,tcpflags,nosmurfs,rpfilter,sourceroute=0 > > shorewall6/policy: > $FW net ACCEPT > [...] > net all DROP > # THE FOLLOWING POLICY MUST BE LAST > all all REJECT info > > So basically, these packets hit the all-all reject policy. What I would like > to do however, is to drop these packets without logging (and I do not want to > change my default policy for that). How can I match these packets? I have > tried several approaches that all didn't work: > > 1) I added a policy that said: > net net DROP > Didn't work and also should be redundant due to the net-all drop rule. > > 2) I added rules in shorewall6/rules to match the source of the traffic > (which are servers by a university in Munich that try to map/scan the IPv6 > address space): > DROP:nonenet:[2001:4ca0:108:42::]/64 all tcp 80 > DROP:nonenet:[2001:4ca0:108:42::]/64 all tcp 443 > DROP:nonenet:[2001:4ca0:108:42::]/64 all udp 443 > DROP:nonenet:[2001:4ca0:108:42::]/64 all udp 53 > DROP:nonenet:[2001:4ca0:108:42::]/64 all ipv6-icmp 128 > I tried it in both ?SECTION NEW as well as ?SECTION ALL - didn't work. > > 3) I tried adding the source of these packets to my blacklist rules > (shorewall6/blrules) in the same manner, and still they'd show up in my logs. > > > So, I'm lost here. *Is it possible to somehow match these packets in order to > drop them silently?* My preference would be to simply drop all packets coming > from the net zone that would be forwarded back through the same interface. > But if I have to specify the source, that would be ok as well. > > For reference I also include my traffic dispositions and log levels from my > shorewall6 configuration file: > grep -e LOG_LEVEL -e DISPOSITION shorewall6/shorewall6.conf > BLACKLIST_LOG_LEVEL=info > INVALID_LOG_LEVEL= > MACLIST_LOG_LEVEL=info > RELATED_LOG_LEVEL= > RPFILTER_LOG_LEVEL=none > SFILTER_LOG_LEVEL=info > SMURF_LOG_LEVEL=info > TCP_FLAGS_LOG_LEVEL=info > UNTRACKED_LOG_LEVEL= > BLACKLIST_DISPOSITION=DROP > INVALID_DISPOSITION=CONTINUE > MACLIST_DISPOSITION=REJECT > RELATED_DISPOSITION=ACCEPT > SFILTER_DISPOSITION=DROP > RPFILTER_DISPOSITION=DROP > SMURF_DISPOSITION=DROP > TCP_FLAGS_DISPOSITION=DROP > UNTRACKED_DISPOSITION=CONTINUE > > I'd aprreciate if someone could point me in the right direction on how to get > rid of these log messages. Thank you! > a) Set the 'routeback' option on ppp0 in /etc/shorewall/interfaces. b) Add your proposed net->net DROP policy BEFORE your current net->all policy. -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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] Escaping of minus-sign in interface name
On 10/10/2018 07:04 AM, Jan Bergner wrote: > Dear shorewall-users list, > > I have some virtual network interfaces due to the fact, I use > systemd-nspawn-containers which get names containing a minus sign. (The > scheme is basically "ve-MACHINE_NAME".) > > Unfortunately, I cannot seem to find any indication on how to treat such > an interface name in, say, a zone assignment. > > In particular, I would like to have an /etc/shorewall/interfaces like this: > > #ZONE INTERFACE BROADCAST OPTIONS > > net eth+ detect dhcp > nspa ve-m1 detect dhcp > nspa ve-m2 detect dhcp > nspb ve-m3 detect dhcp > nspb ve-m4 detect dhcp > oth + detect dhcp > > > However, this does not seem to be working; my interfaces end up in the > oth-zone, as can be expected, since this is my catch-all-zone, assuming > the ve-interfaces are not recognized, properly.) > > Initially, I thought there mus be a simple way of escaping this, but I > could not seem to find it. > > Can someone give me a hint? > > > Thanks in advance and best regards, > Which Shorewall version are you using? Your interfaces file above is FORMAT 1, which suggests that the version is quite old. -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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] shorewall6: How to match packets that would leave through same interface but are rejected since forwading/routing back is prohibited?
On 10/10/2018 01:54 AM, Timo Sigurdsson wrote: > Hi Tom, > > Tom Eastep schrieb am 09.10.2018 23:42: >> On 10/09/2018 01:34 PM, Timo Sigurdsson wrote: >>> Hi, >>> >>> I use shorewall 5.0.15.6 on Debian Stretch in a dual stack setup. On a >>> reugular basis, I get a bunch of the following messages in my log files (my >>> shorewall log prefix is just FW): >>> kernel: [102654.492757] FW:FORWARD:REJECT:IN=ppp0 OUT=ppp0 MAC= >>> SRC=2001:4ca0:0108:0042::0080:0006:0009 >>> DST=2001:14c9:1131:1320:8b80:2765:3c6a:2f19 LEN=80 TC=0 HOPLIMIT=244 >>> FLOWLBL=0 >>> PROTO=TCP SPT=50625 DPT=80 WINDOW=65535 RES=0x00 SYN URGP=0 > >>> The relevant lines in shorewall6/interfaces and shorewall6/policy look like >>> this: >>> shorewall6/interfaces: >>> net ppp0 >>> dhcp,accept_ra=2,tcpflags,nosmurfs,rpfilter,sourceroute=0 >>> >>> shorewall6/policy: >>> $FW net ACCEPT >>> [...] >>> net all DROP >>> # THE FOLLOWING POLICY MUST BE LAST >>> all all REJECT info >>> >>> So basically, these packets hit the all-all reject policy. What I would like >>> to do however, is to drop these packets without logging (and I do not want >>> to >>> change my default policy for that). How can I match these packets? I have >>> tried several approaches that all didn't work: >>> >>> 1) I added a policy that said: >>> net net DROP >>> Didn't work and also should be redundant due to the net-all drop rule. >>> > >>> I'd aprreciate if someone could point me in the right direction on how to >>> get >>> rid of these log messages. Thank you! >>> >> >> a) Set the 'routeback' option on ppp0 in /etc/shorewall/interfaces. >> b) Add your proposed net->net DROP policy BEFORE your current net->all >> policy. > > thanks for the tip. It sounds a bit counter-intuitive, but I'll give it > a try. I have two follow-up questions, though: > > 1) Wouldn't my net-all drop policy already imply net-net drop? Yes -- but your net->all policy specifies logging which you don't want. > > 2) If I add the routeback option to my ppp0 interface, are there any > drawbacks to be aware of or security risks attached? No. > > The man page suggests adding the routefilter option when routeback is > enabled. As routefilter is IPv4-only, am I correct to assume the > rpfilter option that I have set serves this purpose just as well? Yes. > In addition, the man page suggests to enable route filtering on *all* > interfaces which I currently don't have. So, should I set rpfilter > on my other interfaces when I set routeback on ppp0? I don't have have > bridge interfaces or so, so I don't expect issues on my internal > network with rpfilter. Yes, rpfilter is advisable on all interfaces. > > And one more question that is not strictly related to shorewall, but > it occured to me this morning: Would it be possible to filter away > these packets with a blackhole route via 'ip route'? Or do > iptables/netfilter rules come into play before the blackhole route > would be applied? > Blackhole routes are applied before Shorewall filter rules. They would be a solution if: a) You can identify the full set of destination networks involved; and b) You have no reason to access these networks yourself. -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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] Escaping of minus-sign in interface name
On 10/11/2018 05:36 AM, Jan Bergner wrote: > Am 10.10.18 um 18:14 schrieb Tom Eastep: >> On 10/10/2018 07:04 AM, Jan Bergner wrote: >>> Dear shorewall-users list, >>> >>> I have some virtual network interfaces due to the fact, I use >>> systemd-nspawn-containers which get names containing a minus sign. (The >>> scheme is basically "ve-MACHINE_NAME".) >>> >>> Unfortunately, I cannot seem to find any indication on how to treat such >>> an interface name in, say, a zone assignment. >>> >>> In particular, I would like to have an /etc/shorewall/interfaces like this: >>> >>> #ZONE INTERFACE BROADCAST OPTIONS >>> >>> net eth+ detect dhcp >>> nspa ve-m1 detect dhcp >>> nspa ve-m2 detect dhcp >>> nspb ve-m3 detect dhcp >>> nspb ve-m4 detect dhcp >>> oth + detect dhcp >>> >>> >>> However, this does not seem to be working; my interfaces end up in the >>> oth-zone, as can be expected, since this is my catch-all-zone, assuming >>> the ve-interfaces are not recognized, properly.) >>> >>> Initially, I thought there mus be a simple way of escaping this, but I >>> could not seem to find it. >>> >>> Can someone give me a hint? >>> >>> >>> Thanks in advance and best regards, >>> >> Which Shorewall version are you using? Your interfaces file above is >> FORMAT 1, which suggests that the version is quite old. >> >> -Tom > > Hello Tom, > > thank you for your response. > > On this particular system, we use the official version, shipped with > Debian 9. (5.0.15.6) > > However, we produce some IoT devices, based on OpenEmbedded, that are > using version 4.4.14, and we try to use a config style that is working > for both versions. > > Thus, we use the old format, indeed. > Okay - I believe that something else is going on in your configuration that is causing the issue. It would be helpful if you would: a) shorewall show -f capabilities > /etc/shorewall/capabilities b) Tar up your /etc/shorewall/ directory and sent the tar file to me privately. Thanks! -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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] VPN rules and policies
On 10/12/2018 05:20 PM, Alex wrote: > Hi, > > I'm running shorewall-5.2.0.4 on fedora28 and using it with > libreswan-3.27. I'm trying to build a net-to-net VPN as well as a > host-to-host VPN using libreswan and trying to figure out the best way > to protect them using shorewall. > > Both VPNs originate from our main external gateway, 68.195.192.42 > (orion). Our local network, 192.168.1.0/24 is behind it, currently > being masqueraded using shorewall and iptables. > > I'd like to build the net-to-net VPN to 65.46.71.6 (cyclops) and the > host-to-host VPN to 107.154.66.2 (arcade). > > I've defined four zones: > fw - firewall > ext - external (ipv4) > int - internal LAN (ipv4) > vpn - ipsec > > I don't believe my tunnels are set up correctly, though. There are > still rejects from the remote firewall in the logs: > > [173907.906648] ext-fw REJECT IN=br0 OUT= > MAC=0c:c4:7a:a9:18:de:a4:15:88:a9:30:b7:08:00 SRC=65.46.71.6 > DST=68.195.192.42 LEN=628 TOS=0x00 PREC=0x00 TTL=52 ID=190 DF > PROTO=UDP SPT=500 DPT=500 LEN=608 > > Is this being caused by an incorrect policy? Should it be necessary to > have individual rules allowing esp and UDP 500, or is that what the > ipsec designation is for in the zones file? > > I'm trying to follow the IPSEC-2.6.html page and it's confusing. It > never explicitly states what the 'loc' and 'net' zones actually are, > and it appears to contradict itself with regards to the zone file. > > It would be helpful if the full configuration was provided in the > "IPsec Gateway on the Firewall System" example. > > Here is the configuration I've set on our local side (orion). The > remote side (cyclops) is just a simple iptables firewall. I'm hoping > someone can review and give me an idea of why it's failing. > > tunnels: > ipsecvpn65.46.71.6 This should be: ipsec ext 64.46.71.6 -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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] VPN rules and policies
On 10/13/2018 07:37 PM, Alex wrote: > Hi, > > >>> tunnels: >>> ipsecvpn65.46.71.6 >> >> This should be: >> >> ipsec ext 64.46.71.6 > > Should I add another line for the other ipsec tunnel as well? > > ipsecext 107.155.66.2 > Yes. -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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] DNAT, ACCEPT, ADD in rules
On 10/15/2018 05:07 AM, Vieri Di Paola via Shorewall-users wrote: > Hi, > > I have the following in my rules file: > > DNAT net2:!+IPS_BL,+POL_BL,+GEO_BL,+GEOIPS_BL loc:10.215.145.81 > tcp 80,443 - - 30/min:35 > [...] > ADD(POL_BL:src):info:polbl,add2polbl net1,net2,net3:!+POL_BL,+GLOBAL_WL > all tcp,udp - !443,80,25,3389 > > Suppose host at x.x.x.x tries to access via port 80 through shorewall, I > understand the connection should have been DNAT'ed, right? > In no case should it had been added to the POL_BL ipset, right? > However, in shorewall's log I can see the following line: > > Oct 15 10:48:09 Shorewall:polbl:add2polbl:IN=ppp2 OUT= MAC= SRC=x.x.x.x > DST=y.y.y.y LEN=52 TOS=0x00 PREC=0x00 TTL=116 ID=13247 DF PROTO=TCP SPT=52576 > DPT=80 WINDOW=8192 RES=0x00 SYN URGP=0 MARK=0x2 > > Any clues? If the connection rate to ports 80 and 443 from the net exceeds the LIMIT on the DNAT rule, then those connections exceeding the rate will be added to the ipset. -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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] DNAT, ACCEPT, ADD in rules
On 10/15/2018 03:15 PM, Vieri Di Paola via Shorewall-users wrote: > On Tuesday, October 16, 2018, 12:08:35 AM GMT+2, Vieri Di Paola via > Shorewall-users wrote: > >>>> DNAT net2:!+IPS_BL,+POL_BL,+GEO_BL,+GEOIPS_BL loc:10.215.145.81 >>>> tcp 80,443 - - 30/min:35 >>>> [...] >>>> ADD(POL_BL:src):info:polbl,add2polbl net1,net2,net3:!+POL_BL,+GLOBAL_WL >>>> all tcp,udp - !443,80,25,3389 >>> >>> >>> If the connection rate to ports 80 and 443 from the net exceeds the >>> LIMIT on the DNAT rule, then those connections exceeding the rate will >>> be added to the ipset. >> >> Interesting. So, if I want to make sure the SRC IP addr. is not added to my >> POL_BL ipset then I should either remove rate limiting or use something else >> in between. > > Come to think of it, I don't understand why the connections exceeding the > rate will be added to the ipset if the ADD() action excludes dst ports 80 and > 443 (!443,80). > Because you are excluding SOURCE ports, not DESTINATION ports... -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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] Why is "interface not usable"?
On 10/17/18 3:47 AM, Leroy Tennison wrote: > (eth9 is up, has the assigned IP address and $INTERNET_GW is pingable, > afterward arp -n shows the correct MAC address, similarly all of the > "copy" interfaces exist and are up). The below is the providers entry > > yellow 1 1 main eth9 > $INTERNET_GW track eth0,eth3,eth5,tun0 > > 'shorewall start' returns: > > ERROR: Interface eth9 is not usable -- Provider yellow (1) Cannot be Started > Terminated > > If I add : to eth9 I get: > > ERROR: Unable to determine the MAC address of through > interface "eth9" > > Can anyone explain why or at least tell me what kinds of things produce > these errors? Thanks for any help. > The test for usability is contained in the shell function interface_is_usable() in /usr/share/shorewall/lib.runtime. Interface eth9 is usable during 'start', if: a) It is UP (the UP flag is set in the output of 'ip link ls dev eth9) b) It has an IP address assigned c) It's 'state' is not DOWN (see the output of 'ip link ls dev eth9) d) The file /var/lib/shorewall/eth9_disabled does not exist. e) The file /var/lib/shorewall/eth9.status exists and contains 0 (assuming you are using the standard /etc/shorewall/isusable script). If the problem is either d) or e), then 'shorewall enable eth9' should correct the situation. As a final note, not related to the error messages, USE_DEFAULT_RT=No is deprecated and is not advised. You are clearly using that setting since the DUPLICATE and COPY columns in the entry you show above are non-empty. -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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] Shorewall and AWS VPN [SOLVED]
On 10/18/18 10:58 AM, John Peak via Shorewall-users wrote: > Hi Tom-- You can ignore this request. When I reread the config format for > all config files I discovered where you require multiple interfaces in the > same zone to use a wildcard or be listed on multiple lines. Once I fixed > that it's working. Thanks again for the help! Glad to hear that you got it sorted out, John. -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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] About iptables using nf_tables backend on Debian
On 10/24/18 9:18 AM, Vincas Dargis wrote: > Hi, > > During today's batch of Debian Sid updates I was notified about this > iptables change: > > ``` > iptables (1.8.1-1) unstable; urgency=medium > > By default, this package will try to use the nf_tables kernel backend > instead of the xtables one. Please, read more about this in > /usr/share/doc/iptables/README.Debian, including details about the new > update-alternatives configuration possibilities. > This is a major update on the way iptables works and may have severe > impact > in running systems which are upgrading between Debian versions. > The arptables and ebtables binaries are also affected, and those > packages > will be updated soon as well. > > -- Arturo Borrero Gonzalez Wed, 24 Oct 2018 > 14:00:00 +0200 > ``` > > What does that mean with regards to Shorewall? Could there potentially > be incompatibilities on how Shorewall expects Linux firewall to behave? > > I am running Shorewall on my home Sid machine, and I don't see immediate > breakage, though it runs only for an hour maybe. > There could certainly be incompatibilities that effect Shorewall and/or Shorewall6. -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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] Docker 18.03.1-ce breaks 'Docker=Yes'
On 10/26/18 10:23 AM, Anthony Rogers wrote:
> Shorewall and Docker - possible change request
>
> Current version of Shorewall => 5.1.11.1
> Docker version => 18.03.0-ce (works)
> Docker version => 18.06.1-ce (does not work)
>
> Problem statement (you may already be aware):
>
> I have been successfully using Shorewall with Docker in a development
> environment with the above earlier version.
>
> On provisioning a new server with the same version of Shorewall but the
> latest version of Docker, it no longer works.
>
> On upgrading to a later eg. 18.06 version of Docker, Shorewall no longer
> manages the firewall correctly because *docker* seems to have changed
> how it works.
>
> From their change log: "Improve scalability of bridge network isolation
> rules docker/libnetwork#2117."
>
> Diff available here:
> https://codecov.io/gh/docker/libnetwork/pull/2117/diff?src=pr&el=tree#diff-ZHJpdmVycy9icmlkZ2Uvc2V0dXBfaXBfdGFibGVzLmdv
>
>
> They seem to have deprecated chain "DOCKER-ISOLATION", and now use
> "DOCKER-ISOLATION-STAGE-1" and "DOCKER-ISOLATION-STAGE-2" instead.
>
> I suspect that Shorewall expects the former and wipes out the latter.
> This prevents new containers from being spun-up, as their networks
> cannot be created.
>
> This isn't exactly Shorewall's fault, but I suspect that a lot of people
> use its nice plug and play features with 'Docker=Yes'.
>
> Would it be straight forward to patch for this?
>
Attached is a patch that applies with offsets to 5.1.11.1.
. /usr/share/shorewall/shorewallrc
. cd $PERLDIR/Shorewall/
. patch -p4 < path/to/DOCKER-ISOLATION.patch
Please let me know how it works.
Thanks,
-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
\___
diff --git a/Shorewall/Perl/Shorewall/Chains.pm b/Shorewall/Perl/Shorewall/Chains.pm
index 4eeb49b63..af262c0bb 100644
--- a/Shorewall/Perl/Shorewall/Chains.pm
+++ b/Shorewall/Perl/Shorewall/Chains.pm
@@ -3340,10 +3340,17 @@ sub initialize_chain_table($) {
set_optflags( $chainref, DONT_OPTIMIZE | DONT_DELETE | DONT_MOVE );
add_commands( $chainref, '[ -f ${VARDIR}/.nat_DOCKER ] && cat ${VARDIR}/.nat_DOCKER >&3' );
$chainref = new_standard_chain( 'DOCKER-INGRESS' );
+ set_optflags( $chainref, DONT_OPTIMIZE | DONT_DELETE | DONT_MOVE );
+ add_commands( $chainref, '[ -f ${VARDIR}/.filter_DOCKER-INGRESS ] && cat ${VARDIR}/.filter_DOCKER-INGRESS >&3' );
$chainref = new_standard_chain( 'DOCKER-ISOLATION' );
set_optflags( $chainref, DONT_OPTIMIZE | DONT_DELETE | DONT_MOVE );
- add_commands( $chainref, '[ -f ${VARDIR}/.filter_DOCKER-INGRESS ] && cat ${VARDIR}/.filter_DOCKER-INGRESS >&3' );
- add_commands( $chainref, '[ -f ${VARDIR}/.filter_DOCKER-ISOLATION ] && cat ${VARDIR}/.filter_DOCKER-ISOLATION >&3' );
+ add_commands( $chainref, '[ -f ${VARDIR}/.filter_DOCKER-ISOLATION ] && cat ${VARDIR}/.filter_DOCKER-ISOLATION >&3' );
+ $chainref = new_standard_chain( 'DOCKER-ISOLATION-STAGE-1' );
+ set_optflags( $chainref, DONT_OPTIMIZE | DONT_DELETE | DONT_MOVE );
+ add_commands( $chainref, '[ -f ${VARDIR}/.filter_DOCKER-ISOLATION-STAGE-1 ] && cat ${VARDIR}/.filter_DOCKER-ISOLATION-STAGE-1 >&3' );
+ $chainref = new_standard_chain( 'DOCKER-ISOLATION-STAGE-2' );
+ set_optflags( $chainref, DONT_OPTIMIZE | DONT_DELETE | DONT_MOVE );
+ add_commands( $chainref, '[ -f ${VARDIR}/.filter_DOCKER-ISOLATION-STAGE-2 ] && cat ${VARDIR}/.filter_DOCKER-ISOLATION-STAGE-2 >&3' );
}
my $ruleref = transform_rule( $globals{LOGLIMIT} );
@@ -8620,7 +8627,19 @@ sub save_docker_rules($) {
qq($tool -t nat -S POSTROUTING | tail -n +2 | fgrep -v SHOREWALL > \${VARDIR}/.nat_POSTROUTING),
qq($tool -t filter -S DOCKER | tail -n +2 > \${VARDIR}/.filter_DOCKER),
qq([ -n "\$g_dockeringress" ] && $tool -t filter -S DOCKER-INGRESS | tail -n +2 > \${VARDIR}/.filter_DOCKER-INGRESS),
- qq([ -n "\$g_dockernetwork" ] && $tool -t filter -S DOCKER-ISOLATION | tail -n +2 > \${VARDIR}/.filter_DOCKER-ISOLATION)
+ qq(),
+ qq(case "\$g_dockernetwork" in),
+ qq(One\)),
+ qq(rm -f \${VARDIR}/.filter_DOCKER-ISOLATION*),
+ qq($tool -t filter -S DOCKER-ISOLATION | tail -n +2 > \${VARDIR}/.filter_DOCKER-ISOLATION),
+ qq(;;),
+ qq(Two\)),
Re: [Shorewall-users] Docker 18.03.1-ce breaks 'Docker=Yes'
On 10/27/18 4:26 AM, Anthony Rogers wrote: > Hi Tom, > > I'm just working through this. > > I'm a bit new to both Docker and Shorewall! > > I think there's a minor typo in the patch file on line 60. ' > &3' > should be '>&3', or the script errors. > > First I ran against Docker version 18.03.0-ce as a regression test. > > I fixed the patch file inside the container and 'shorewall restart' ran OK. > > I noticed that the DOCKER-USER chain was removed, however I don't > currently use it, so this might not be a problem. > > On upgrading to Docker version 18.06.1-ce, the unpatched Shorewall > removed the ISOLATION chains as expected. > > After applying the patch, the ISOLATION rules were retained, although > again the DOCKER-USER chain was removed. > > Further, I was able to both create new networks both manually and also > as part of spinning up a new container. > > The patch seems to have worked (subject to the typo), so many thanks for > your prompt help. > > Regards, > > Tony. Thanks, Tony. When the DOCKER-USER chain is present, where is it jumped to from? Thanks, -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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] Docker 18.03.1-ce breaks 'Docker=Yes'
On 10/27/18 10:44 AM, Anthony Rogers wrote:
> Hi Tom,
>
> I have attached the iptables -L after a 'docker restart' and then after
> running the shorewall script.
>
> The diff of those two log files is:
>
> 14,16d13
> < DOCKER-USER all -- anywhere anywhere
> < DOCKER-ISOLATION-STAGE-1 all -- anywhere
> anywhere
> < ACCEPT all -- anywhere anywhere ctstate
> RELATED,ESTABLISHED
> 17a15
>> ACCEPT all -- anywhere anywhere ctstate
> RELATED,ESTABLISHED
> 45c43
> < Chain DOCKER-ISOLATION-STAGE-1 (1 references)
> ---
>> Chain DOCKER-ISOLATION-STAGE-1 (0 references)
> 57,60d54
> < Chain DOCKER-USER (1 references)
> < target prot opt source destination
> < RETURN all -- anywhere anywhere
> <
> 124c118
> < Chain sha-lh-e5cf36ce25c75630550b (0 references)
> ---
>> Chain sha-lh-a054db08bd2f8e099a19 (0 references)
> 127c121
> < Chain sha-rh-f96c7a0b6585893a1b9f (0 references)
> ---
>> Chain sha-rh-3dc25e45009adb1cfa85 (0 references)
>
> Regards,
>
> Tony.
>
Okay - please apply the attached patch on top of the previous one.
Thanks Tony,
-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
\___
diff --git a/Shorewall/Perl/Shorewall/Chains.pm b/Shorewall/Perl/Shorewall/Chains.pm
index 8e203dd70..2b0bd9239 100644
--- a/Shorewall/Perl/Shorewall/Chains.pm
+++ b/Shorewall/Perl/Shorewall/Chains.pm
@@ -3341,7 +3341,10 @@ sub initialize_chain_table($) {
add_commands( $chainref, '[ -f ${VARDIR}/.nat_DOCKER ] && cat ${VARDIR}/.nat_DOCKER >&3' );
$chainref = new_standard_chain( 'DOCKER-INGRESS' );
set_optflags( $chainref, DONT_OPTIMIZE | DONT_DELETE | DONT_MOVE );
- add_commands( $chainref, '[ -f ${VARDIR}/.filter_DOCKER-INGRESS ] && cat ${VARDIR}/.filter_DOCKER-INGRESS >&3' );
+ add_commands( $chainref, '[ -f ${VARDIR}/.filter_DOCKER-INGRESS ] && cat ${VARDIR}/.filter_DOCKER-INGRESS >&3' );
+ $chainref = new_standard_chain( 'DOCKER-USER' );
+ set_optflags( $chainref, DONT_OPTIMIZE | DONT_DELETE | DONT_MOVE );
+ add_commands( $chainref, '[ -f ${VARDIR}/.filter_DOCKER-USER ] && cat ${VARDIR}/.filter_DOCKER-USER >&3' );
$chainref = new_standard_chain( 'DOCKER-ISOLATION' );
set_optflags( $chainref, DONT_OPTIMIZE | DONT_DELETE | DONT_MOVE );
add_commands( $chainref, '[ -f ${VARDIR}/.filter_DOCKER-ISOLATION ] && cat ${VARDIR}/.filter_DOCKER-ISOLATION >&3' );
@@ -8627,6 +8630,7 @@ sub save_docker_rules($) {
qq($tool -t nat -S POSTROUTING | tail -n +2 | fgrep -v SHOREWALL > \${VARDIR}/.nat_POSTROUTING),
qq($tool -t filter -S DOCKER | tail -n +2 > \${VARDIR}/.filter_DOCKER),
qq([ -n "\$g_dockeringress" ] && $tool -t filter -S DOCKER-INGRESS | tail -n +2 > \${VARDIR}/.filter_DOCKER-INGRESS),
+ qq([ -n "\$g_dockeruser" ]&& $tool -t filter -S DOCKER-USER | tail -n +2 > \${VARDIR}/.filter_DOCKER-USER),
qq(),
qq(case "\$g_dockernetwork" in),
qq(One\)),
@@ -8655,6 +8659,7 @@ sub save_docker_rules($) {
q(rm -f ${VARDIR}/.nat_POSTROUTING),
q(rm -f ${VARDIR}/.filter_DOCKER),
q(rm -f ${VARDIR}/.filter_DOCKER-INGRESS),
+ q(rm -f ${VARDIR}/.filter_DOCKER-USER),
q(rm -f ${VARDIR}/.filter_DOCKER-ISOLATION*),
q(rm -f ${VARDIR}/.filter_FORWARD),
q(fi)
@@ -9169,6 +9174,10 @@ sub create_netfilter_load( $ ) {
enter_cmd_mode;
emit( '[ -n "$g_dockeringress" ] && echo ":DOCKER-INGRESS - [0:0]" >&3' );
enter_cat_mode;
+ } elsif ( $name eq 'DOCKER-USER' ) {
+ enter_cmd_mode;
+ emit( '[ -n "$g_dockeruser" ] && echo ":DOCKER-USER - [0:0]" >&3' );
+ enter_cat_mode;
} else {
emit_unindented ":$name - [0:0]";
}
@@ -9282,6 +9291,11 @@ sub preview_netfilter_load() {
print( '[ -n "$g_dockeringress" ] && echo ":DOCKER-INGRESS - [0:0]" >&3' );
print "\n";
enter_cat_mode1;
+ } elsif ( $name eq 'DOCKER-USER' ) {
+ enter_cmd_mode1 unless $mode == CMD_MODE;
+ print( '[ -n "$g_dockeruser" ] && echo ":DOCKER-USER - [0:0]" >&3&
Re: [Shorewall-users] Docker 18.03.1-ce breaks 'Docker=Yes'
On 10/27/18 1:17 PM, Anthony Rogers wrote:
> Hi Tom,
>
> The prepatch attachment, is without any of the patches applied.
>
> The postpatch attachment is with both.
>
> Both ISOLATION chains are now present, but the DOCKER-USER chain is
> possibly not quite right?
>
>
The attached patch should fix that.
-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
\___
diff --git a/Shorewall/Perl/Shorewall/Misc.pm b/Shorewall/Perl/Shorewall/Misc.pm
index 43cbaa343..21722656f 100644
--- a/Shorewall/Perl/Shorewall/Misc.pm
+++ b/Shorewall/Perl/Shorewall/Misc.pm
@@ -668,7 +668,7 @@ sub create_docker_rules() {
my $chainref = $filter_table->{FORWARD};
add_commands( $chainref, '[ -n "$g_dockeringress" ] && echo "-A FORWARD -j DOCKER-INGRESS" >&3', );
-add_commands( $chainref, '[ -n "$g_dockeringress" ] && echo "-A FORWARD -j DOCKER-USER">&3', );
+add_commands( $chainref, '[ -n "$g_dockeruser" ]&& echo "-A FORWARD -j DOCKER-USER">&3', );
add_commands( $chainref ,
'',
'case "$g_dockernetwork" in',
signature.asc
Description: OpenPGP digital signature
___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] Docker 18.03.1-ce breaks 'Docker=Yes'
On 10/28/18 9:52 AM, Anthony Rogers wrote: > Hi Tom, > > It's looking good. See attached 'iptables -L' listings. > > The diff is below, after I did a 'shorewall restart'. It looks like all > the chains are in place correctly now. > > Many thanks, > > Tony. Thanks for your help in testing the change! Regards, -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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
[Shorewall-users] Shorewall 5.2.1.1
Shorewall 5.2.1.1 is now available for download. Problems Corrected: 1) The Perl module versions were not updated for the 5.2.1 release. That has been corrected. 2) The lib.common file previously confused Emacs such that editing the file in shell mode was awkward. Because lib.common is included in compiled scripts, this defect also made editing a compiled script awkward. The issue has been resolved, so that the file now renders properly in Emacs's shell mode. 3) Previously, if ip6tables-restore failed during Shorewall6 start, restart or reload, the resulting error message indicated that iptables-load had failed. That has been corrected. 4) Setting Docker=Yes did not work correctly with Docker version 18.03.1-ce. In that version, the DOCKER-ISOLATION chain was replaced by a pair of chains: DOCKER-ISOLATION-STAGE-1 and DOCKER-ISOLATION-STAGE-2. That has been corrected. As part of this change, Shorewall now correctly handles the DOCKER-USER chain as well as the two new isolation chains. 5) Previously, if there were multiple 'balance' providers and more than one of them were experiencing carrier loss, then the 'enable' and 'disable' operations could fail. That has been corrected (Jeremie Courreges-Anglas). Thank you for using Shorewall, -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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] About iptables using nf_tables backend on Debian
On 10/29/18 11:04 AM, Vincas Dargis wrote: > On 2018-10-24 23:34, Tom Eastep wrote: >> On 10/24/18 9:18 AM, Vincas Dargis wrote: >>> What does that mean with regards to Shorewall? Could there potentially >>> be incompatibilities on how Shorewall expects Linux firewall to behave? >> >> There could certainly be incompatibilities that effect Shorewall and/or >> Shorewall6. > > Any plans to handle this issue? Maybe worth documenting/noting that > Debian Buster users are encouraged to use `update-alternatives` system > for enabling "old" backend? > > Or this should be handled by package maintainers? My opinion is that we should address issues as they arise after this iptables change migrates to testing. nf_tables is the direction in which the Netfilter team are going, and if we immediately direct users to switch to the old backend, we only delay resolution of compatibility issues. Eventually, the old backend will go away, so we want all known issues with the new backend to be resolved by that time. I've copied the Debian Shorewall Maintainer for his input. -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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] Excluding DNAT flow from connection tracking
On 11/5/18 12:12 PM, Mark Jonsen wrote: > Hello, > > > i want to exclude an complete flow of an incoming Destination NAT from > conntrack. (Its an UDP Connection and the flow back to the client is > opened for testing since the destination machine can access the source > interface unrestricted). > Given that NAT *requires* connection tracking, what you are asking isn't going to work. The NOTRACK entries are ineffective, because you are specifying an interface in the DEST column. Since NOTRACK is applied before routing, Shorewall uses the main routing table to replace the interface with one or more subnetworks. Because the initial incoming UDP packet has not had its destination IP address rewritten yet, it isn't matching the NOTRACK rules. -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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] ICMP replies are inconsistent
On 11/5/18 6:08 AM, Vieri Di Paola wrote: > Hi, > > I'm attachng a shorewall dump while trying to ping a shorewall > firewall interface at 192.168.212.1 from a host within the "dmz" zone > with IP address 192.168.212.93. > > I get inconsistent ICMP replies. > A tcpdump on the shorewall firewall itself shows this: > > # tcpdump -n -i enp5s0 host 192.168.212.93 and icmp > dropped privs to tcpdump > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on enp5s0, link-type EN10MB (Ethernet), capture size 262144 bytes > 14:59:20.513984 IP 192.168.212.93 > 192.168.212.1: ICMP echo request, > id 1, seq 746, length 40 > 14:59:20.514156 IP 192.168.212.1 > 192.168.212.93: ICMP echo reply, id > 1, seq 746, length 40 > 14:59:21.517489 IP 192.168.212.93 > 192.168.212.1: ICMP echo request, > id 1, seq 747, length 40 > 14:59:21.517653 IP 192.168.212.1 > 192.168.212.93: ICMP echo reply, id > 1, seq 747, length 40 > 14:59:22.521495 IP 192.168.212.93 > 192.168.212.1: ICMP echo request, > id 1, seq 748, length 40 > 14:59:22.521681 IP 192.168.212.1 > 192.168.212.93: ICMP echo reply, id > 1, seq 748, length 40 > 14:59:23.525488 IP 192.168.212.93 > 192.168.212.1: ICMP echo request, > id 1, seq 749, length 40 > 14:59:23.525616 IP 192.168.212.1 > 192.168.212.93: ICMP echo reply, id > 1, seq 749, length 40 > 14:59:24.529495 IP 192.168.212.93 > 192.168.212.1: ICMP echo request, > id 1, seq 750, length 40 > 14:59:24.529665 IP 192.168.212.1 > 192.168.212.93: ICMP echo reply, id > 1, seq 750, length 40 > 14:59:25.533542 IP 192.168.212.93 > 192.168.212.1: ICMP echo request, > id 1, seq 751, length 40 > 14:59:25.533698 IP 192.168.212.1 > 192.168.212.93: ICMP echo reply, id > 1, seq 751, length 40 > 14:59:26.537567 IP 192.168.212.93 > 192.168.212.1: ICMP echo request, > id 1, seq 752, length 40 > 14:59:26.537724 IP 192.168.212.1 > 192.168.212.93: ICMP echo reply, id > 1, seq 752, length 40 > 14:59:27.541601 IP 192.168.212.93 > 192.168.212.1: ICMP echo request, > id 1, seq 753, length 40 > 14:59:27.541797 IP 192.168.212.1 > 192.168.212.93: ICMP echo reply, id > 1, seq 753, length 40 > 14:59:28.545663 IP 192.168.212.93 > 192.168.212.1: ICMP echo request, > id 1, seq 754, length 40 > 14:59:28.545819 IP 192.168.212.1 > 192.168.212.93: ICMP echo reply, id > 1, seq 754, length 40 > 14:59:29.549700 IP 192.168.212.93 > 192.168.212.1: ICMP echo request, > id 1, seq 755, length 40 > 14:59:38.626915 IP 192.168.212.93 > 192.168.212.1: ICMP echo request, > id 1, seq 756, length 40 > 14:59:43.512067 IP 192.168.212.93 > 192.168.212.1: ICMP echo request, > id 1, seq 757, length 40 > 14:59:48.512169 IP 192.168.212.93 > 192.168.212.1: ICMP echo request, > id 1, seq 758, length 40 > 14:59:53.512369 IP 192.168.212.93 > 192.168.212.1: ICMP echo request, > id 1, seq 759, length 40 > > Why is my shorewall system not always replying? > > Here's the shorewall dump: > > https://drive.google.com/open?id=1oLsOAUdehsxKcvKZ2Z-vCzJS9lVv_5RQ > I don't see anything in the dump. You might trying using the iptrace command to trace what is happening to the echo-request packets; if that doesn't show anything, then try looking at the echo-replies. -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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] Possible minor bug
On 11/6/18 4:29 AM, ObNox wrote:
> Hi,
>
> Shorewall : 5.2.1.1
>
> I've decided to modularize Shorewall's configuration to keep things
> readable as they get more complicated.
>
> While testing, I use another configuration directory base and use
> "compile" to compare final results against the original ones.
>
> Shell# shorewall -v2 compile /path/to/oher-config newresult.firewall
>
> Withing "params" file, I include files from a subdirectory and to make
> sure I'm in the right directory, I use the internal "${g_confdir}"
> variable.
>
> Unfortunately, "${g_confdir}" is always set to "/etc/shorewall", no
> matter what the "[directory]" argument of "compile" is set to which
> makes the compilation fail (as the included files could not be found).
>
> Shouldn't all options accepting a "[directory]" argument set the
> internal "${g_confdir}" variable to the specified directory?
>
No. Specifying a directory simply pushes that directory onto the front
of the CONFIG_PATH.
-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
___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] Possible minor bug
On 11/6/18 12:49 PM, ObNox wrote:
> On 06/11/2018 19:26, ObNox wrote:
>
>>>>> Shouldn't all options accepting a "[directory]" argument set the
>>>>> internal "${g_confdir}" variable to the specified directory?
>>>>>
>>>>
>>>> No. Specifying a directory simply pushes that directory onto the front
>>>> of the CONFIG_PATH.
>>
>>> If you don't plan to provide some kind of way (a new env var
>>> perhaps?) to know for sure Shorewall is using a custom directory for
>>> configuration, please tell me and I'll craft something on my own to
>>> circumvent this shortcoming.
>>
>> A bit of research seems to show that there's a $g_shorewalldir which
>> holds the needed information.
>>
>> But, I wonder why it's not available as a variable in "params" file.
Remember that the params file is processsed twice; once in the CLI
(where the g_shorewalldir variable lives) and once in the compiler
(actually in the $LIBEXECDIR/getparams program) where g_shorewalldir
does not exist.
>
> All right, I got it the way I wanted :-)
>
> file "/usr/share/shorewall/lib.cli" line 4603 at :
>
> "setup_product_environment 1"
>
> I've added, right above : "export g_shorewalldir" and that did the trick!
>
> Now "$g_shorewalldir" is available in "params" and I can now include
> everything I need relative to the processed directory! The variable is
> also available in "rules".
>
> As far as I tested within my environment, I don't seem to notice any
> negative impact so I'll keep using it.
>
In the next release, I'm adding support for $SW_CONFDIR which will hold
either /etc/shorewall[6] or the directory specified on the run-line.
-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
___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] shorewall VLANs and network ranges
On 11/8/18 4:56 AM, Vieri Di Paola wrote: > Hi, > > I'd like to describe my goal here to see if someone can guide me to > the "best solution". > > A Shorewall server has several ethernet interfaces, and one of them > (say, eth0) is configured with VLAN IDs 1, 11, 12 (eth0.1, eth0.11, > eth0.12). > > So eth0 is then connected to a "trunk" port on a managed switch > (untagged VLAN 1, tagged VLAN 11, tagged VLAN 12). > > The eth0 IP addr. configuration on the Shorewall system is something > like 192.168.210.1/24, and the hosts in this LAN segment are within > this IP addr. range with static IP addresses. > It is REQUIRED that all hosts in this network have IP addresses within > this range, and that the Shorewall server use the least IP addresses > as possible (ie. 1). > > As a simplified practical example, suppose I have the following: > > - 1 host in VLAN 11 with IP address 192.168.210.10/24, default gw > 192.168.210.1 > - 2 hosts in VLAN 1 with IP addresses 192.168.210.20-21/24, default gw > 192.168.210.1 > - 1 host in VLAN 12 with IP address 192.168.210.30/24, default gw > 192.168.210.1 > > I need Shorewall to manage traffic between these VLANs > (allow/drop/reject...). eg. I want only $FW to access VLAN 1 hosts, > VLAN 11 hosts can access specific ports on $FW only, VLAN 12 hosts can > access selected ports on VLAN 1 hosts. > > The usual way to configure VLANs is to use non-overlapping IP ranges > for each virtual interface. > However, I cannot do that here. > > I was thinking of using "parallel zones", but I'm not sure that would > work (I cannot specify eth0.1, eth0.11 or eth0.12 in the Shorewall > Interfaces file). Of course you can!!! > > I was also trying to configure a bridge, but I don't know if and how I > can bridge a VLAN with the interface, and then set Shorewall > BPORT-based rules. > Something like bridging eth0.1, eth0.11 and eth0.12, setting a > management IP address 192.168.210.1/24, and then defining bridge zones > and BPORT rules. > > Can anyone please give me some hints and pointers? > There is *nothing* unique about VLAN interfaces, as far as Shorewall is concerned. Treat them just as you would non-VLAN ethernet devices. -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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] tc problem on new GENTOO kernel
On 11/8/18 7:39 AM, Alexander Stoll wrote: > Hi Tom, > > posting to the list because until know I am not shure what is to blame... > > - working config with kernel 4.18.14 (gentoo-sources-4.18.14) > > - introduced with gentoo-sources-4.18.15 tc rules are not loading > anymore on startup, gentoo-sources-4.19.x also affected > > - set up a testenv on spare with simple config > > log output > > Setting up Traffic Control... > RTNETLINK answers: Numerical result out of range > ERROR: Command "tc qdisc add dev enp8s0 root handle 1: hfsc default > 12" Failed > > > seems tc is no longer working with these parameters... > > My first guess: regression in patchset (gentoo-sources), needs > verification and further digging. > > Is anyone aware of some known bug? > This is the first that I have heard of this issue... -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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] Strange error with Centos 7
On 11/13/18 3:00 AM, Paolo Prandini wrote: > I installed the minimal version of Centos 7, run a yum upgrade > and then yum install shorewall > When I test my configuration with shorewall check ( I only set zones > interfaces policy) , I always get > nf_log: can't load ipt_ULOG, conflicting nfnetlink_log already loaded > What can I do to avoid this problem? > Thanks a lot I haven't seen this problem, but I'm updating my Centos 7 VM and will try to reproduce... -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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] Strange error with Centos 7
On 11/13/18 3:00 AM, Paolo Prandini wrote: > I installed the minimal version of Centos 7, run a yum upgrade > and then yum install shorewall > When I test my configuration with shorewall check ( I only set zones > interfaces policy) , I always get > nf_log: can't load ipt_ULOG, conflicting nfnetlink_log already loaded > What can I do to avoid this problem? > Thanks a lot I've reproduced the problem. Are you trying to log via ULOG or is it just the journal message that concerns you? Thanks, -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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] shorewall VLANs and network ranges
> ff:ff:ff:ff:ff:ff, ethertype > 802.1Q (0x8100), length 192: vlan 1, p 0, ethertype IPv4, > 192.168.210.49.57553 > 255.255.255.255.10001: UDP, length 146 > 15:00:49.275777 00:24:54:d9:cb:e4 > 00:e3:c0:5f:81:5d, ethertype > 802.1Q (0x8100), length 78: vlan 1, p 0, ethertype IPv4, > 192.168.215.201 > 192.168.215.1: ICMP echo request, id 1, seq 11496, > length 40 > 15:00:49.275830 00:e3:c0:5f:81:5d > 00:24:54:d9:cb:e4, ethertype > 802.1Q (0x8100), length 78: vlan 1, p 0, ethertype IPv4, 192.168.215.1 >> 192.168.215.201: ICMP echo reply, id 1, seq 11496, length 40 > 15:00:50.278810 00:24:54:d9:cb:e4 > 00:e3:c0:5f:81:5d, ethertype > 802.1Q (0x8100), length 78: vlan 1, p 0, ethertype IPv4, > 192.168.215.201 > 192.168.215.1: ICMP echo request, id 1, seq 11497, > length 40 > 15:00:50.278883 00:e3:c0:5f:81:5d > 00:24:54:d9:cb:e4, ethertype > 802.1Q (0x8100), length 78: vlan 1, p 0, ethertype IPv4, 192.168.215.1 >> 192.168.215.201: ICMP echo reply, id 1, seq 11497, length 40 > 15:00:51.282792 00:24:54:d9:cb:e4 > 00:e3:c0:5f:81:5d, ethertype > 802.1Q (0x8100), length 78: vlan 1, p 0, ethertype IPv4, > 192.168.215.201 > 192.168.215.1: ICMP echo request, id 1, seq 11498, > length 40 > 15:00:51.282856 00:e3:c0:5f:81:5d > 00:24:54:d9:cb:e4, ethertype > 802.1Q (0x8100), length 78: vlan 1, p 0, ethertype IPv4, 192.168.215.1 >> 192.168.215.201: ICMP echo reply, id 1, seq 11498, length 40 > ^C > > Why isn't the ICMP request dropped? > Because you have given interface enp8s5 an IP address and have assigned it to the dmz zone, and your rules allow ping from dmz -> fw. The bridge configuration never comes into play. In a valid bridge configuration, the bridge port interfaces have no IP configuration and are only defined to Shorewall as bport interfaces. -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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] shorewall VLANs and network ranges
On 11/14/18 12:29 AM, Vieri Di Paola wrote: > On Wed, Nov 14, 2018 at 12:53 AM Tom Eastep wrote: >> Because you have given interface enp8s5 an IP address and have assigned >> it to the dmz zone, and your rules allow ping from dmz -> fw. The bridge >> configuration never comes into play. In a valid bridge configuration, >> the bridge port interfaces have no IP configuration and are only defined >> to Shorewall as bport interfaces. > You lost me there. > > As far as I can tell, I haven't set any IP address to enp8s5 or > assigned it to the dmz zone. > Here's what I have in my interfaces file: > > dmz enp5s0 routeback,dhcp,proxyarp=1 > dmzxbr0 bridge,dhcp,proxyarp=1 > dmz0br0:enp8s5 routeback > dmz1br0:enp8s5_1routeback > dmz11 br0:enp8s5_11 routeback > > Also, this is my network configuration which is the same as the one > reported in the SW dump: > > # ip addr show enp8s5 > 8: enp8s5: mtu 1500 qdisc fq_codel > master br0 state UP group default qlen 1000 > link/ether 00:e3:c0:5f:81:5d brd ff:ff:ff:ff:ff:ff > inet6 fe80::2e3:c0ff:fe5f:815d/64 scope link >valid_lft forever preferred_lft forever > # ip addr show enp8s5_1 > 60: enp8s5_1@enp8s5: mtu 1500 qdisc > noqueue master br0 state UP group default qlen 1000 > link/ether 00:e3:c0:5f:81:5d brd ff:ff:ff:ff:ff:ff > inet6 fe80::2e3:c0ff:fe5f:815d/64 scope link >valid_lft forever preferred_lft forever > # ip addr show enp8s5_11 > 61: enp8s5_11@enp8s5: mtu 1500 qdisc > noqueue master br0 state UP group default qlen 1000 > link/ether 00:e3:c0:5f:81:5d brd ff:ff:ff:ff:ff:ff > inet6 fe80::2e3:c0ff:fe5f:815d/64 scope link >valid_lft forever preferred_lft forever > # ip addr show br0 > 62: br0: mtu 1500 qdisc > noqueue state UP group default qlen 1000 > link/ether 00:e3:c0:5f:81:5d brd ff:ff:ff:ff:ff:ff > inet 192.168.215.1/24 brd 192.168.215.255 scope global br0 >valid_lft forever preferred_lft forever > inet6 fe80::2e3:c0ff:fe5f:815d/64 scope link >valid_lft forever preferred_lft forever > # ip addr show enp5s0 > 2: enp5s0: mtu 1500 qdisc pfifo_fast > state UP group default qlen 1000 > link/ether 68:05:ca:11:64:30 brd ff:ff:ff:ff:ff:ff > inet 192.168.210.1/23 brd 192.168.211.255 scope global enp5s0 >valid_lft forever preferred_lft forever > inet 192.168.212.1/24 brd 192.168.212.255 scope global enp5s0 >valid_lft forever preferred_lft forever > inet6 fe80::6a05:caff:fe11:6430/64 scope link >valid_lft forever preferred_lft forever > > As you can see from the above, enp8s5 does not have an IP address > configured. Only br0 has a management IP address which I need anyway. > Also, br0 only covers enp8s5, enp8s5_1 and enp8s5_11, not enp5s0. > > The traffic's source address reported in this dump is not in the dmz > zone but in dmz1, ie. the traffic flow is through the br0 bridge. > > Have I overlooked something? > No -- I was apparently confusing enp8s5 with enp5s0 (I hate this new NIC naming convention). It appears that *no* traffic entered via enp5s0 during the period of time covered by the dump: Chain br0_fwd (1 references) pkts bytes target prot opt in out source destination 0 0 dmz0_frwd all -- * * 0.0.0.0/00.0.0.0/0 PHYSDEV match --physdev-in enp8s5 policy match dir in pol none < 25 4464 dmz1_frwd all -- * * 0.0.0.0/00.0.0.0/0 PHYSDEV match --physdev-in enp8s5_1 policy match dir in pol none 0 0 dmz11_frwd all -- * * 0.0.0.0/00.0.0.0/0 PHYSDEV match --physdev-in enp8s5_11 policy match dir in pol none 0 0 dmzx_frwd all -- * * 0.0.0.0/00.0.0.0/0 policy match dir in pol none Chain br0_in (1 references) pkts bytes target prot opt in out source destination 0 0 dmz0-fwall -- * * 0.0.0.0/00.0.0.0/0 PHYSDEV match --physdev-in enp8s5 policy match dir in pol none <=== 49 4424 dmz1-fwall -- * * 0.0.0.0/00.0.0.0/0 PHYSDEV match --physdev-in enp8s5_1 policy match dir in pol none 0 0 dmz11-fw all -- * * 0.0.0.0/00.0.0.0/0 PHYSDEV match --physdev-in enp8s5_11 policy match dir in pol none 0 0 dmzx-fwall -- * * 0.0.0.0/00.0.0.0/0 policy match dir in pol none Or, at least, none made it as far as the filter table. So I suggest analyzing the packet flow with 'shorewall iptrace -s 192.168.215.201
Re: [Shorewall-users] Strange error with Centos 7
On 11/14/18 6:32 AM, Scott Beane wrote: > Same Ulogd error here following shorewall's logging set up man page(s) > <http://shorewall.org/shorewall_logging.html> to move iptables output > into its own log file, in my case, shorewall.log. > > Sometimes, ulogd does not log to file. Seems dependent upon when Ulogd > is started by systemd. I am now starting it after shorewall. Note that > it works without ipt_ULOG being loaded nonetheless (see #3 below). ipt_ULOG is only required to use the 'ULOG' log level. > > Ulogd appear to be needed, but I remain confused as to whether ulogd is > doing anything or whether rsyslogd configure edits (see #5 below) are > handling the correct logging or whether it takes both rsyslogd and ulogd. NFLOG logging will be handled by ulogd - syslog logging (info, debug, etc) will be handled by rsyslogd. -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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] shorewall issue since switching to new internet connection
On 11/13/18 3:09 AM, Boris wrote: > Am 25.09.18 um 10:21 schrieb Boris: >> Am 25.09.2018 um 00:50 schrieb Tom Eastep: >>> On 09/24/2018 01:55 PM, Boris wrote: >>>> Am 24.09.2018 um 19:12 schrieb Tom Eastep: >>>>> On 09/05/2018 08:16 AM, Boris wrote: >>>>>> Hej SW-list, >>>>>> >>>>>> This is the first time that I'm writing directly to the SW list. First >>>>>> of all, I want to thank you for this great software! I can hardly >>>>>> believe that I have been using SW for more than 15 years - embedded in >>>>>> the also great environment of LEAF (Linux Embedded Appliance Framework >>>>>> (formerly Firewall)). >>>>>> >>>>>> And now, for the first time, I have a problem that I don't understand >>>>>> and hope for help: >>>>>> My LEAF box (Ver. 6.x with SW 5.1.7.2 on Alix hardware) worked great on >>>>>> a VDSL internet line with 25 Mbps / 5Mbps. I used a FritzBox 7490 as >>>>>> modem (PassThrough). I have a web server and a mail server in a DMZ >>>>>> segment, a few desktop PCs in the LAN segment and a few wireless devices >>>>>> in a WLAN segment. The box also serves as an OpenVPN server. Nothing >>>>>> really extraordinary, I think. >>>>>> >>>>>> A few hours ago I got a new internet line switched with higher >>>>>> bandwidth. Unfortunately, I don't (yet) have any detailed technical >>>>>> specifications for the line other than the bandwidth (100Mbps / 40Mbps). >>>>>> A new FritzBox 7590 serves as modem. During a conversation with the >>>>>> support of the provider the keyword 'VLAN 7' was mentioned. This seems >>>>>> to indicate a BNG connection from Telekom, but I didn't have to set up >>>>>> VLAN tagging. >>>>>> >>>>>> Now to the problem description: With the unchanged SW configuration, >>>>>> REJECTS of TCP packets from and to the zone 'net' occur, which were >>>>>> transported correctly before the switchover! It looks like some packets >>>>>> are passing through sporadically, but I can't secure that and I can't >>>>>> even reproduce it. All other zones work fine with each other, so >>>>>> loc-wlan, wlan-dmz, dmz-loc and so on. In addition, icmp packets are >>>>>> transported over the zone net without any problems. >>>>>> In order to be able to use my environment, I removed all restrictions as >>>>>> a temporary solution, with a global statement in /shorewall/policy: >>>>>> all all ACCEPT >>>>>> This is of course undesirable and I am looking for the cause of the >>>>>> problem. I asked the provider for detailed specifications of the line. >>>>>> Maybe someone has an idea here? I deactivated the global ACCEPT again >>>>>> and made a dump, which is attached. >>>>>> >>>>>> Many thanks and many greetings, >>>>>> >>>>>> >>>>> >>>>> Your internet interface is now eth0, not ppp0. So you need to change >>>>> your configuration. >>>>> >>>>> -Tom >>>>> >>>> >>>> Hej Tom, >>>> >>>> thank you very much for your statement! >>>> >>>> I'm sure you have one or more very good reason to come to this >>>> conclusion. Could you please give a little explanation? >>>> >>>> Finally, I'm afraid you missunderstood my description of the situation. >>>> >>>> ppp is still doing the login and ppp0 is the interface that 'owns' the >>>> public IP: >>>> >>>> # ip addr sh: >>>> >>>> [snip] >>>> 3: eth0: mtu 1500 qdisc pfifo_fast >>>> state UNKNOWN group default qlen 1000 >>>> link/ether 00:0d:b9:13:fb:d8 brd ff:ff:ff:ff:ff:ff >>>> [snip] >>>> 13: ppp0: mtu 1492 qdisc >>>> pfifo_fast state UNKNOWN group default qlen 3 >>>> link/ppp >>>> inet 217.70.192.188 peer 213.178.81.101/32 scope global ppp0 >>>>valid_lft forever preferred_lft forever >>>> >>>> Of course I tried to follow your hint and changed ppp0 into eth0 in >>>&g
Re: [Shorewall-users] Strange error with Centos 7
On 11/13/18 3:39 PM, Tom Eastep wrote: > On 11/13/18 3:00 AM, Paolo Prandini wrote: >> I installed the minimal version of Centos 7, run a yum upgrade >> and then yum install shorewall >> When I test my configuration with shorewall check ( I only set zones >> interfaces policy) , I always get >> nf_log: can't load ipt_ULOG, conflicting nfnetlink_log already loaded >> What can I do to avoid this problem? >> Thanks a lot > > > I've reproduced the problem. Are you trying to log via ULOG or is it > just the journal message that concerns you? > Paolo replied privately that he is only concerned about the journal message. That message can be eliminated as follows: a) Copy /usr/share/shorewall/helpers /etc/shorewall/. b) Edit /etc/shorewall/helpers and remove this line: loadmodule ipt_ULOG -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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] shorewall VLANs and network ranges
On 11/15/18 9:47 AM, Simon Matter wrote: >> OK, I'm seeing a very odd behavior here, but at least I can now easily >> reproduce the issue. >> >> I have a test host with IP address 192.168.215.200 pinging continously >> the Shorewall FW at 192.168.215.1. >> At first, I connect it to Switch Port with VLAN ID 11 Untagged (enp8s5 >> on the FW is connected to Switch Port VLAN 11 tagged + 12 tagged + 1 >> tagged). It gets the ICMP replies just fine, as expected according to >> my Shorewall rules. >> >> I've captured dumps and traces while this was happening (I can see >> traffic on VLAN 11, nothing on VLAN 12 which is OK): >> >> SW DUMP: >> https://drive.google.com/open?id=1_wLPvrowWGE4CPFYMQSzqxz0_FvZXm4q >> SW TRACE: >> https://drive.google.com/open?id=1AXzSDhBTN62veUPYjzVxgddPEBdY1Amy >> >> I then disconnected the test host's ethernet cable from the Switch and >> plugged it into another port on the same Switch but with VLAN ID 12 >> Untagged. >> The test host keeps pinging FW at 192.168.215.1 successfully when it >> SHOULDN'T because of my Shorewall rules and policies. >> A tcpdump on the enp8s5_12 interface shows VLAN 12 traffic and ICMP >> requests/replies. >> A tcpdump on the enp8s5_11 interface shows that there's no more VLAN 11 >> traffic. >> >> I grabbed a SW dump, SW trace and a tcpdump: >> >> TCPDUMP on enp8s5_12: >> https://drive.google.com/open?id=1JVSOMNsXmPA1gKaVhYguZr0VmKzwSOER >> TCPDUMP on enp8s5: >> https://drive.google.com/open?id=1pxyuMP6lynquB_BEks56HzjPqeWg-J6U >> SW DUMP: >> https://drive.google.com/open?id=1donyBraZpwKSyNG4w75LGkfPvlwgf3B9 >> SW TRACE: >> https://drive.google.com/open?id=1eFYjF9HPi144uzl2Y_oDZxtMCDq4fSog >> >> The test host is a Windows 10 laptop. Disconnecting its ethernet cable >> and putting it back in did not change anything. However, I noticed >> that if I put the laptop in sleep mode and woke it up again after AT >> LEAST 30 seconds, traffic behavior would finally be "as expected", ie. >> the test host would fail pinging the FW. > > I can't follow you here with all the details and dumps... > > It just sounds to me like it has something to do with ARP caches, on a > switch, on a host, on a router? > > Or even more fun, host routes generated through ICMP redirect messages? > That's what I believe also. Vieri - Do I understand correctly that after you physically reconfigure, things settle down after some period of time and work properly (and stay working properly)? If so, I don't believe that there is anything here to worry about. -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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] shorewall VLANs and network ranges
On 11/16/18 4:34 AM, Vieri Di Paola wrote: > On Thu, Nov 15, 2018 at 8:48 PM Tom Eastep wrote: >> That's what I believe also. >> >> Vieri - Do I understand correctly that after you physically reconfigure, >> things settle down after some period of time and work properly (and stay >> working properly)? If so, I don't believe that there is anything here to >> worry about. > Simon and Tom, thank you for looking into this. > > I've noticed that it doesn't really matter if I put the Windows 10 > host to sleep for 30 seconds. It happens with any host (Linux, etc.), > and the easy way to "make things work" is to simply disconnect the > host cable from the switch (port with VLAN ID 11 Untagged, in my > case), wait *at least* 30 seconds, and finally connect the cable to > another switch port (VLAN ID 12 Untagged, in my case). If I honor this > time lag, everything behaves "as expected". In my previous tests, I > would move the cable from one port to another on the switch in way > less than 30 seconds. > > I haven't found any ARP timeout setting on this particular switch, > even though I've seen this option somewhere on another brand or model. > > Anyway, yes, once the physical connections are settled, everything > seems to work fine. However, I have to keep in mind that any change in > the wiring requires to keep the switch port down for at least 30 > seconds. > > I'm really curious though, so I took another look at the logs. > The shorewall iptrace below was taken from my previous post at > https://drive.google.com/open?id=1eFYjF9HPi144uzl2Y_oDZxtMCDq4fSog > .That's when things were "not working right". According to the trace, > the packets are actually entering chain dmz12-fw. They should be > dropped, but they are apparently not according to what I see on the > client host itself. > > Nov 15 09:36:40 inf-fw2 kernel: TRACE: raw:PREROUTING:policy:13 IN=br0 > OUT= PHYSIN=enp8s5_12 MAC=00:e3:c0:5f:81:5d:f4:39:09:d9:14:c8:08:00 > SRC=192.168.215.200 DST=192.168.215.1 LEN=60 TOS=0x00 PREC=0x00 > TTL=128 ID=9994 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=16395 > Nov 15 09:36:40 inf-fw2 kernel: TRACE: mangle:PREROUTING:rule:1 IN=br0 > OUT= PHYSIN=enp8s5_12 MAC=00:e3:c0:5f:81:5d:f4:39:09:d9:14:c8:08:00 > SRC=192.168.215.200 DST=192.168.215.1 LEN=60 TOS=0x00 PREC=0x00 > TTL=128 ID=9994 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=16395 > Nov 15 09:36:40 inf-fw2 kernel: TRACE: mangle:PREROUTING:policy:9 > IN=br0 OUT= PHYSIN=enp8s5_12 > MAC=00:e3:c0:5f:81:5d:f4:39:09:d9:14:c8:08:00 SRC=192.168.215.200 > DST=192.168.215.1 LEN=60 TOS=0x00 PREC=0x00 TTL=128 ID=9994 PROTO=ICMP > TYPE=8 CODE=0 ID=1 SEQ=16395 > Nov 15 09:36:40 inf-fw2 kernel: TRACE: mangle:INPUT:policy:1 IN=br0 > OUT= PHYSIN=enp8s5_12 MAC=00:e3:c0:5f:81:5d:f4:39:09:d9:14:c8:08:00 > SRC=192.168.215.200 DST=192.168.215.1 LEN=60 TOS=0x00 PREC=0x00 > TTL=128 ID=9994 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=16395 > Nov 15 09:36:40 inf-fw2 kernel: TRACE: filter:INPUT:rule:6 IN=br0 OUT= > PHYSIN=enp8s5_12 MAC=00:e3:c0:5f:81:5d:f4:39:09:d9:14:c8:08:00 > SRC=192.168.215.200 DST=192.168.215.1 LEN=60 TOS=0x00 PREC=0x00 > TTL=128 ID=9994 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=16395 > Nov 15 09:36:40 inf-fw2 kernel: TRACE: filter:br0_in:rule:4 IN=br0 > OUT= PHYSIN=enp8s5_12 MAC=00:e3:c0:5f:81:5d:f4:39:09:d9:14:c8:08:00 > SRC=192.168.215.200 DST=192.168.215.1 LEN=60 TOS=0x00 PREC=0x00 > TTL=128 ID=9994 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=16395 > Nov 15 09:36:40 inf-fw2 kernel: TRACE: filter:dmz12-fw:rule:4 IN=br0 > OUT= PHYSIN=enp8s5_12 MAC=00:e3:c0:5f:81:5d:f4:39:09:d9:14:c8:08:00 > SRC=192.168.215.200 DST=192.168.215.1 LEN=60 TOS=0x00 PREC=0x00 > TTL=128 ID=9994 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=16395 > > So I then searched the shorewall log and found this: > > Nov 15 09:36:40 inf-fw2 kernel: Shorewall:dmz12-fw:DROP:IN=br0 OUT= > PHYSIN=enp8s5_12 MAC=00:e3:c0:5f:81:5d:f4:39:09:d9:14:c8:08:00 > SRC=192.168.215.200 DST=192.168.215.1 LEN=62 TOS=0x00 PREC=0x00 > TTL=128 ID=9995 PROTO=UDP SPT=50892 DPT=53 LEN=42 > > There's nothing regarding ICMP. > I would have expected something like: > > Nov 16 09:36:40 inf-fw2 kernel: Shorewall:dmz12-fw:DROP:IN=br0 OUT= > PHYSIN=enp8s5_12 MAC=00:e3:c0:5f:81:5d:f4:39:09:d9:14:c8:08:00 > SRC=192.168.215.200 DST=192.168.215.1 LEN=60 TOS=0x00 PREC=0x00 > TTL=128 ID=19982 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=22595 > (this line was taken today from a "working environment") > > Basically, what puzzles me most is that the "iptrace" shows that the > dmz12-fw filter is being applied to the ICMP message, but nothing is > logged regarding ICMP in syslog. > I'm wondering if this behavior is ICMP-specific. I haven't tri
Re: [Shorewall-users] NFQUEUE and bport zones
On 11/19/18 1:23 AM, Vieri Di Paola wrote: > Hi, > > I know I can't specify a bport zone as DST in an ACCEPT/DROP/etc. > rule. Besides, a "shorewall check" reports an error. > > However, can a bport zone be used as a DST in an NFQUEUE action? A > "shorewall check" does not report an error for that. > A bport zone may only appear in the DEST column when the SOURCE specifies the related bridge's zone or another bport zone on that same bridge. -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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] shorewall issue since switching to new internet connection
On 11/16/18 1:31 PM, Boris wrote: > Am 14.11.18 um 19:01 schrieb Tom Eastep: >> >> You can assign a zone (call it 'hack') to eth0 then add these policies: >> >> hack all ACCEPT >> all hackREJECT >> > > Hej Tom, > > thank you VERY much for this! > I will try this the next days and give report. > I have thought a bit more about this, and I think that a better idea is to just add an entry in /etc/shorewall/interfaces that associates eth0 with the same zone as the ppp interface (probably 'net' or 'wan'). You don't have to worry about output traffic on eth0 because it has no IP address; hence, there can be no routes out of the interface and no IP traffic will be sent there. -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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] How to migrate from AUTOHELPERS to manual helper assignment? (VOIP/SIP)
On 11/24/18 3:36 AM, Timo Sigurdsson wrote:
> Hi,
>
> I recently moved from AUTOHELPERS=Yes to AUTOHELPERS=No in my shorewall
> configuration and while I've got it working, I still don't fully
> understand how the manual helper assignment is supposed to be done
> correctly or why I needed to make one change in particular.
>
> So, with AUTOHELPERS=Yes, the following rules in shorewall6/rules were
> sufficient and to get VOIP working:
> ACCEPT voipnet udp 3478,5060
> ACCEPT net voipudp 5060
>
> (Note: This is shorewall6, so NAT is not involved here.)
>
> After setting AUTOHELPERS=No, I added a HELPER line for sip. But that
> didn't seem to be sufficient. Signaling worked, but the audio stream
> was blocked when using one of my two SIP providers. Only after adding
> another accept rule for outgoing traffic, I could get VOIP calls with
> both providers working again. Now my rules look like this:
> HELPER voip- udp 5060{
> helper=sip }
> ACCEPT voipnet udp 3478,5060
> ACCEPT voipnet udp - 7078-7097
> ACCEPT net voipudp 5060
>
> The UDP port range 7078-7079 is what my SIP device's documentation
> recommends opening in firewall. But I don't understand why this rule
> was not necessary when AUTOHELPERS=Yes was used, but seems to be
> necessary when I try to assign the HELPER manually.
>
> Can someone explain this change in behavior? Or how do I attach the
> HELPER manually to replicate the behavior of AUTOHELPERS?
>
> For the record: I've also tried use both ports 3478 and 5060 in the
> HELPER rule, but that didn't make a difference. The other helper-
> related settings in my shorewall configuration (both shorewall and
> shorewall6) are HELPERS=sip and LOAD_HELPERS_ONLY=Yes.
>
> And one more question regarding the documentation:
> The man page shorewall-rules says:
> "No destination zone should be specified in HELPER rules."
>
> But the page http://shorewall.org/Helpers.html shows an example
> rule at the end that has the DEST zone set:
> HELPER all net tcp 21 ; helper=ftp
>
> Is that a mistake or can the DEST zone be specified in HELPER rules?
> In general, I'd like my rules to be as specific as possible, so,
> naturally, I'd have specified net as the DEST zone of my sip HELPER
> rule, but I didn't because of the statement in the man page.
>
What I recommend after setting AUTOHELPERS=No, is to simply add this to
your /etc/shorewall/conntrack file:
CT:helper:sip:PO- - udp 5060
That is all that AUTOHELPERS=Yes does for SIP.
-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
___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] VPN zones and policies
On 11/24/18 7:59 AM, Alex wrote: > Hi, > I have a shorewall-5.2.0.4 system on fedora28 connecting to a similar > shorewall system as a net-to-net VPN and having some difficulties with > rules for the VPNs involved with the firewall. > > The local side is 68.194.193.42 (orion) with private subnet > 192.168.1.0/24 behind it and the remote side is 65.45.72.6 (cyclops) > with 64.1.15.0/27 (DMZ) behind it. > > The problem I'm having is that hosts in the DMZ can't reach hosts on > the private subnet 192.168.1.0/24. Should the local private network be > listed in hosts among the VPN networks? > > I have all these networks listed in the hosts file as part of the VPN on > orion: > vpn br0:192.168.1.0/24,65.45.72.6,64.1.15.0/27 ipsec > > How do I indicate to the firewall that the 64.1.15.0/27 network is the > DMZ on the remote firewall and should be access through the VPN by the > local private network 192.168.1.0/24? > > I've included below my current configuration, but I don't believe the > "ext" network is defined properly. > > interfaces: > ext br0 detect > tcpflags,nosmurfs,routefilter,logmartians > int eth1detect > tcpflags,nosmurfs,routefilter,logmartians,routeback > > zones: > vpn ipsec mode=tunnel mss=1400 > ext ipv4 > int ipv4 > > Should I create a "dmz" zone to contain the 64.1.15.0/27 remote network? > > policy: > int int ACCEPT > int ext ACCEPT > $FW int ACCEPT > int vpn ACCEPT > int $FW ACCEPT > vpn int ACCEPT info > $FW vpn ACCEPT > vpn $FW ACCEPT > $FW ext ACCEPT > all all REJECT $LOG > I can't begin to help you without knowing what your IPSEC config looks like. The output of 'shorewall dump' would be very helpful. -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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] VPN zones and policies
On 11/24/18 3:00 PM, Alex wrote: >>> The problem I'm having is that hosts in the DMZ can't reach hosts on >>> the private subnet 192.168.1.0/24. Should the local private network be >>> listed in hosts among the VPN networks? > >> I can't begin to help you without knowing what your IPSEC config looks >> like. The output of 'shorewall dump' would be very helpful. > > Thanks so much. I didn't want to ask you to go through all the other > stuff as well, so I really appreciate it. > > I've pasted it here: > https://pastebin.com/1WV223TN > > You'll also notice there's a bit more of the network that I didn't > previously explain. Here's a list of all networks involved: > > 65.45.72.6 & 64.1.15.1: external and internal interface on cyclops > (remote firewall) > 68.194.193.42 & 192.168.1.1: external and internal interfaces on orion > (local firewall) > 107.155.66.2: remote Linux system > 66.103.218.96/28: DMZ connected to cyclops > 64.1.15.0/27: DMZ connected to cyclops > > 192.168.6.0/24: road warrior network connected to 68.195.193.42 > 192.168.1.0/24: internal LAN > > Alex, I don't see anything wrong with either the IPSEC or Shorewall configurations on Orion. -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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] Unexpected behaviour with shorewall check
On 11/26/18 7:55 AM, Lee Brown wrote: > Version 4.6.1.2 / CentOS 6.10 > > I have a rule: > DROP isp:+bogons all > > I made a minor change to the ip list, then performed: > shorewall check > > This loaded the new ip list into the shorewall configuration. > > I would not expect a check command to effect the active configuration. > Updates to ipsets take effect when the 'ipset add' command is executed. The 'check' command had no additional effect on the active 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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
[Shorewall-users] Shorewall 5.2.1.2
Shorewall 5.2.1.2 is now available for download. Problems Corrected: 1) The fix for DOCKER=Yes in 5.2.1.1 inadvertantly results in an assertion failure when processing a 'check -r' command when DOCKER=Yes. That has been corrected. As part of that change, empty 'cat' commands in the generated script were eliminated. 2) When the HELPER target is used with an empty HELPER column, the error message produced previously incorrectly read: ERROR: HELPER require requires that ... That has been corrected so that the message now reads: ERROR: HELPER requires that ... 3) On Centos 7, the following journal message appeared when Shorewall attempted to load kernel modules: nf_log: can't load ipt_ULOG, conflicting nfnetlink_log already loaded To eliminate that message, Shorewall no longer attempts to load ipt_ULOG. Note that most current distributions no longer support ULOG. Current users of ULOG should convert to using NFLOG at the earliest opportunity. New Feature: 1) A new variable SW_CONFDIR has been added. $SW_CONFDIR evaluates to $CONFDIR/shorewall[6] if no directory name is passed to a compile, check, start, restart or reload command. If a directory name is passed to one of these commands, then $SW_CONFDIR expands to that directory name. Thank you for using Shorewall. -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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] Missing interfaces on status report (shorewall status -i).
On 12/11/18 7:21 AM, Jesús Román wrote:
> Hello.
>
> I am a Shorewall user and, as my knowledge of this code is tiny and I do
> not know if this behavior might interfere with the function of the
> firewall, I would like to report a strange behavior.
>
> I am using shorewall in a device running Linux 4.9 which has 3 interfaces.
>
> eth0 -> Interface attached to the LAN.
> eth11 -> Port used by portable equipment to do maintenance
> operations in the device.
> wlan0 -> Wireless interface.
>
> The shorewall used is the release 5.1.1
>
> I have observed that after the execution of a "shorewall restart"
> command, the status of interfaces (shorewall -v status -i) does not
> appear on the console. Only the status of the Disabled interfaces is
> shown, in my case, eth11.
>
> Besides, the files:
>
> /var/lib/shorewall/.status
> /var/lib/shorewall/undo__routing
>
> have disappeared from the directory, except "eth11.status".
>
> Using the couple of commands "ifdown ", "ifup ", the
> correspondent interface appears on the report of status but, when the
> firewall is stopped and started again (or restarted), they disappear
> from the report.
>
> Checking the setup of another different device I am using, I have
> observed that it is working well, showing the status of all of its
> interfaces defined in the firewall. The difference resides in this one
> has 3 providers defined.
>
> Inspecting the code built by the compiler, I have seen that the behavior
> is different when at least one interface is working as provider or not.
>
> Providers setup: The function "setup_routing_and_traffic_shaping" has 1
> line performing an "undo_routing" BEFORE starting providers and interfaces.
>
> No providers setup: The function "setup_routing_and_traffic_shaping" has
> 2 lines performing an "undo_routing" and "restore_default_route" AFTER
> starting interfaces.
>
> Should those lines be placed BEFORE starting interfaces when there are
> no providers defined?
>
> Reviewing the code of Shorewall 4.4.0, this function is different but,
> these 2 lines are placed in a different position near the beginning of
> "setup_routing_and_traffic_shaping".
>
> As workaround, I have defined the wireless interface as provider but, as
> I do not need Load Balancing neither Backup paths, I would prefer not to
> do it.
>
> Could you check if I am right?
Yes, you are correct.
Attached is a patch to 5.1.1:
. /usr/share/shorewall/shorewallrc
patch $PERLLIBDIR/Shorewall/Providers.pm < OPT_INTERFACES-5.1.1.patch
A similar patch will be included in Shorewall 5.2.1.3.
-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
\___
--- Providers.pm.orig 2018-12-11 09:09:58.490278322 -0800
+++ Providers.pm 2018-12-11 09:10:14.297222598 -0800
@@ -1861,14 +1861,14 @@
push_indent;
+ emit "\nundo_routing";
+ emit "restore_default_route $config{USE_DEFAULT_RT}";
+
if ( $pseudoproviders ) {
emit '';
emit "start_$providers{$_}->{what}_$_" for @providers;
}
- emit "\nundo_routing";
- emit "restore_default_route $config{USE_DEFAULT_RT}";
-
my $standard_routes = @{$providers{main}{routes}} || @{$providers{default}{routes}};
if ( $config{NULL_ROUTE_RFC1918} ) {
signature.asc
Description: OpenPGP digital signature
___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] hosts file and vpn hosts
On 12/11/18 3:10 PM, Alex wrote: > Hi, > I have a shorewall-5.2.0.4 system on fedora28 and have set it up with > a few VPN connections. The problem I'm having is with how to instruct > shorewall that there is a range of IPs behind the remote VPN endpoint > (also a shorewall system) that should be considered as part of the > VPN. > > For now I've added the IPs in the DMZ of the remote firewall to the > vpn line in the hosts file, but I can't imagine that's correct, given > it specifies the interface. > > Here's a list of all networks involved: > > 65.45.72.6 & 64.1.15.1: external and internal interface on cyclops > (remote firewall) > 68.194.193.42 & 192.168.1.1: external and internal interfaces on orion > (local firewall) > 107.155.66.2: remote Linux system > 66.103.218.96/28: DMZ connected to cyclops > 64.1.15.0/27: DMZ connected to cyclops > > 192.168.6.0/24: road warrior network connected to 68.195.193.42 > 192.168.1.0/24: internal LAN > > Here is an example. The 64.1.15.3 IP is in the DMZ behind the remote > firewall. This is a mail server trying to communicate with the mail > server on the local shorewall firewall. > > [11440.214121] ext-fw REJECT IN=br0 OUT= > MAC=0c:c4:7a:a9:18:de:a4:15:88:a9:30:b7:08:00 SRC=64.1.15.3 > DST=68.194.193.42 LEN=60 TOS=0x00 PREC=0x00 TTL=50 ID=10192 DF > PROTO=TCP SPT=52208 DPT=25 WINDOW=29200 RES=0x00 SYN URGP=0 > > Here is my local hosts file. > vpn > br0:192.168.6.0/24,192.168.1.0/24,65.45.72.6,64.1.15.0/27,68.194.193.42,66.103.218.96/28,107.155.66.2 > ipsec > > Here is the output from 'shorewall dump' > https://pastebin.com/e8gvjmFr > The dump shows that there is no IPSec policy that covers 64.1.15.3 -> 68.194.193.42. So this traffic is being treated as coming from the vpn zone. This is an IPSEC configuration issue, not a Shorewall configuration issue. -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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
[Shorewall-users] Shorewall 5.2.1.3
Shorewall 5.2.1.3 is now available for download. Problem Corrected: 1) When a configuration had optional interfaces but no providers, the 'status -i' command previously would fail to show interface status for interfaces that had not been disabled or enabled since the last start, restart or reload. That has been corrected. Thank you for using Shorewall, -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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] hosts file and vpn hosts
On 12/11/18 5:22 PM, Alex wrote: > Hi, > > On Tue, Dec 11, 2018 at 7:44 PM Tom Eastep wrote: >> On 12/11/18 3:10 PM, Alex wrote: >>> >>> Here is an example. The 64.1.15.3 IP is in the DMZ behind the remote >>> firewall. This is a mail server trying to communicate with the mail >>> server on the local shorewall firewall. >>> >>> [11440.214121] ext-fw REJECT IN=br0 OUT= >>> MAC=0c:c4:7a:a9:18:de:a4:15:88:a9:30:b7:08:00 SRC=64.1.15.3 >>> DST=68.194.193.42 LEN=60 TOS=0x00 PREC=0x00 TTL=50 ID=10192 DF >>> PROTO=TCP SPT=52208 DPT=25 WINDOW=29200 RES=0x00 SYN URGP=0 >>> >>> Here is my local hosts file. >>> vpn >>> br0:192.168.6.0/24,192.168.1.0/24,65.45.72.6,64.1.15.0/27,68.194.193.42,66.103.218.96/28,107.155.66.2 >>> ipsec >>> >>> Here is the output from 'shorewall dump' >>> https://pastebin.com/e8gvjmFr >>> >> The dump shows that there is no IPSec policy that covers 64.1.15.3 -> >> 68.194.193.42. So this traffic is being treated as coming from the vpn >> zone. This is an IPSEC configuration issue, not a Shorewall >> configuration issue. The above should have read "is NOT being treated as coming from the vpn zone". > Can you explain where you see that the traffic is being treated as > coming from the VPN zone? To be treated as coming from the vpn zone, traffic from 64.1.15.3 to 68.194.193.42 must have an IPSec security policy. From the dump, we see in the Security Policy Database (SPD) that there are policies from 64.1.15.0/27: src 64.1.15.0/27 dst 192.168.1.0/24 uid 0 dir fwd action allow index 226 priority 1042404 ptype main share any flag (0x) lifetime config: limit: soft (INF)(bytes), hard (INF)(bytes) limit: soft (INF)(packets), hard (INF)(packets) expire add: soft 0(sec), hard 0(sec) expire use: soft 0(sec), hard 0(sec) lifetime current: 0(bytes), 0(packets) add 2018-12-11 17:21:37 use 2018-12-11 18:08:58 tmpl src 65.45.72.6 dst 68.195.192.42 proto esp spi 0x(0) reqid 16397(0x400d) mode tunnel level required share any enc-mask auth-mask comp-mask src 64.1.15.0/27 dst 192.168.1.0/24 uid 0 dir in action allow index 216 priority 1042404 ptype main share any flag (0x) lifetime config: limit: soft (INF)(bytes), hard (INF)(bytes) limit: soft (INF)(packets), hard (INF)(packets) expire add: soft 0(sec), hard 0(sec) expire use: soft 0(sec), hard 0(sec) lifetime current: 0(bytes), 0(packets) add 2018-12-11 17:21:37 use 2018-12-11 18:08:24 tmpl src 65.45.72.6 dst 68.195.192.42 proto esp spi 0x(0) reqid 16397(0x400d) mode tunnel level required share any enc-mask auth-mask comp-mask Both of them cover traffic destined for 192.168.1.0/24; the first is for forwarded traffic and the second is for input traffic. Since the mail server is running on the Shorewall system itself, the destination IP address is 68.194.193.42 which isn't covered by the input policy. > > Can I define a VPN policy in shorewall that includes 64.1.15.0/28 and > 66.103.218.0/27, the two ranges in the DMZ, in the same way I defined > the 65.45.72.2 endpoint? If you want the email traffic to be sent through the VPN, then you must add an ipsec policy for that traffic in your FreeSwan configuration. > > Should I remove those ranges from the vpn entry in the shorewall hosts file? You certainly don't need the IP subnets in that entry. Any traffic matching an active SPD entry will be treated as coming from or going to the vpn zone. -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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] DNAT from specific host
On 12/13/18 12:40 AM, HÖGLUND, Göran via Shorewall-users wrote: > Hi > > I can not figure out how to DNAT traffic from a specific IP address in > one zone to a specific ip address in another zone all let all other > traffic be treated ”normally” > > My idea is: > > DNAT loc:192.168.0.2 dmz:192.168.1.2 udp 53 > > Seems to fail …. That rule will forward UDP DNS requests from 192.168.0.2 in the loc zone to the DNS server at 192.168.1.2 in the dmz zone, PROVIDED THAT there are no existing conntrack entries for udp 53 from 192.168.0.2 to whatever the original destination address in the request. If the conntrack utility is installed, you can delete any such entries via: conntrack -D -s 192.168.0.2 -p udp --dport 53 -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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] DNAT from specific host
On 12/13/18 9:00 AM, Tom Eastep wrote: > On 12/13/18 12:40 AM, HÖGLUND, Göran via Shorewall-users wrote: >> Hi >> >> I can not figure out how to DNAT traffic from a specific IP address in >> one zone to a specific ip address in another zone all let all other >> traffic be treated ”normally” >> >> My idea is: >> >> DNAT loc:192.168.0.2 dmz:192.168.1.2 udp 53 >> >> Seems to fail …. > > That rule will forward UDP DNS requests from 192.168.0.2 in the loc zone > to the DNS server at 192.168.1.2 in the dmz zone, PROVIDED THAT there > are no existing conntrack entries for udp 53 from 192.168.0.2 to > whatever the original destination address in the request. > > If the conntrack utility is installed, you can delete any such entries via: > > conntrack -D -s 192.168.0.2 -p udp --dport 53 > One more thing - DNS sometimes falls back to TCP if the response is too long for a single datagram. So you probably want: DNAT log:192.168.0.2 dmz:192.168.1.2 udp,tcp 53 -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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
[Shorewall-users] Shorewall 5.2.1.4
Shorewall 5.2.1.4 is now available for download. Problems Corrected: ) A change in 5.2.0.5 that corrected an ip[6]tables error in the UNTRACKED section of the rules file, changed the name of the chain used to hold UNTRACKED rules. Previously, the chain was named &z1-z2, where 'z1' is the source zone and 'z2' is the destination; after the change, the chain was named =z1-z2. Unfortunately, some log messages generated out of these chains still referred to &z1-z2; that has been corrected. 2) Some dead/silly code has been removed from two functions in the Chains.pm Perl module. The two functions have been combined into a single function. 3) When the RATE column contains both a source and a destination rate, it was previously impossible to specifiy a netmask (VLSM) on either rate. Attempting to specify a mask would result in: ERROR: Invalid rate (...) That has been corrected. Note that when specifying a netmask, the leading 's' or 'd' may not be omitted. 4) Several typos in the man pages have been corrected (Roberto Sánchez. Thank you for using Shorewall, -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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] DNAT from specific host
On 12/18/18 4:24 AM, HÖGLUND, Göran via Shorewall-users wrote: > Thanks! > This works perfect, I have a follow up question though and this may be the > cause to my real problem. > Instead of a dns server in the dmz zone I'd like to reach a dns server over a > openvpn connection. > > The tunnel device tun9 is defined as a zone, we use the tunnel to reach the > firewall from a Nagios server where the tunnel terminates. > Tcpdump show traffic entering the tunnel and it looks fine from the Shorewall > perspective in the client. > On the server side the dns traffic from my host on the local lan on the > client is missing. If tcpdump see outgoing traffic, then the configuration on that end is okay. > > When I start Shorewall I get a warning about the tunnel > WARNING: Optional Interface tun9 is not usable -- tun9 not Started Try 'shorewall enable tun9'. -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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] dnat / masq issue possibly rt_table too
On 12/18/18 6:43 AM, Vincent G wrote: > Hi there, > > I'm having a configuration issue when trying to DNAT over a multi nic > setup : > > I'm using debian8/jessie with shorewall 4.6.4.3 from packages > > The shorewall instance is connected to 4 interfaces with 3 zones : > - eth0: net > - eth1: net > - eth2: hard > - eth3: prod > > Yes, the first two interfaces are on the same network with different IPs > (eth0 : 10.31.0.101/24 / eth1: 10.31.0.102/24 / gateway : 10.31.0.254) > For testing purpose these IP addresses are static, but in the real world > it will be dhcp assigned ones. > > Goal is to DNAT incoming requests (and filter/drop other) : > - from net to ip101:443 to prod:172.31.1.31 > - from net to ip101:22 to prod:172.31.1.230 > - from net to ip102:443 to prod:172.31.1.61 > - from net to ip102: to prod:172.31.1.61 > > All traffic from prod zone must go from eth0 to net zone. > > I've setup some rt_tables and ip rules and ping is working fine (with or > without shorewall) : > from net to ip101 : icmp traffic seen on eth0 > from net to ip102 : icmp traffic seen on eth1 > from ip101 (ping -I eth0 or ping without -I switch) : icmp traffic seen > on eth0 > from ip102 (ping -I eth1) : icmp traffic seen on eth1 > > I can have dnat working for ip101 OR ip102 but not for both. > I see martian source kernel errors for the non-working DNAT rule. (IPv4: > martian source 172.31.1.31 from 10.31.0.254, on dev eth0) > > I've attached a dump of my current setup one working for ip102 but > throwing martian source for requests on ip101 > > I've been struggling with this setup and cannot achieve what I want, can > someone point me to the mistake I've made ? > Are you following the configuration guidance in http://www.shorewall.org/MultiISP.html? You can accomplish what you want fairly easily if you do. If you follow that guide and still have issues, please submit the output of 'shorewall dump' collected as described at http://www.shorewall.org/support.htm#Guidelines -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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] Problems only with authentications
On 12/18/18 9:23 AM, Fausto Rambotti wrote: > Hi all. > I have a shorewall 4.6 on a Debian, everything work well apart the > authentication on some services on Internets. > I mean that even if I can connect with some services like POP3/S or > IMAP/S (tested with telnet and openssl), but the authentication fail > only when shorewall is up. > The authentication happen succesfully without shorewall and only the > masquerading. > Same thing with clients like thunderbird or outlook. > Any idea to solve this issue? > Not without seeing the output of 'shorewall dump' - see http://www.shorewall.org/support.htm#Guidelines -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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] SNAT between internal networks
On 12/18/18 12:01 PM, Erich Titl wrote:
> Hi
>
> I have a shorewall configuration where on the internal interface I set
> up several vlans which are represented to shorewall as zones loc1 to locn.
>
> Now all these zones are masqueraded towards the net using entries in
> SNAT. So far so good.
>
> Zone loc1 serves as something like a master or administrative zone and I
> would like to access Wifi APs in the zones loc(!1) from loc1 using
> http(s). Some of the Wifi equipment appears to only accept traffic from
> the local network for administration, so I would like to masquerade
> traffic from loc1 to locx so it appears that the traffic comes from the
> local zone.
>
> Any ideas
>
MASQUERADEethx.2
MASQUERADEethx.3
MASQUERADEethx.4
...
where
is the subnet associated with loc1
ethx.n is the interface to locn
-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
___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] DNAT from specific host
On 12/18/18 11:58 PM, HÖGLUND, Göran via Shorewall-users wrote: > Thanks for the tip, did not help though or maybe enabled in the wrong place. > I inserted the command in the openvpn init script when the tunnel is > successfully up running. > > Changing 1 to 0 in tun9.status in the client cleared the warning. > > It must be a simple miss I've made > > > Running on server and nothing comes out. > tcpdump -i tun0 udp port 53 > > Running on client > 07:50:09.922232 IP 172.29.71.195.52801 > 10.0.0.6.domain: 50186+ A? > www.msftconnecttest.com. (41) That is using tcpdump on the firewall's tun9 interface? > > Shorewall show routing shows > 10.0.0.6 via 10.89.1.249 dev tun9 > In main table. > > Info in policy file produces the expected output of blocked traffic in the > syslog, this traffic is completely lost, I can only see it hitting the tunnel > on the client side. > Same domain look up from firewall works perfect. > > Beats me. > Me too. -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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
[Shorewall-users] Shorewall 5.2.2 Beta 1
Shorewall 5.2.2 Beta 1 is now available for testing. Problems Corrected: 1) This release includes defect repair through Shorewall 5.2.1.4. New Features: 1) New macros have been contributed by Vincas Dargis: Bitcoin Tor ONCRPC Additionally, Tuomo Soini has contributed a WUDO (Windows Update Delivery Optimization) macro. 2) The Perl modules have undergone some cleanup/optimization. 3) Given that recent kernels have dropped ULOG support, use of ULOG in Shorewall is now deprecated and results in a warning message. The warning can be eliminated by switching to NFLOG and ulogd2. 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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] WireGuard Port Forwarding
On 12/22/18 4:17 PM, C. Cook wrote: > I've set up WireGuard on a VM in my LAN. In the LAN's router I am > port-forwarding my chosen (UDP) WireGuard port to the WireGuard server > in the LAN. (All CentOS 7.6) I've forwarded the shorewall.dmp from the > WG server to Tom. > > For the life of me I can not get the WG phone app communicating with the > server. O am getting occasional Shorewall blockages, but because times > are not in the line I don't know when they relate. For example this is > on the router: > > [1123910.652480] FORWARD REJECT IN=eth0 OUT=eth0 > MAC=00:1f:5b:69:23:8c:f6:b5:2f:a2:db:8e:08:00 SRC=172.58.40.50 > DST=10.1.50.16 LEN=176 TOS=0x00 PREC=0x00 TTL=53 ID=0 PROTO=UDP > SPT=37262 DPT=7962 LEN=156 > [1123915.644317] FORWARD REJECT IN=eth0 OUT=eth0 > MAC=00:1f:5b:6:23:8c:f6:b5:2f:a2:db:8e:08:00 SRC=172.58.40.50 > DST=10.1.50.16 LEN=176 TOS=0x00 PREC=0x00 TTL=53 ID=0 PROTO=UDP > SPT=37262 DPT=7962 LEN=156 > > Here's the DNAT in rules: > > DNAT net local:10.1.50.16 udp wgvpn - > > So FFS it's supposed to receive it in eth0, but then it's supposed to > send it back out eth1 not eth0. > > Interfaces: > > net eth0 tcpflags,dhcp,nosmurfs,routefilter,sourceroute=0 > local eth1 tcpflags,nosmurfs,routefilter > > Any idea what's going on? > Clearly, your routing table indicates that the packet should be sent out of eth0 rather than eth1, and since eth0 doesn't have the 'routeback' option, the packet is being dropped in the FORWARD chain (see Shorewall FAQ 17). -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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] LAN Routing
On 12/28/18 10:08 AM, C. Cook wrote: > Idk whether this is a Shorewall question or not. > > My LAN has a class C of 192.168.1.0. The gateway for all LAN members is > 192.168.1.1 > > Now one of the LAN members is a KVM VM at 192.168.1.16, and it is the > Wireguard VPN server. Remote machines come in through the gateway and > are port-forwarded to the VPN server for full access to the LAN. This > works fine now. (Thank you) > > First Question: Remote VPN members can access any node in the LAN, but > can not get back out through the gateway for internet access. Any idea > where I should look? The VPN server does have its gateway set to > 192.168.1.1. Is the remote VPN client configured to use the VPN as a default route? > > Second Question: Another member of the LAN, 192.168.1.4, is the backups > server. And the backups server runs a KVM VM which handles all security > cameras (ZoneMinder) through a dedicated port in the class C of > 10.1.50.0. This security cam VM has a second IP in the class C of the > LAN and serves Zoneminder to the LAN this way. > > I would like to serve Zoneminder to the outside only on the VPN. Does > that mean I port-forward 80 to the VPN server, either through a reverse > SSH tunnel or by Shorewall DNAT? Then to access it from remote on the > VPN server? Is this the best way? Would it then also still be > accessible to the LAN? I'm confused. Who initiates this TCP connection on port 80 and where is the http server? > > Third Question: The cameras on 10.1.50.0 are only visible to the > cameras server on a dedicated port. These cameras provide a high-res > RTSP stream and a low-res RTSP stream, the latter being appropriate for > a remote phone. Can anyone see how I can pipe the low-res stream to the > VPN server so it's accessible by a remote phone? > Is this stream accessible from other hosts on the LAN? If so, how? -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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] FTP shorewall Helper
On 12/28/18 10:48 AM, Naveen Neelakanta wrote: > > Hi All, > > I am facing issues with ftp traffic, when the client initiates the > ftp connection, I see it leave the internet interface after getting > NATed with internet interface IP, I see the return traffic on the > internet interface I don't see it getting forwarded, nor hitting the > conntrack entry. > I have enabled the FTP helper in /etc/shorewall/conntrack , i am using > shorewall version "5.2.0.4". > > Let me know if i am missing something. > > ?if $AUTOHELPERS && __CT_TARGET > ?if __FTP_HELPER > CT:helper:ftp:PO - - tcp 21 > ?endif > ?endif > > i have the AUTOHELPERS= yes in shorewall.conf > > #lsmod | grep nf_nat_ftp > nf_nat_ftp 2028 0 > nf_conntrack_ftp 6942 3 nf_nat_ftp > nf_nat 15273 12 > nf_nat_pptp,nf_nat_proto_gre,xt_nat,nf_nat_h323,nf_nat_sip,openvswitch,nf_nat_irc,nf_nat_ftp,nf_nat_amanda,nf_nat_masquerade_ipv4,nf_nat_ipv4,nf_nat_tftp > nf_conntrack 87157 28 > nf_nat_pptp,nf_conntrack_sip,nf_conntrack_irc,xt_nat,nf_nat_h323,nf_conntrack_ftp,nf_nat_sip,openvswitch,nf_conntrack_ipv4,nf_conntrack_tftp,ipt_MASQUERADE,nf_nat_irc,nf_conntrack_pptp,nf_conntrack_amanda,nf_conntrack_broadcast,nf_nat_ftp,nf_conntrack_sane,nf_nat_amanda,nf_conntrack_netlink,nf_conntrack_netbios_ns,nf_conntrack_proto_gre,xt_CT,nf_nat_masquerade_ipv4,nf_conntrack_h323,xt_conntrack,nf_nat_ipv4,nf_nat_tftp,nf_nat > > The helper is not required in order to establish the initial control connection. So if you are having problems with that part, the issue doesn't involve the helper. The helper get involved during establishment of the data connection created to handle get, put, ls, etc. It sounds like the 'client' in this case is in your local lan? If so, the CT rule would be hit in the nat table PREROUTING chain when the original SYN packet was received by the firewall from the client. I'll take a look if you: - shorewall reset - - shorewall dump > shorewall.dump - Send me the shorewall.dump file (as an attachment) along with the IP addresses of the client and server Thanks, -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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] FTP shorewall Helper
On 12/30/18 5:33 PM, Naveen Neelakanta wrote: > Hi Tom, > > I see that only the FTP Passive Mode works, but is there any other > settings that i need to enable for the active mode to work. I believe > Linux nf_nat_ftp and nf_conntrack_ftp should take care of the mapping > correct and i see they are getting loaded. > > ubuntu@BR2-UBUNTU1:~$ ftp 144.208.69.31 > Connected to 144.208.69.31. > 220-- Welcome to Pure-FTPd [privsep] [TLS] -- > 220-You are user number 18 of 150 allowed. > 220-Local time is now 17:01. 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 30 minutes of inactivity. > Name (144.208.69.31:ubuntu): dlpu...@dlptest.com > <mailto:dlpu...@dlptest.com> > 331 User dlpu...@dlptest.com <mailto:dlpu...@dlptest.com> OK. Password > required > Password: > 230 OK. Current restricted directory is / > Remote system type is UNIX. > Using binary mode to transfer files. > ftp> ls > 500 I won't open a connection to 10.24.8.11 (only to 96.64.220.253) > ftp: bind: Address already in use That is your FTP server refusing to create the active mode connection. Is there a router in front of the Shorewall box that is doing SNAT on incoming connections? > > conntrack entry: > tcp 6 430709 ESTABLISHED src=10.24.8.11 dst=144.208.69.31 > sport=53478 dport=21 src=144.208.69.31 dst=10.24.8.117 sport=21 > dport=53478 [ASSURED] mark=0 zone=4 use=1 > > 30-001011-4894:/log/home/test# shorewall show capabilities | grep FTP > FTP Helper: Available > FTP-0 Helper: Not available > TFTP Helper: Available > TFTP-0 Helper: Not available > The Shorewall box thinks that the client IP address is 10.24.8.11, while your FTP server thinks that it is 96.64.220.253. -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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] LAN Routing
On 12/29/18 2:26 PM, C. Cook wrote: > > On 12/28/18 1:34 PM, Tom Eastep wrote: >> On 12/28/18 10:08 AM, C. Cook wrote: >>> Idk whether this is a Shorewall question or not. >>> >>> My LAN has a class C of 192.168.1.0. The gateway for all LAN members is >>> 192.168.1.1 >>> >>> Now one of the LAN members is a KVM VM at 192.168.1.16, and it is the >>> Wireguard VPN server. Remote machines come in through the gateway and >>> are port-forwarded to the VPN server for full access to the LAN. This >>> works fine now. (Thank you) >>> >>> First Question: Remote VPN members can access any node in the LAN, but >>> can not get back out through the gateway for internet access. Any idea >>> where I should look? The VPN server does have its gateway set to >>> 192.168.1.1. >> Is the remote VPN client configured to use the VPN as a default route? > > It's set so that no applications are exempted from using the VPN. I > should think this would be equivalent. Seems to be my only option. > I doubt that the setting you are talking about redirects all traffic through the tunnel. > >> >>> Second Question: Another member of the LAN, 192.168.1.4, is the backups >>> server. And the backups server runs a KVM VM which handles all security >>> cameras (ZoneMinder) through a dedicated port in the class C of >>> 10.1.50.0. This security cam VM has a second IP in the class C of the >>> LAN and serves Zoneminder to the LAN this way. >>> >>> I would like to serve Zoneminder to the outside only on the VPN. Does >>> that mean I port-forward 80 to the VPN server, either through a reverse >>> SSH tunnel or by Shorewall DNAT? Then to access it from remote on the >>> VPN server? Is this the best way? Would it then also still be >>> accessible to the LAN? >> I'm confused. Who initiates this TCP connection on port 80 and where is >> the http server? > > The remote phone could initiate it using the ZM app, or any random > machine inside the LAN could initiate it. Only the WireGuard server is > running Wg so no internal communications is VPN. > > Communication with the cameras could be via port 80 to get ZoneMinder > functionality, or directly from the cameras by getting the rtsp stream > with something like VLC. Then, since the backup server is on the LAN, VPN clients should be able to connect to it directly. > >> >>> Third Question: The cameras on 10.1.50.0 are only visible to the >>> cameras server on a dedicated port. These cameras provide a high-res >>> RTSP stream and a low-res RTSP stream, the latter being appropriate for >>> a remote phone. Can anyone see how I can pipe the low-res stream to the >>> VPN server so it's accessible by a remote phone? >>> >> Is this stream accessible from other hosts on the LAN? If so, how? > To access the camera directly, the Shorewall box needs to have a route to the 10.1.50.0/24 subnet via the backup server's 192.168.1.4 address and the backup server would need to enable IP forwarding. Assuming that you can get default routing from the VPN client to go through the tunnel, then the VPN clients can access the server directly. > It's not, because the cameras are in a different class C than the LAN. > The rtsp streams can be reached by the backups server (KVM host to the > cameras VM) because it has a dual IP, one of which is in the cameras' > domain. > > If I add IPs to all machines in the LAN I'm concerned that this would > put them in the collision domains of the cameras, defeating the purpose > of having them in a different class C. > > If you are concerned about 10.1.50.0/24 colliding with a network local the the VPN client, you can use DNAT on the Shorewall box. You could have VPN clients connect to port 81 on IP 192.168.1.4, which would be DNATted to the dedicated port on the camera. -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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] FTP shorewall Helper
On 12/31/18 10:12 AM, Naveen Neelakanta wrote: > The box on which the shorwall is running is doing the SNAT. But it is doing SNAT of *outgoing* requests only, correct? There is no SNAT occurring on the FTP control connection whose conntrack entry you forwarded. > aybe an > external facing firewall is doing another NAT with the source ip ( > 96.64.220.253) hence I am not seeing any new connection back on my > device. Should i see a new connection request from the server to > ip 96.64.220.253 , will there be an entry created by FTP helper to > accept the new connection request coming from the server ( i don't see > it in the conntrack entry ). Please understand that the problem you are seeing here has *nothing* to do with the Shorewall box or with FTP helpers. The problem is that the FTP server is refusing to create an active mode data connection to 10.24.8.11. Was that the actual IP address of the ftp client or was it 96.64.220.253? -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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] FTP shorewall Helper
On 12/31/18 7:02 PM, Naveen Neelakanta wrote: > Hi Tom, > > After adding the zones in the conntrack , i start seeing this issue, > where the nf_nat_ftp is not getting called. If I remove the zones from > conntrack entry, I don't see the issue, but I need the zones. > > Any pointers to solve this will help. > I don't have any, as I have no experience with conntrack zones. I can envision potential problems with active mode FTP and zones if the zone for client->FTPserver traffic is different from the one for FTPserver->client traffic. You seem to be using "CT --zone x", according to your earlier post(s). I see that "CT --zone-orig x" and "CT --zone-reply x" are also supported, but again, I have no experience with using them. -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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] FTP shorewall Helper
On 1/1/19 2:05 PM, Naveen Neelakanta wrote: > Hi Tom > > This works where zone 2 is the internet facing zone. > > ?if __FTP_HELPER > > IPTABLES(CT --zone 2 --helper ftp) eth3 - > tcp 21 > > IPTABLES(CT --zone 2 --helper ftp):O 0.0.0.0/0 <http://0.0.0.0/0> > eth3 tcp 21 > > IPTABLES(CT --zone 2 --helper ftp) veth-e3-p - > tcp 21 > > IPTABLES(CT --zone 2 --helper ftp):O 0.0.0.0/0 <http://0.0.0.0/0> > veth-e3-p tcp 21 > > ?endif > > > Please find the attached conntrack file, please let me know if this is > the right way to do it or is there a better way. > > Can I use a generic zone id in this case or just the zone which is > internet facing? > You may need to add additional entries for your other zones, if you need to provide ftp access from those zones. -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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] Making shorewall.net accessible with https
On 1/4/19 9:47 AM, Bruno Friedmann wrote: > Actually trying to connect with https the website return an error > with misconfigured certificate > > They belong to mastermind > We have no plans to make the Shorewall web sites and mirrors accessible via https. -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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] NOTRACK interface
On 1/7/19 2:04 PM, Naveen Neelakanta wrote:
> Hi Tom,
>
>
> iptables/netfilter allows us to match based on a device group and the
> net devices can be added or removed from a device group like below:
>
>
>
> ip link set dev eth0 group 42
>
> ip link set dev eth1 group 42
>
> ip link show group 42
>
> 2: eth0: mtu 1500 qdisc pfifo_fast
> state UP mode DEFAULT group notrack_interfaces qlen 1000
>
> link/ether 00:0c:29:a1:3f:ce brd ff:ff:ff:ff:ff:ff
>
> 3: eth1: mtu 1500 qdisc pfifo_fast
> state UP mode DEFAULT group notrack_interfaces qlen 1000
>
> link/ether 00:0c:29:a1:3f:d8 brd ff:ff:ff:ff:ff:ff
>
>
>
> Now this can be used to match a dev group like below:
>
>
>
> iptables -t raw -I PREROUTING 1 -m devgroup --src-group 42 -j CT --notrack
>
> iptables -t raw -I OUTPUT 1 -m devgroup --dst-group 42 -j CT --notrack
>
>
> Can this be achieved using Shorewall, if possible?, can you please share
> an example.
>
It cannot be accomplished in the raw table, because the 'conntrack' file
does not currently allow inline matches. In those files that do allow
inline matches, you can accomplish this by following the rule with:
;; -m devgroup --{src|dst}-group nn
-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
___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] Routing Question
On 1/7/19 10:02 AM, C. Cook wrote: > I have a WireGuard server running in a KVM virtual machine in my LAN. > (CentOS 7.6) It accepts WG connections from the outside (phone, laptop) > and this is working fine with port-forarding, but I also intend it to be > the Azire VPN access to the outside for the LAN. > > This question is about the latter. I want every machine in the LAN to > go out through the Azire tunnel. > > The WG interface is running on the server: > > # ip address > 1: lo: mtu 65536 qdisc noqueue state UNKNOWN > group default qlen 1000 > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 > inet 127.0.0.1/8 scope host lo > valid_lft forever preferred_lft forever > 2: eth0: mtu 1500 qdisc pfifo_fast > state UP group default qlen 1000 > link/ether 52:54:00:c0:46:30 brd ff:ff:ff:ff:ff:ff > inet 192.168.1.16/24 brd 192.168.1.255 scope global eth0 > valid_lft forever preferred_lft forever > 5: outgoingWG-ca1: mtu 1420 qdisc > noqueue state UNKNOWN group default qlen 1000 link/none > inet 10.34.8.123/19 scope global outgoingWG-ca1 > valid_lft forever preferred_lft forever > > But to start with I want to route all traffic from this server out the > WG interface, rather than eth0. > > # route > Kernel IP routing table > Destination Gateway Genmask Flags Metric Ref Use > Iface > default gateway 0.0.0.0 UG 0 0 0 eth0 > 10.34.0.0 0.0.0.0 255.255.224.0 U 0 0 0 > outgoingWG-ca1 > link-local 0.0.0.0 255.255.0.0 U 1002 0 0 eth0 > 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 > > How would this be done? There is no > /etc/sysconfig/network-scripts/ifcfg-outgoingWG-ca1 where I could set > gateway since the WG interface is created by a systemd service. Is > there a Shorewall trick I could use? > > Then, how would I route the rest of the LAN to this WG server and out > the WG interface to the greater internet? You also have to remember that the encapsulated VPN traffic must still be routed out of eth0, which further complicates your question. I'm afraid that I don't know enough about WG to advise you, and I also don't use systemd for network 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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
[Shorewall-users] Shorewall 5.2.2 Beta 2
Shorewall 5.2.2 Beta 2 is now available for download. New Feature: 1) Shorewall can now detect interface default gateways configured by Network Manager. 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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] SNATting
On 1/9/19 1:25 PM, C. Cook wrote:
> I guess I don't understand the concept of SNATting, or whether I in fact
> need it. Seems like it's the reverse of DNAT, for going -out-.
>
> I have a KVM VM which is a WireGuard server. It's working fine with the
> tunnel VPN going out. But I also want all the other machines in the LAN
> to send their unknown web references out the tunnel as well.
>
> Seems like I need to set the LAN machines so their gateway is the WG
> server. And it seems like I need to set up dnsmasq and chrony so the WG
> server can use the special DNS server of my VPN provider and share that
> with the LAN.
>
> Now I -thought- that allowing in rules, source traffic from zone
> net{LANIP}, to zone outWG would do it, but LAN traffic doesn't go out.
> I think I'm missing something in the snat file, and maybe rules.
>
> Any suggestions?
>
Not without the output of 'shorewall dump'
-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
___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] Weights on balance and fallback
Hi Norm, On 1/9/19 11:24 PM, Norman Henderson wrote: > Hi, We have several different real internet connections as well as > tunnels used for certain purposes. Some have "capped" volume and others > not; the ones that do not have different data rates; and all have > varying reliability. > > I'm having trouble understanding how the weight values work for the > options balance= and fallback= on a provider. > > I saw IP Route documentation suggesting that weights on "nexthop" > clauses (which are what get created by the cited options in the > providers file), are packet proportions i.e. > nexthop via x weight 1 > nexthop via y weight 10 > would send 10 packets over y for every packet sent over x > > However, experiments with the option balance= in shorewall providers > suggest that a lower number gives a higher priority to a particular > provider. > > Can someone give a clear explanation? In Shorewall, the weights in 'nexthop' are only relevant to the first packet of each outgoing flow. Once an interface is picked, that interface is used for all outgoing packets of that flow. So it is *flows* that are distributed via those weights, and not *packets*. We take that approach to avoid sending packets with a source IP of one ISP out through the network of another ISP, as ISPs have a habit of dropping such packets. > > Also, I believe providers with option fallback=n are never used unless > all of the balance= providers are disabled, is that correct? Yes. > And then, > do the weights work the same way as for balance? > Yes. -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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] SNATting
On 1/9/19 3:08 PM, C. Cook wrote: > > I got it. I was missing a snat MASQUERADE entry on the WG server. > > WireGuard service for my LAN is now fully functional. The VM running WG > server has channels for in from my phone, etc, and out through > AzireVPN. Soon I'll set up another out channel to serve websites and email. > > The Spain PoP looks like it's going to be slow. > Glad to hear that you got it sorted, -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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] Weights on balance and fallback
On 1/10/19 9:18 AM, Norman Henderson wrote: > Thank you Tom. Can you clarify the significance of the numbers: > e.g. provider a weight 1, provider b weight 10, provider c weight 100, > which provider is preferred and what will be the proportional allocation > of new flows? New flows will be apportioned in the same proportions as the weights. It is my understanding that the algorithm builds a list containing "weight" number of entries for each provider. Flows are then allocated using a round-robin approach. I don't know how this list is ordered. -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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] one to one NAT
On 1/10/19 5:03 PM, Naveen Neelakanta wrote: > Yes, I did go through that, what I don't understand is, if one to one ( > private to public ) nat rule is added in nat file, why do we need an > additional rule to allow outside IP to send traffic to inside private > IP, won't the one to one rule take care of this. Yes -- that's the whole point of the nat file.. -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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] Interface's wait=200 returns error whereas wait=120 does not. Why?
On 1/11/19 3:18 PM, Fog_Watch wrote: > Hello > > I would like an option on my ppp0 interface to be wait=200. When set > the following error is returned "Invalid value (200) for option wait". > wait=120 returns no such error. How do I set wait=200? > You can't - the maximum allowed value for 'wait' is 120 (2 minutes) -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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] Websites Are Down!
On 1/12/19 2:08 PM, C. Cook wrote: > > On 1/12/19 1:24 PM, C. Cook wrote: >> >> >> On 1/12/19 1:10 PM, C. Cook wrote: >>> >>> >>> On 1/12/19 12:45 PM, C. Cook wrote: >>>> >>>> >>>> On 1/12/19 12:37 PM, Roberto C. Sánchez wrote: >>>>> On Sat, Jan 12, 2019 at 12:33:48PM -0800, C. Cook wrote: >>>>>>... and can't get up! >>>>>> >>>>>>[Sat Jan 12 11:56:22 2019] FORWARD REJECT IN=eth0 OUT=eth0 >>>>> >>>>> >>>>> Have you specified routeback for eth0 in interfaces? >>>>> >>>>> Regards, >>>>> >>>>> -Roberto >>>> >>>> No, but never have in the past. Suddenly it stopped working. >>>> >>>> Now I've changed the line to: >>>> >>>> net eth0 >>>> tcpflags,dhcp,nosmurfs,sourceroute=0,routefilter,routeback >>>> >>>> ... and I'm no longer getting the forwarding or any other error in >>>> my router or server, but I still can't pull up delphi-real-estate.com >>>> >>> Ok, the router's interface looking toward the DMZ has no IP! >>> >>> It thinks another system has its IP, but I don't have one set >>> anywhere. Maybe 10.1.1.1 is no-mans-land? >>> >> Fixed the IP and I can ping the DMZ Apache server VM from the router >> now, but curl to it and access from the outside still doesn't work. >> > I've confirmed that thr router is -not- passing along the ports to the > DMS, even though this is set: > > Web(DNAT) net dmz:10.1.1.30 - - - > - 3/sec:10 > Web(DNAT) local dmz:10.1.1.30 - - - > ð0 > > ... and forwarding is on in all quarters. > > I don't have anything in snat. Is there supposed to be? > > What you are trying to do *will never work*. You are accepting web connections on the public IP address on the Shorewall router, port forwarding them to the web server who is trying to reply out of the WG server. There are two problems with this idea: a) The WG server can't reverse the effect of the DNAT in the router, so the responses are going out with the wrong source IP. b) Even if DNAT were not involved, you would likely be sending packets out through one ISP with source addresses assigned to another ISP. Those are subject to being dropped. -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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] Websites Are Down!
On 1/13/19 11:21 AM, C. Cook wrote: > >> What you are trying to do *will never work*. You are accepting web >> connections on the public IP address on the Shorewall router, port >> forwarding them to the web server who is trying to reply out of the WG >> server. There are two problems with this idea: >> >> a) The WG server can't reverse the effect of the DNAT in the router, so >> the responses are going out with the wrong source IP. >> >> b) Even if DNAT were not involved, you would likely be sending packets >> out through one ISP with source addresses assigned to another ISP. Those >> are subject to being dropped. >> >> -Tom > > Understand. But I only arrived here after my sites went down with no > mods to the webserver VM, and a full day of trying to get them back up. > > And my goal is ultimately to move my server to the outgoing VPN, but > that's low priority. Sites out is high priority. > The obvious fix is to change the web server's default gateway back to the Shorewall router. -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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] Interface's wait=200 returns error whereas wait=120 does not. Why?
On 1/13/19 2:26 PM, Fog_Watch wrote: > On Sat, 12 Jan 2019 08:07:18 -0800 > Tom Eastep wrote: > >> the maximum allowed value for 'wait' is 120 > Is this a limitation of iptables? > No -- it's a Shorewall-imposed limit. I really can't see stalling boot-up for more than 2 minutes if an interface isn't going to come up. -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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] rules with just ips
On 1/14/19 12:56 PM, Naveen Neelakanta wrote: > Hi All, > > Is it possible to just configure the Source Nat and Destination nat > rules without giving any zone informations or interface information and > just configure IPs address? > > Also see that if DNAT Rules is configured, SNAT rules in snat file is > being skipped, however, the masquerade is happening with the interface > ip, but I want to change the source ip from a NAT pool that is configured. > When DNAT is applied on an incoming flow, SNAT rules are ignored because the respose packet's source IP *must be* the destination IP in the incoming packet. > snat file: > SNAT(10.24.19.235)192.168.7.50/32 eth2:1.1.1.1/32 > rules file: > DNAT lan inet:2.2.2.2 0 - - 1.1.1.1 > > When I get the rule, I am not sure it belongs to which zone, i just get > the ipaddress and interface name. I don't understand why you cannot determine the zone. The zone *must* be known for Shorewall to generate the companion ACCEPT rule (remember that Shorewall DNAT rules generate two ip[6]tables rules: a DNAT rule in the nat table and an ACCEPT rule in the filter table). -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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] Interface's wait=200 returns error whereas wait=120 does not. Why?
On 1/15/19 3:03 AM, Matt Darfeuille wrote: > On 1/15/2019 11:37 AM, Fog_Watch wrote: >> On Mon, 14 Jan 2019 08:12:53 -0800 >> Tom Eastep wrote: >> >>> I really can't see stalling >>> boot-up for more than 2 minutes if an interface isn't going to come up >> My modem takes 3 minutes to get a DSL sync, so about 3 1/2 minutes >> after a power blackout ppp0 can be created. If "wait" could be 3 >> minutes then I'd be more confident that Shorewall would start correctly >> after a resumption of power. >> > > Have you considered the 'optional' option in '/etc/shorewall/interfaces'?: > > http://shorewall.org/manpages/shorewall-interfaces.html > Depending on how you have used ppp0 in your Shorewall configuration, if you use the 'optional' option for the interface, you may have to 'shorewall enable ppp0' after it comes up. This can be automated using a link status monitor like FooLSM. I'll consider raising the limit. But in the meantime, you can change it yourself: - in Zones.pm (you can use your distro's package manager to find the file), is a hash declaration for %maxoptionvalue which contains: wait = 120 - you can change that to: wait = 300 to up the limit to 5 minutes. -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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] communicate in-LAN via shorewall-gateway external IP?
On 1/15/19 11:54 AM, Brian J. Murrell wrote: > If I have a Shorewall gateway doing NAT to the Internet for an RFC-1918 > LAN behind it, should I be able to communicate to services that are on > the LAN through the gateway's external IP address from hosts on the > same LAN assuming there is DNAT policy successfully allowing external > hosts to communicate with with internal services? No -- See Shorewall FAQ 2 (http://www.shorewall.net/FAQ.htm#faq2) > > To explain, if I have a web server on the LAN that has a DNAT rule in > Shorewall allowing hosts on the Internet-side to reach it via > Shorewall's external IP, should hosts on the LAN be able to reach it by > the same Shorewall external IP? No -- again, see the above FAQ. > > If the answer is yes for a simple[r] service above like HTTP, should it > work equally well for SIP? If I have a SIP server on the LAN and when > the SIP server is INVITEing a SIP client on the LAN with an SDP payload > specifying the external IP for the media session, should the client on > the LAN be able to contact the SIP server on the Shorewall external IP > and port specified in the SDP and get that media session routed back > into the SIP server successfully? No -- again, see the above FAQ. > > For the above, it is safe to assume that SIP NAT traversal is working > successfully for hosts that are fully on the Internet-side of the > Shorewall gateway and media sessions get set up so that there is fully > functioning two-way audio. > Yes. Some of the other sub-FAQs of FAQ 2 discuss other aspects of this issue. -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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
[Shorewall-users] Shorewall 5.2.2 RC 1
Shorewall 5.2.2 RC 1 is now available for testing.
Problems Corrected:
1) When processing inline matches, the compiler previously inserted
the matches before the column-generated matches if there was a plus
sign ("+") anywhere in the matches. Now, it only does so if the
first non-blank character in the matches is a plus sign.
New Features:
1) Shorewall can now detect interface default gateways configured by
Network Manager.
2) Inline matches are now supported in the 'conntrack' file.
3) In the 'accounting' file, Inline matches in an INLINE(...) rule now
allow a leading '+' to cause the matches to be evaluated before
those generated by the column specifications.
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
___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] SNAT on a forwarding traffc
On 1/16/19 12:20 PM, Naveen Neelakanta wrote: > Hi Tom, > > Can I do a Source nat on the incoming traffic on an interface from > outside and it will be forwarded. > > If that is possible can you please share an example rule. > SNAT may only be performed on packets that are leaving the firewall. -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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
[Shorewall-users] Shorewall 5.2.2
Shorewall 5.2.2 is now available for download.
Problems Corrected:
1) This release includes defect repair through Shorewall 5.2.1.4. See
http://http://www.shorewall.org/pub/shorewall/5.2/shorewall-
5.2.1/releasenotes.txt.
2) When processing inline matches, the compiler previously inserted
the matches before the column-generated matches if there was a plus
sign ("+") anywhere in the matches. Now, it only does so if the
first non-blank character in the matches is a plus sign.
New Features:
1) New macros have been contributed by Vincas Dargis:
Bitcoin
Tor
ONCRPC
Additionally, Tuomo Soini has contributed a WUDO (Windows Update
Delivery Optimization) macro.
2) The Perl modules have undergone some cleanup/optimization.
3) Given that recent kernels have dropped ULOG support, use of ULOG in
Shorewall is now deprecated and results in a warning message. The
warning can be eliminated by switching to NFLOG and ulogd2.
4) Shorewall can now detect interface default gateways configured by
Network Manager.
5) Inline matches are now supported in the 'conntrack' file.
6) In the 'accounting' file, Inline matches in an INLINE(...) rule now
allow a leading '+' to cause the matches to be evaluated before
those generated by the column specifications.
7) If view of the fact that some modems take an eternity to recover
from a power failure, the limit of the 'wait' interface option
setting has been increased from 120 seconds (2 minutes) to 300
seconds (5 minutes).
Thank you for using Shorewall,
-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
___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] interface specific rules
On 1/17/19 4:58 PM, Naveen Neelakanta wrote: > > I tried with this , was getting error . > > DNAT any:eth2:0.0.0.0/0 <http://0.0.0.0/0> any:8.8.8.8 icmp > - - 1.1.1.1/32 <http://1.1.1.1/32> > ERROR: Source Interface (eth2) not allowed when the SOURCE is the > firewall /etc/shorewall/rules (line 21) > > So, I believe when we use interface, I have to specify its zone like the > below, which does not through any error. > I was looking for a way to use any and use the interface name. > > DNAT inet:eth2:0.0.0.0/0 <http://0.0.0.0/0> any:8.8.8.8 icmp > - - 1.1.1.1/32 <http://1.1.1.1/32> > > Regards, > Naveen > > > On Thu, Jan 17, 2019 at 4:41 PM Justin Pryzby <mailto:pry...@telsasoft.com>> wrote: > > On Thu, Jan 17, 2019 at 04:02:13PM -0800, Naveen Neelakanta wrote: > > Hi Tom, > > > > I have the below DNAT rule working, but I want to apply this rule > only for > > a specific interface, > > can we achieve that? > > > > DNAT any:0.0.0.0/0 <http://0.0.0.0/0> any:8.8.8.8 icmp > - - 1.1.1.1/32 <http://1.1.1.1/32> > > It says: > http://shorewall.net/manpages/shorewall-rules.html > > SOURCE - source-spec[,...] > Source hosts to which the rule applies. > source-spec is one of the following: > > zone:interface > ... > Why??? -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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] interface specific rules
On 1/17/19 10:25 PM, Naveen Neelakanta wrote: > Hi Tom, > > I was testing for a requirement for supporting for SNAT and DNAT support > for either direction outside to inside or inside to outside on the > interface configuration. > Hence I was testing DNAT rule on either direction, I was able to > achieve this but with any zone, could not restrict on just the interface. > My question is "What problem are you trying to solve by having DNAT rules that are independent of the incoming zone?". -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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] interface specific rules
On 1/18/19 8:52 AM, Tom Eastep wrote: > On 1/17/19 10:25 PM, Naveen Neelakanta wrote: >> Hi Tom, >> >> I was testing for a requirement for supporting for SNAT and DNAT support >> for either direction outside to inside or inside to outside on the >> interface configuration. >> Hence I was testing DNAT rule on either direction, I was able to >> achieve this but with any zone, could not restrict on just the interface. >> > > My question is "What problem are you trying to solve by having DNAT > rules that are independent of the incoming zone?". > But if you *really* want to do it, the following will forward all incoming icmp packets addressed to 1.1.1.1 to 8.8.8.8. Note that this only does the DNAT and does not generate any accompanying ACCEPT rules in the filter table /etc/shorewall/actions: Dnat /etc/shorewall/action.Dnat DNAT@1 @2 /etc/shorewall/rules Dnat(eth0, 8.8.8.8) all!$FWall icmp- - 1.1.1.1 -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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] interface specific rules
On 1/18/19 10:58 AM, Naveen Neelakanta wrote: > Thanks, Tom I will try that, to your question, let's say there are DNS > request to IP 4.2.2.2 udp/tcp 53 and I want to DNAT those to a different > DNS server (say 8.8.8.8) > > I get that. In the example you sent, you used 'any' rather than 'all'. Is it that you have multiple zones on an interface (possibly nested) and you want DNS requests from all of those zones to be forwarded? -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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] interface specific rules
On 1/18/19 12:14 PM, Naveen Neelakanta wrote: > No, I just have a single zone on that interface. > > cat /etc/shorewall/interfaces > inet eth2 detect tcpflags,nosmurfs,logmartians > > I tried the Dnat action method I did not see it getting translated, > below are the steps i did. > > /etc/shorewall/action.Dnat > DNAT @1 @2 > > /etc/shorewall/rules > Dnat(eth2,8.8.8.8) all!$FW all icmp - - 1.1.1.1/32 > > > Chain ~comb0 (11 references) > pkts bytes target prot opt in out source > destination > 0 0 DNAT icmp -- eth2 * 0.0.0.0/0 > <http://0.0.0.0/0> 1.1.1.1 to:8.8.8.8 > > > Since the traffic is coming from LAN and going out on eth2( WAN > ) interface, I believe I need to get the eth2 to be on the out interface > column, i tried few things to get the eth2 on the out column it did not > help. > > Any other suggestions? > If the traffic is coming from the LAN, then that should be the SOURCE zone. Given that 8.8.8.8 is external to your site, the destination zone is 'inet'. So, for 'ping', you would have: DNATlan inet:8.8.8.8icmpecho-request - 1.1.1.1 For DNS: DNATlan inet:8.8.8.8udp,tcp 53 - 1.1.1.1 Using the DNS macro: DNS(DNAT) lan inet:8.8.8.8- - - 1.1.1.1 If your lan->inet policy is ACCEPT, you can replace 'DNAT' with 'DNAT-'. -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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] interface specific rules
On 1/18/19 12:54 PM, Naveen Neelakanta wrote: > Thanks that was my last option, if I could not make the rule which was > an interface specific, so that I can avoid the duplicates in case, the > same rule is configured on another interface and also avoid getting > config w.r.t to the direction for the traffic flow like ( trusted to > untrusted ) or ( untrusted to trusted) . > > Naveen, If you are going to use Shorewall, you need to start thinking in terms of zones for rules rather than interfaces. -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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] Converting "masq" to "snat"
On 1/18/19 7:14 PM, ObNox wrote:
> Hi,
>
> If possible, when upgrading Shorewall, could it detect the file format
> of the "masq" file an use the same format on the converted "snat" file ?
>
> I mean : If "masq" is using the column-based format then convert to a
> column-based "snat" file, etc.
>
> I exclusively use the bracket-based format which I find way more
> readable when there are a lot of lines in any file.
>
> Currently, "masq" to "snat" conversion only produces column-based files
> which I find a bit hard to manually convert without errors to the
> bracket-format :-)
>
> Thank you.
>
> PS: I also exclusively use ${...} for variables format but I can leave
> with the $... (without brackets) and convert them all later with a
> single regex search/replace without errors :-)
>
I've taken a look at this and it would involve an almost complete
rewrite of the five conversion routines (tos -> mangle, tcrules ->
mangle, masq -> snat, routestopped -> stoppedrules, and blacklist ->
blrules). A complicating factor is that people most often use both
formats; they specify the leading contiguous columns, then use the
bracket-based format for the remaining options. I certainly don't want
to attempt to implement any changes to the conversion routines until
after the next major Debian release.
-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
___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] Exclusions
On 1/20/19 11:17 AM, C. Cook wrote: > I've recently changed all my LAN addresses from 192.168.111.0/24 to > 10.1.1.0/24, for simplicity and refinement. A better choice would be 10...0/24 where and are random numbers in the range 0-255. > > One odd thing I found was that I could not assign 10.1.1.1 because it > said some MAC address already had that. So I worked around that. That happens when there is another host *on the same LAN* that has that IP address. > > Suddenly I started getting Shorewall DROPs on my LAN members from > various _public_ IPs to ports 80, 443, and so on! This has never > happened in 10+ years of using Shorewall. I realized that it must be my > Frontier Communications fiber ONT that has 10.1.1.1 and it's letting > everyone and their brother into my LAN. Internet hosts can't send requests to your local LAN members, without there being DNAT somewhere along the line. Are you sure that you have the correct DNAT rules in place since you have renumbered your local subnet? > > So now I have to change everything to something else. But I also want > to exclude any possibility of outsiders getting in. Studying the docs > it seems the right way is in the router: > > ?SECTION ALL > DROP all > local:10.0.0.0/8,local:172.0.0.0/8,local:192.168.0.0/16 > all all > > Am I on the right track here? The above will break all connections that you allow from the net via DNAT. What policy/rules do you currently have in place from the internet zone to your local zone? Have you looked at these requests as they enter your firewall using a packet sniffer (tcpdump -ni dst host 10.1.1.0/24)? If the above produces no output while your local systems are logging DROPs, then the problem is on your own firewall. > > Also I have IPV6 disabled. Frontier doesn't support it and I've made > several failed attempts to tunnel it. Assuming I have it turned off in > shorewall.conf and in sysctl.conf net.ipv6.conf.all.disable_ipv6 = 1 > net.ipv6.conf.default.disable_ipv6 = 1 > > ... am I good there? Yes. > > I can't exclude all public IPs as remote VPN clients will be coming in > from all directions. They'll be connecting to the public IP of the > router, which then port-forwards that port to the WireGuard server > inside the LAN. > -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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] New reserved zone-name in "policy"
On 1/20/19 11:45 AM, ObNox wrote:
> Hi,
>
> I deal with a lot of zones and have strict policies to not let zones
> talk to each other by default.
>
> This brings a bit of lack of readability in the "policy" file, like :
>
> z1,z2,z3,z4,z5 { dest=z1,z2,z3,z4,z5+ policy=REJECT loglevel=info }
>
> Of course, here with the 2-letter example zones it's still readable but
> in the real world with 10+ 4-letters zones, that's another story :-)
>
> Would be possible to create a new reserved zone name which would regroup
> all user created zones excluding the $FW ?
>
> Maybe simply "zones" (plural) that would be : all minus $FW ?
>
> so one could have a new policy line :
>
> zones { dest=zones+ policy=REJECT loglevel=info }
>
> which would bring 2 benefits :
>
> 1/ Readability of course
>
> 2/ Nothing to worry about when a new zone is created, it would be
> included in the next "reload" command without having to add it twice here
>
> To further extend the concept, one could add exclusions for the typical
> case "I want all zones except these", like : zones[!z1,z2]
>
> I think about the "net" zone to obviously exclude :
>
> zones!net { dest=zones+!net policy=REJECT loglevel=info }
>
> What do you think ?
>
The current convention in the rules file is that all- represents all
zones except $FW.
-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
___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] martian source through VPN
On 1/21/19 6:36 AM, Alex wrote: > Hi, > > I have a fedora29 system with shorewall-5.2.0.4 and trying to add road > warriors through the VPN from a similar system with fedora29 and > shorewall-5.2.0.4 with a dynamic IP. > > [159401.601943] IPv4: martian source 192.168.1.2 from 192.168.6.1, on dev br0 > [159401.601959] ll header: : 0c c4 7a a9 18 de a4 15 88 a9 30 > b7 08 00..z...0... > > I've set up 192.168.1.0/24 and 192.168.6.0/24 in the vpn zone in hosts. > > I'm not sure which config settings to include here in the message > body, so thought I would include "shorewall dump" for both systems. > I'm hoping someone can help me identify the issue. > > # VPN server > https://pastebin.com/70zAaW0u > > # road warrior client > https://pastebin.com/AFGMtsWK > The problem is that eth1 is associated with 192.168.6.0/24, but a packet with source IP 192.168.6.1 is being received through br0. On the VPN client, the loopback interface has been assigned that IP address with is a duplicate of the IP address of eth1 on the server. -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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] shorewall mark and several providers
On 1/24/19 3:13 AM, Vieri Di Paola wrote: > Hi, > > I'm trying to clear up my mangle configuration regarding packet > marking because it doesn't seem to be working quite as I expect it to. > > My LAN host at 10.215.144.48 is accessing Internet via a shorewall > gateway with a MARK(1) action. Provider 1 (mark 1) is supposed to be > accessed through interface ppp1. > > I put the following line both at the top and bottom of the mangle file > (just in case): > > MARK(1) 10.215.144.48 0.0.0.0/0 all > > After reloading I tried to access https://www.iplocation.net/ from the > lan host at 10.215.144.48. > However, I could not read ppp1's public IP address but that of ppp2 (I > cleared the client browser's cache). > In fact, I could run tcpdump on the shorewall gateway to see how the > traffic was flowing through ppp2 instead of ppp1: > # tcpdump -n -i ppp2 host 107.154.118.114 > IP 79.148.120.225.62087 > 107.154.118.114.443: Flags [P.], seq > 3281967082:3281967487, ack 1044905512, win 260, length 405 > > I know there's the following action in between: > MARK(2):P 10.215.144.0/23,10.215.246.0/23,10.215.248.0/24 > However, I take it the other should prevail. > > The shorewall dump while connecting from 10.215.144.48 to > 107.154.118.114:443 through ppp2 instead of ppp1 is here: > https://drive.google.com/file/d/1SfWqdLPz2zbdJnRcBzN5K94qYChGz_F3/view?usp=sharing > > Any ideas? > Looks like the one at the end of the file is marking in the FORWARD chain, not in the PREROUTING chain. As you point out, the one at the front of the file is useless, as it is superseded by the /23 rule. There is also another entry for that source IP in the file, but it only deals with DEST=192.168.92.1. -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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] Exclusions
On 1/24/19 6:50 AM, C. Cook wrote: > > Strangers are still getting in to the interior of my network! How is > this possible? > > Wed Jan 23 15:28:18 2019] net-fw DROP IN=wlp3s0 OUT= > MAC=34:02:86:43:de:1f:52:54:00:3e:56:2a:08:00 SRC=95.163.255.192 > DST=10.2.10.2 LEN=60 TOS=0x00 PREC=0x00 TTL=45 ID=28760 DF PROTO=TCP > SPT=60772 DPT=80 WINDOW=29200 RES=0x00 SYN URGP=0 OPT > (020405B40402080AAC0174E601030307) ... > [Wed Jan 23 15:29:04 2019] net-fw DROP IN=wlp3s0 OUT= > MAC=34:02:86:43:de:1f:52:54:00:3e:56:2a:08:00 SRC=95.163.255.181 > DST=10.2.10.2 LEN=60 TOS=0x00 PREC=0x00 TTL=45 ID=42741 DF PROTO=TCP > SPT=60561 DPT=80 WINDOW=29200 RES=0x00 SYN URGP=0 OPT > (020405B40402080AAC0228C001030307) > I can't possibly guess without seeing a dump from the main Shorewall box. -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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] A big thank you!
On 1/25/19 3:48 AM, Kevin Olbrich wrote: > Hi! > > I want to say thank you to all involved in the project (development, > debug, etc.)! > Especially Tom, who seems to work a lot on Shorewall to make it even > better with each update. > > Many projects that I lead use shorewall, routers as well as servers > (must be about thousand?). > It is stable, reliable and easy to automate because of the config structure. > > Shorewall is great software! > > Thank you and have a good weekend! > Thanks Kevin!! -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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
[Shorewall-users] Shorewall 5.2.3 Beta 1
Shorewall 5.2.3 Beta 1 is now available for testing. New Features: 1) Zone exclusion (e.g., "all!z2,z2,...") is now supported in the policy file. 2) With the availability of zone exclusion in the rules file, 'all[+]-' and 'any[+]-' are equivalent to 'all[+]!$FW' and 'any[+]!$FW' respectively. Beginning with this release, the former are deprecated in favor of the latter and will result in a warning message, if used. 3) Internal documentaton of the undocumented 'test' parameter to compiler.pl has been added (it is used by the regression test library to suppress versions and date/times from the generated script). 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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] martian source through VPN
On 1/28/19 6:48 AM, Alex wrote: > Hi, > >>> The problem is that eth1 is associated with 192.168.6.0/24, but a packet >>> with source IP 192.168.6.1 is being received through br0. On the VPN >>> client, the loopback interface has been assigned that IP address with is >>> a duplicate of the IP address of eth1 on the server. >> >> I think I've fixed the martian problem, but I still can't reach one >> side of the VPN from the other and vice-versa. >> >> Just to summarize from a few days ago: >> >> 192.168.11.0/24 -- -- -- 192.168.1.0/24 >> >> VPN1 is a dynamic IP (currently 68.192.251.223) with a freedns >> hostname. VPN2 has a static IP (68.199.193.42). I'd like to be able to >> reach hosts on either side, as well as the VPN hosts themselves. >> >> Currently it doesn't appear that I can reach any host from any other >> host at all. > > I don't understand why shorewall isn't building the rules necessary > for packets to pass from one internal network with private IPs to the > virtual interface with private IPs on the other endpoint: > > On orion (68.199.193.42) > src 192.168.1.0/24 dst 192.168.11.0/24 uid 0 > dir out action allow index 8953 priority 1042407 ptype main > share any flag (0x) > lifetime config: > limit: soft (INF)(bytes), hard (INF)(bytes) > limit: soft (INF)(packets), hard (INF)(packets) > expire add: soft 0(sec), hard 0(sec) > expire use: soft 0(sec), hard 0(sec) > lifetime current: > 0(bytes), 0(packets) > add 2019-01-28 02:53:05 use 2019-01-28 09:46:46 > tmpl src 68.199.193.42 dst 68.192.251.223 > proto esp spi 0x(0) reqid 16389(0x4005) mode > tunnel > level required share any > enc-mask auth-mask comp-mask > > $ ping 192.168.11.1 > PING 192.168.11.1 (192.168.11.1) 56(84) bytes of data. > From 192.168.1.1 icmp_seq=1 Destination Host Unreachable > > On orion (68.199.193.42): > [393874.843186] FORWARD REJECT IN=eth1 OUT=br0 > MAC=0c:c4:7a:a9:18:df:4c:ed:fb:bb:47:93:08:00 SRC=192.168.1.7 > DST=192.168.11.1 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=47549 DF > PROTO=ICMP TYPE=8 CODE=0 ID=26710 SEQ=2258 > > As explained in Shorewall FAQ 17, when packets are dropped/rejected in the FORWARD chain, it means that either the SOURCE or the DEST does not fall into any zone. In this case, the DEST is not in any zone (192.168.11.0/24) does not appear anywhere in the ruleset). -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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] martian source through VPN
On 1/28/19 12:53 PM, Alex wrote: > Hi, > >>> $ ping 192.168.11.1 >>> PING 192.168.11.1 (192.168.11.1) 56(84) bytes of data. >>> From 192.168.1.1 icmp_seq=1 Destination Host Unreachable >>> >>> On orion (68.199.193.42): >>> [393874.843186] FORWARD REJECT IN=eth1 OUT=br0 >>> MAC=0c:c4:7a:a9:18:df:4c:ed:fb:bb:47:93:08:00 SRC=192.168.1.7 >>> DST=192.168.11.1 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=47549 DF >>> PROTO=ICMP TYPE=8 CODE=0 ID=26710 SEQ=2258 >>> >> As explained in Shorewall FAQ 17, when packets are dropped/rejected in >> the FORWARD chain, it means that either the SOURCE or the DEST does not >> fall into any zone. In this case, the DEST is not in any zone >> (192.168.11.0/24) does not appear anywhere in the ruleset). > > The 192.168.11.0/24 network is behind the other endpoint (remote) > gateway. I need to have that network listed in the local gateway's > hosts file? How do I determine which interface they should be bound to > in interfaces? br0 is the external interface on the local gateway. Since the subnet is remote, it should be associated with br0. > > # shorewall show zones > Shorewall 5.2.0.4 Zones at orion.inside.example.com - Mon Jan 28 > 15:53:11 EST 2019 > > fw (firewall) > vpn (ipv4) > ext (ipv4) >br0:0.0.0.0/0 > int (ipv4) >eth1:0.0.0.0/0 > dmz (ipv4) > wyck1 (ipv4) >br0:192.168.11.0/24 > wyck2 (ipv4) >br0:192.168.10.0/24 That shows NO ipsec4 zones! Since you are using Libreswan, your remote and local VPN zones must be of that type. > > I'm also confused on which document I'm supposed to be following. This > one says it was last updated in Jun, 2018, but only references kernel > 2.6. I'm of course using kernel-4.19. I'm assuming I also follow that > document? > http://shorewall.net/VPNBasics.html > > Does any of this configuration change since I'm using libreswan > instead of openvpn? libreswan does not create a tun or ppp interface. > You should be using http://www.shorewall.org/IPSEC-2.6.html The reason that the article mentions kernel 2.6, is that the entire kernel and user space implentation of IPSEC changed in that release. -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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] Packet Routing
On 1/29/19 9:22 AM, C. Cook wrote: > Something is wrong with packet routing in WireGuard. My outgoing > channel to AzireVPN works fine (the whole LAN is routed through it) but > the incoming channel can never complete the connexion handshake. > > Incoming is a separate channel with separate interface and port. It's > for remote phone, laptop, etc. > > When I take down the outgoing channel, incoming then works fine! Put > outgoing back up and incoming stops again. > > With outgoing up, I see Shorewall DROPs saying net-outWG with UDP inWG > port. So incoming WG packets to net are getting sent right back out > outWG interface. I figured this must be because of this routing rule: > > 10.2.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 > > 10.2.1.0/24 is for the LAN and 10.2.3.0/24 is internal to WG. > > So in snat I changed the rule to: > > MASQUERADE 10.2.1.0/26 outWG-se1 > > ... and changed the phone to 10.2.3.70 so it shouldn't be masqueraded > back out and hopefully will go to the WH interface with this routing rule: > > 10.2.3.0 0.0.0.0 255.255.255.0 U 0 0 0 inWG > > > TBH I don't know why the phone would be in 10.2.1.0 since I haven't > assigned it that IP anywhere. All I know for sure is that when I take > down the outgoing channel, incoming then works. Dump sent to Tom. > As far as I can see, this issue has nothing to do with Shorewall. I suggest that you contact the WG folks. -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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
