I have a VPN interface wg0. I also have zones vpn[1-12].
Is there any way to specify a rule that includes all vpn zones (or wg0
interface) without having to list them individually (and keep the list
updated as new zones are added)?
Cheers,
b.
signature.asc
Description: This is a digitally
On Tue, 2022-02-08 at 10:36 +0200, Tuomo Soini wrote:
>
> I'll test the patch on rhel7 based system and we'll see if that works
> there - I don't think there is any older supported distro out
> there...
Any result with this? Can we go ahead with the proposed MR?
Cheers,
b.
On Sun, 2022-02-06 at 10:58 -0500, Brian J. Murrell wrote:
>
>
> Well, it is, in that shorewall is using obsoleted interfaces.
There is now an MR at
https://gitlab.com/shorewall/code/-/merge_requests/5 to migrate to
newer, supported interfaces.
On Thu, 2022-02-03 at 23:38 +0100, Benny Pedersen wrote:
> On 2022-02-03 22:31, Brian J. Murrell wrote:
>
> > Is it really possible that Socket6::gethostbyname2 is not implemented
> > on a modern and recent distro such as Fedora?
>
> yes
Well, it seems that the get
With Shorewall6 5.2.8 on Fedora 35, I am getting:
Socket6::gethostbyname2 not implemented on this architecture at
/usr/share/perl5/vendor_perl/Shorewall/IPAddrs.pm line 512, <$currentfile> line
37.
Shorewall6 has worked fine in the past, for a very long time.
Is use of Socket6::gethostbyname2
On Wed, 2022-01-12 at 18:59 -0600, Justin Pryzby wrote:
>
> You need to make sure the reply is coming by way of the shorewall
> system.
> Which can then apply SNAT rules.
Yes, I was able to solve the problem with the following in the snat
file:
MASQUERADE - br-lan
Looks like Google has upped the ante with Chromecasts and it's no
longer sufficient to just block external DNS queries and expect the
Chromecast devices to fall-back to the DHCP supplied local DNS
resolvers.
Looks like we are going to have to up the game to redirecting DNS
requests to the
On Mon, 2020-04-27 at 11:24 -0400, Brian J. Murrell wrote:
> If I have a bunch of zones defined:
>
> vpn1 ipv4
> vpn2 ipv4
> vpn3 ipv4
>
> and hosts for the zones:
>
> vpn1 tun0:+vpn1_set
> vpn2 tun0:10.75.23.0/24,+vpn2_set
> vpn3 tun0:+vpn3_set
>
If I have a bunch of zones defined:
vpn1ipv4
vpn2ipv4
vpn3ipv4
and hosts for the zones:
vpn1tun0:+vpn1_set
vpn2tun0:10.75.23.0/24,+vpn2_set
vpn3tun0:+vpn3_set
Is there any way to write a single rule that covers all of those
zones/hosts as a source?
Something like:
On Mon, 2020-02-24 at 16:28 -0500, Brian J. Murrell wrote:
>
I wonder if there is any thought or comment on my proposals below?
> Would it be infeasible to just leave the mangle table alone if there
> is
> no Shorewall configuration that needs to use it?
>
> Or alternatively
On Mon, 2020-02-24 at 12:27 -0800, Tom Eastep wrote:
>
> You apparently have FORWARD_CLEAR_MARK=Yes or it is defaulting to
> Yes.
Indeed. That was it.
> Set it to No to be sure.
Done.
mangle table is empty now, but is [re-]set to empty by Shorewall.
> You can try creating a capabilities
Is there any option to have shorewall[6] completely disregard the
mangle table?
I've pared down my previous multi-provider config such that all I am
getting in my mangle table is:
Chain PREROUTING (policy ACCEPT 41 packets, 3740 bytes)
pkts bytes target prot opt in out source
On Sun, 2019-03-31 at 10:04 -0700, Tom Eastep wrote:
>
> Brian,
Hi Tom,
> The lack of macro support for a particular application scenario
> generally means that no one with the ability to test that scenario
> has
> stepped up to produce such a macro.
Fair enough.
> If you want to test, then:
I'm noticing a lack of macro support for SIP over TCP. Is that
intentional (i.e. because there is something inherent about SIP over
TCP not working) or just oversight?
In my case, my primary interest is IPv6, so just conntracking, but
there will be times I suppose when I want it over IPv4 also
On Mon, 2019-02-25 at 07:14 -0500, Brian J. Murrell wrote:
>
> On the "lite" machine I have
> 5.2.0.4.
~sigh~ Which is one single bugfix release behind what I need.
Cheers,
b.
signature.asc
Description: This is a digitally
On Wed, 2018-08-01 at 14:27 -0700, Tom Eastep wrote:
>
So, getting back to this...
> Any results with this patch? I would like to include this fix in
> 5.2.0.5.
On the shorewall (i.e. not the "lite") machine, I have 5.2.0.5
installed that includes this patch. On the "lite" machine I have
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
On Thu, 2018-09-06 at 20:11 +0100, Tom Eastep wrote:
>
> I suspect that is exactly what they are. Their logging was previously
> suppressed by the NotSyn action invoked out of the Drop action.
The NotSyn action did not take into account current (or recent) TCP
connections though did it? Was it
I'm noticing an increase in the following sort of packet drop logs from
Shorewall:
Sep 2 17:08:56 gw kernel: [28287.557719] Shorewall:net2fw:DROP:IN=eth0.2 OUT=
SRC=4.24.10.6 DST=7.1.2.1 LEN=102 TOS=0x00 PREC=0x00 TTL=237 ID=57081 DF
PROTO=TCP SPT=6667 DPT=51394 WINDOW=110 RES=0x00 ACK PSH
On Tue, 2018-07-31 at 10:48 +0200, Matt Darfeuille wrote:
>
> The attached patch (MUTEX_ON_TAKE1.patch) includes:
> - MUTEX_ON.patch
> - MUTEX_ON1.patch
> - The above correction (changing 'openwrt' to 'lockbin')
> - My take on fixing the above error ( "/sbin/shorewall-lite: line 14:
> -n: not
On Sat, 2018-07-28 at 08:03 -0700, Tom Eastep wrote:
> diff --git a/Shorewall-core/lib.common b/Shorewall-core/lib.common
> index 205fc705f..bbebf0936 100644
> --- a/Shorewall-core/lib.common
> +++ b/Shorewall-core/lib.common
> @@ -751,6 +751,8 @@ mutex_on()
>
On Sat, 2018-07-28 at 15:04 +0200, Matt Darfeuille wrote:
>
> Tom, with MUTEX_ON.patch applied, on LEDE '--pid' is not available or
> is
> it done on purpose?:
>
> root@LEDE:~# ps --pid
> ps: unrecognized option: pid
> BusyBox v1.25.1 () multi-call binary.
>
> Usage: ps
>
> Show list of
On Thu, 2018-07-26 at 08:51 -0700, Tom Eastep wrote:
>
> Brian,
Hi Tom,
> Can you point me to online documentation that describes how this
> 'lock'
> utility is supposed to work?
It's a busybox applet added to busybox by OpenWRT. Here's the source
for it:
On Thu, 2018-07-26 at 05:48 +0200, Matt Darfeuille wrote:
>
> As illustrated by this lingering thread, issues that are only present
> on
> one platform makes me moved away from OpenWRT/LEDE.
The platform is not the problem. The platform is just providing the
tools.
Or are you suggesting that
On Mon, 2018-07-16 at 07:12 -0400, Brian J. Murrell wrote:
>
> I think I finally do have the required versions now, yes?
Am I correct about having the required versions now?
> However, as you can see above, we still have stale/orphan
> locks/processes hanging around.
If so, any ide
On Sat, 2018-06-30 at 08:25 -0700, Tom Eastep wrote:
>
> If 'shorewall show version' returns '5.2.0', then you do not have the
> fix on your administrative system. If it returns '5.2.0.1', then you
> do
> have the fix.
$ shorewall show version
ERROR: Cannot read /etc/shorewall/shorewall.conf!
On Thu, 2018-04-12 at 09:10 -0700, Tom Eastep wrote:
>
> No -- it requires the firewall script to be compiled with the fix, as
> well as having the fix installed on the shorewall[6]-lite firewall.
# rpm -q shorewall
shorewall-5.2.0-0.01.fc28.noarch
# opkg info shorewall-lite
Package:
Hi,
Since upgrading from 5.1.12 to 5.2.0 on the machine that I build
firewall rulesets for my shorewall-lite-running-router, I have seen a
massive increase in RST and FIN packets being logged such as:
Jun 15 15:30:02 gw kernel: [895825.983756] Shorewall:net2fw:DROP:IN=eth0.2 OUT=
MAC=...
On Tue, 2018-06-19 at 09:39 -0700, Tom Eastep wrote:
>
> It is in 5.2.0
Hrm. I had to patch /usr/share/shorewall/action.IfEvent by hand with
5.2.0.
> Does your distro install the common Shorewall files in
> a directory other than /usr/share/shorewall/?
I don't believe so, no:
$ rpm -qf
On Fri, 2018-04-13 at 09:08 -0700, Tom Eastep wrote:
>
> In the process, I discovered a bug in the 'reset' logic of IfEvent()
> when 'dst' is specified; that bug is corrected by the attached patch:
>
> patch /usr/share/shorewall/action.IfEvent < IfEvent.patch
I see this is missing from
On Mon, 2018-06-11 at 08:39 -0700, Tom Eastep wrote:
>
> Okay. Provided that your firewall is not an IPSEC endpoint, please
> try
> setting the ZERO_MARKS option in shorewall6.conf.
Assuming you mean setting the ZERO_MARKS option to Yes, that doesn't
resolve the issue either.
Cheers,
b.
On Thu, 2018-06-07 at 08:37 -0700, Tom Eastep wrote:
>
> In place of your ip6tables command, please try this one:
>
> ip6tables -t mangle -I OUTPUT -p icmpv6 --icmpv6-type 136 -j RETURN
>
> Does that also solve the issue?
No, it doesn't I'm afraid.
Cheers,
b.
signature.asc
Description: This
On Mon, 2018-03-26 at 19:18 -0400, Brian J. Murrell wrote:
> I have this strange problem where ICMP6 router advertisement
> responses
> are not making out to their requester.
I have narrowed this down to packet connmarking in the mangle table.
First, my mangle table:
Chain PREROUTIN
On Tue, 2018-06-05 at 10:00 +0300, Tuomo Soini wrote:
>
> That's huge patchset which is already in upstream. Upgrade to LEDE
> and
> you should be ok.
I'm already on the latest LEDE (it's actually called OpenWRT now/again)
stable (17.01.4) but 17.01.5 is in the pipeline and I'd like to make
sure
On Mon, 2018-06-04 at 23:51 +0300, Tuomo Soini wrote:
>
> Update to centos 7 latest kernels (3.10.0-862.*.el7) will fix the
> issue.
My Shorewall gateway is OpenWRT, so identifying particular patches
would still be most useful, so that I get patch and build locally as
well as get them upstream.
On Tue, 2018-03-27 at 12:44 -0700, Tom Eastep wrote:
>
> I've asked the maintainer of Foobar Linux, a RHEL-based distribution,
> for details.
Did you get any response to this query?
> He found a neighbor discovery cleanup patch from way back
> in 2014 that solved the problem for him.
This
Damn. I knew I shouldn't have hit send so quickly...
On Fri, 2018-04-13 at 09:08 -0700, Tom Eastep wrote:
> diff --git a/Shorewall/Actions/action.IfEvent
> b/Shorewall/Actions/action.IfEvent
> index 5f245ed22..64cbb8e25 100644
> --- a/Shorewall/Actions/action.IfEvent
> +++
On Fri, 2018-04-13 at 09:08 -0700, Tom Eastep wrote:
>
> I've tested the following:
>
> #
> #
> # IRC
> #
> SetEvent(IRC) { SOURCE=loc,apps,
> DEST=net,
I'm having trouble wrapping my mind around what the Events
configuration looks like for the use-case of an IRC server wanting to
reach the ident server of an IRC client on connect.
I.e. If IRC client C makes a connection to IRC server S on port 6667,
then IRC server S is allowed to connect from
On Wed, 2018-04-11 at 19:09 -0700, Tom Eastep wrote:
>
> Did you read the 5.1.12.3 release notes?
Ahhh. No. I read the 5.1.12 release notes but didn't go any further
when I didn't see it. Should have really.
> 1) Previously, the Shorewall[6][-lite] lock file was not always
> released
On Wed, 2018-02-28 at 08:51 -0800, Tom Eastep wrote:
>
> There are quite a few, but they are only an issue for people who have
> to
> rely on the obscure 'lock' utility. The rest just get a 'stale lock
> file
> removed' message the next time that they run shorewall[6][-lite].
> I'll
> try to come
On Tue, 2018-03-27 at 12:44 -0700, Tom Eastep wrote:
>
> I've asked the maintainer of Foobar Linux, a RHEL-based distribution,
> for details. He found a neighbor discovery cleanup patch from way
> back
> in 2014 that solved the problem for him.
Do we have a copy of this patch or know where it is
On Tue, 2018-03-27 at 10:18 -0700, Tom Eastep wrote:
>
> Which kernel version?
4.4.92 on LEDE 17.01.4.
> A number of us have seen this problem (it
> currently exists in RHEL 7)
Who backport *tons* of stuff to their "3.10.0" kernel.
> which is traceable to a kernel issue.
Do you have a link
I have this strange problem where ICMP6 router advertisement responses
are not making out to their requester.
My OUTPUT chain looks like:
Chain OUTPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
49623 4936K accounting
On Wed, 2018-02-28 at 08:35 -0800, Tom Eastep wrote:
>
> The documentation for the 'blacklist' command has always stated that
> it
> requires 'DYNAMIC_BLACKLIST='ipsec,...' to be available, and
> processing
> of the 'blacklist' command in 5.0.14.1 and 5.1.10.2 is identical.
>
> With
On Wed, 2018-02-28 at 08:51 -0800, Tom Eastep wrote:
>
> There are quite a few, but they are only an issue for people who have
> to
> rely on the obscure 'lock' utility.
It's from busybox, FWIW.
> The rest just get a 'stale lock file
> removed' message the next time that they run
I'm not really sure when this started but the only change to my
configuration recently was an upgrade of shorewall on the "master" from
5.0.14.1 to 5.1.10.2. In any case, I seem to be getting this now:
# /usr/sbin/shorewall-lite blacklist 185.170.42.18
ERROR: The blacklist command is not
On Fri, 2018-01-12 at 07:09 -0500, Brian J. Murrell wrote:
> I frequently get the following situation on my shorewall-lite
> machine,
> typically right after boot, where "shorewall-lite restart" has been
> run
> many times, overlapping even, I am sure as interfa
On Mon, 2018-01-15 at 06:52 +0100, Matt Darfeuille wrote:
>
> Ok -- You seem to be fixated on not restricting the use of the lock
> utility.
Please don't be so defensive. That's not it at all. I am trying to
debug a problem here and in trying to do that I am trying to understand
the nature of
On Sun, 2018-01-14 at 17:06 +0100, Matt Darfeuille wrote:
>
> The code is only working and tested on OpenWRT.
Which is my platform.
> Lock on OpenWRT has limited functionalities.
Such as what? And why would it being limited (only) on OpenWRT mean
you that make it's use exclusive to OpenWRT.
On Sun, 2018-01-14 at 16:46 +0100, Matt Darfeuille wrote:
>
> If you are not on OpenWRT you may want to apply the attached patch.
So, don't use "lock" on platforms other than OpenWRT? But it's Ok to
use any of the other locking method on non-OpenWRT machines?
Why are you promoting the use of
I frequently get the following situation on my shorewall-lite machine,
typically right after boot, where "shorewall-lite restart" has been run
many times, overlapping even, I am sure as interfaces are brought up,
etc.:
# ps -ef | grep shorewall
root 1094 1 0 Jan11 ?00:00:01 lock
On Tue, 2018-01-02 at 11:17 -0800, Tom Eastep wrote:
>
> The 'blacklist' command accepts subnets already.
Oh. Wow. So it does. My list is just so /32 heavy that I didn't see
the
signature.asc
Description: This is a digitally signed message part
I wonder what the thoughts are on being able to blacklist subnets using
shorewall blacklist, specifically with ipsets.
Of course subnets could be expanded and applied at a list of hosts
using shorewall blacklist, but surely there is a performance issue with
that, no?
Cheers,
b.
signature.asc
When I try to load a ruleset to a remote shorewall[-lite] instance with
DYNAMIC_BLACKLIST=ipset,disconnect
I get an error:
ERROR: The 'disconnect' option requires that the conntrack utility be
installed
This error would make sense in the non-remote-reload situation but
doesn't in the
I currently have a workflow set up here where any time I have an IP
address that I want blocked/blacklisted I add it to an ipset which is
referenced in the blrules file.
After adding a new entry to an ipset I run:
# /etc/shorewall-lite/state/firewall run save_ipsets
On Wed, 2017-12-20 at 10:20 -0800, Tom Eastep wrote:
> On 12/20/2017 09:33 AM, Brian J. Murrell wrote:
> >
> > Compiling /etc/shorewall6/gw-Reboot/rules...
> >ERROR: Unknown destination zone (&{INT_SRV_ALL_DSTS})
> > /usr/share/shorewall/macro.Auth (line 9)
&g
Trying to use some of the techniques explained on:
http://shorewall.net/configuration_file_basics.htm
am I misunderstanding run-time address variables?
I have /etc/shorewall6/init:
INT_SRV_ALL_SRCS=$(ip -6 addr ls br-lan | sed -n -e '/fe80::/d' -e '/fd31:/d'
-e '/::1\/128/d' -e
Hi,
I want to copy a policy on an existing shorewall[6]-lite router to a
new router so that the new router, when turned on, picks up exactly
where the old router left off.
On the old (LEDE) router, the existing policy state lives in
/etc/shorewall[6]-lite/state/ as such:
# ls -l
On Wed, 2017-11-29 at 12:50 -0800, Tom Eastep wrote:
>
> You need a minimum version (5.0.13) to be able to specify 'balance'
> on
> more than one provider.
Hrm. My machine has 5.0.14.1 and had that version when I posted
https://sourceforge.net/p/shorewall/mailman/message/36115498/
> Yes -- if
On Wed, 2017-11-29 at 09:54 -0800, Tom Eastep wrote:
>
> No. But I would try specifying 'balance'
But I need a minimum version of Shorewall for balance, per
https://sourceforge.net/p/shorewall/mailman/message/36115613/, right?
If so, what's that minimum?
> (or 'primary', if your version
>
I have a shorewall6/shorewall6-lite installation where the router has
multiple IPv6 connections to the Internet. Accordingly I have
configured the providers file[1].
When I do have the providers file present with the following contents:
CGCO1 0x100 - eth0.2 -
On Sat, 2017-11-25 at 10:54 -0800, Tom Eastep wrote:
>
> That is correct. I do a similar thing here; by using source-address
> routing rules, my DMZ uses one interface and the local LAN uses the
> other.
Not sure I'm following but you are making me curious.
Only if you care to, could you expand
On Sat, 2017-11-25 at 10:07 -0800, Tom Eastep wrote:
>
> Then why not make one the primary and the other the fallback?
>
So that does seem to resolve the reloading problem and having to flush
that table before reloading. So that's great. Thanks!
But it's not really doing/enforcing
On Tue, 2017-11-14 at 16:31 -0800, Tom Eastep wrote:
>
> This is a known problem -- see the known problems section of current
> releasenotes. Basically, 'balance' doesn't work with IPv6 because the
> above routes are not balanced routes but rather two separate routes
> with
> different metrics.
Hi.
When I try to apply a policy a second time (even without changing it)
from a shorewall6 5.0.14.1 machine to a remote shorewall6-lite 5.1.8
machine I get an error:
Initializing...
Adding Providers...
RTNETLINK answers: File exists
ERROR: Command "/usr/bin/ip -6 route replace default scope
On Tue, 2017-11-14 at 13:38 -0800, Tom Eastep wrote:
>
> I don't understanding how you are falling into the case statement if
> you
> are running under uid 1001.
Manual patch application fubar. :-( When I fix my code to reflect the
patch correctly, it does work. Sorry for the noise.
Cheers,
On Tue, 2017-11-14 at 08:34 -0800, Tom Eastep wrote:
> + case "$IP" in
> + */*)
> + if [ ! -x "$IP" ] ; then
> + fatal_error "The program specified in IP ($IP) does not
> exist or is not executable"
> + fi
This results in
On Tue, 2017-11-14 at 08:34 -0800, Tom Eastep wrote:
>
> The attached patch
Pretty sure I understand but please allow me to clarify... this is a
patch to the shorewall on the local system, not the shorewall6-lite
system, yes?
> will allow you to specify IP (and SHOREWALL-SHELL) in
> the remote
I'm trying to deploy a remote policy with shorewall[6]-lite to a LEDE
17.01.4 router running shorewall[-lite] 5.1 from a host running
shorewall 5.0.
The problem is that on LEDE now, they supply a busy-box "ip" applet
which is not quite featured enough for shorewall:
Adding Providers...
ip:
On Tue, 2016-12-06 at 08:21 -0800, Tom Eastep wrote:
>
> This is a common problem with UDP. A packet arrives on tun0 before
> the
> DNAT rule is in place, and the resulting conntrack table entry
> persists so long as matching packets continue to arrive. You can
> remove the offending entry using
On my shorewall router there is traffic entering on the tun0 interface
and exiting the br-lan interface. Any packets entering from tun0 with
a destination port of 23768 on a machine on the br-lan interface should
be port-mapped to 5060.
I have the following in my shorewall rules file:
DNAT
On Fri, 2016-12-02 at 12:30 -0800, Tom Eastep wrote:
>
> You reported that *restore* returns an error, not *reload*, did you
> not?
Doh! You are correct. Too many "re-"s I guess.
So typically reload is preferable to restart, correct? Will reload
work even with SAVE_IPSETS?
Looking more
On Fri, 2016-12-02 at 09:40 -0800, Tom Eastep wrote:
>
> With RESTART=restart,
So, on that note, it seems to me that RESTART=reload and
SAVE_IPSETS=Yes should be an error.
But RESTART= still doesn't alter the fact that "shorewall* reload"
won't work with SAVE_IPSETS=Yes. Should reload actually
Unfortunately it doesn't seem that when a shorewall-lite restore fails
due to ipsets being present, that shorewall-lite exits with an error:
# /usr/sbin/shorewall-lite restore
Restoring Shorewall Lite...
Initializing...
Processing init user exit ...
Creating any undefined ipsets...ipset v6.24:
On Wed, 2016-11-30 at 13:58 -0800, Tom Eastep wrote:
>
> This is the same behavior as on Shorewall and Shorewall6. If you have
> SAVE_IPSETS configured and you want to restore an old config with the
> firewall running,
Is the point here to prevent overwriting the current ipsets with old
ones?
>
Hi,
When I try to do a restore action with shorewall-lite 5.0.13.4 I get:
# /usr/sbin/shorewall-lite -qq restore
ipset v6.24: Element cannot be added to the set: it's already added
ERROR: Cannot restore /etc/shorewall-lite/state/restore-ipsets with
Shorewall running: Firewall state not
Is having to set STARTUP_ENABLED on the shorewall-lite side intended?
Seems to be a newish requirement and odd at that, on the shorewall-lite
end at least. The shorewall-lite.conf doesn't even have the header and
variable to set the way the shorewall.conf does.
Cheers,
b.
signature.asc
On Wed, 2016-11-09 at 10:25 -0800, Tom Eastep wrote:
> On 11/09/2016 08:29 AM, Tom Eastep wrote:
>
> >
> >
> > You *always* need SNAT on a router that can direct traffic to one
> > provider or another.
That seems a pity. It doesn't seem unreasonable that an RA could
include direction on how
On Tue, 2016-11-08 at 18:31 -0500, Brian J. Murrell wrote:
>
> Ahh. OK. I will see about getting an upgrade under way.
Done, and the IPv6 policy does load but I just want to confirm if the
routing is as expected. Given the providers:
CGCO1 0x100 - 6to4-c
On Tue, 2016-11-08 at 13:55 -0800, Tom Eastep wrote:
>
> The first isn't an issue -- the balance provider's default route is
> in
> the 'balance' table.
Ahhh. I missed the balance table in the routing policy DB.
> The second is solved by upgrading to 5.0.14[.1]. The early IPv6
> kernel
>
On Tue, 2016-11-08 at 08:16 -0800, Tom Eastep wrote:
>
> I'm surprised that this ever worked. The best way to resolve this
> issue is to switch your configuration to USE_DEFAULT_RT=Yes.
So, out of interest and reading that USE_DEFAULT_RT=No is deprecated, I
thought I would try this on my IPv4
I have a shorewall6/shorewall6-lite configuration that was working on
4.x that I am migrating to migrate to 5.0.8.2/5.0.13.4.
When I try to remote-reload I get an error:
...
Starting Shorewall6 Lite
Initializing...
Adding Providers...
RTNETLINK answers: File exists
ERROR: Command "ip -6
Greetings all...
Having upgraded my "control" station to F24 which has shorewall 5.0.8.2
on it it's failing to work with the shorewall-lite on my router which
is at 4.5.7:
Shorewall configuration compiled to /etc/shorewall/gw-BB/firewall
Copying /etc/shorewall/gw-BB/firewall and
On Wed, 2016-03-23 at 12:57 +0800, James Andrewartha wrote:
> On 23/03/16 01:49, Brian J. Murrell wrote:
> > I wonder if anyone has applied rate limiting on their Shorewall in
> > front of an Asterisk or other SIP server.
>
> I would suggest looking at http://www.fail2ban.o
I wonder if anyone has applied rate limiting on their Shorewall in
front of an Asterisk or other SIP server.
The basic problem is high-rate cracking attempts... people trying to
brute-force attack the server with registrations and/or SIP call
attempts.
While I've read about the RATE LIMIT column
On Thu, 2016-02-25 at 08:02 +, Simon Hobson wrote:
>
> Not really, in as much as the traffic has already arrived before you
> have the opportunity to control how much of it there is.
Right. But I can slow down TCP by dropping packets to which video
streaming services like Netflix adjust the
As we all know, one cannot really shape/limit inbound traffic other
than to "police" it. Or at least that was the state of things the last
time I was in this neighborhood. Maybe things have changed since then.
Ultimately, what I want to do is basically what T-mobile is doing with
their "Binge
On Wed, 2016-02-03 at 16:02 +0800, James Andrewartha wrote:
>
> You could have time-based rules in the mangle file to select the
> default
> provider.
Oh. Now that is an interesting solution. I had not considered that
one. I was focused on raw routing, not policy routing with marks.
I will
I have two providers, one is fast (with a bigger usage cap), one is
slow (with a smaller usage cap) so I generally default route through
the fast one as the dedicated primary route with the slow sitting back
as secondary (i.e. for just when the first one goes down, not round-
robin).
But the slow
On Sat, 2015-09-26 at 18:16 -0700, Tom Eastep wrote:
> I'm afraid that I'm not following you -- the only difference between
> Shorewall's IPv4 and IPv6 support in this area is that IPv4 supports
> multi-hop routes and IPv6 doesn't; and that's a kernel limitation.
It's not really a technical IPv4
On Sun, 2015-09-27 at 08:46 -0700, Tom Eastep wrote:
> Using SNAT and packet marking, you can do the same thing on your
> router
> with IPv6 as you can with IPv4, AFAIK.
Yes, I had considered that. But the idea of IPv6 eliminating NAT is so
magnificent. :-)
Cheers,
b.
signature.asc
On Sat, 2015-09-26 at 14:33 -0700, Tom Eastep wrote:
> Here is the way that I do it. My LAN has addresses in network
> 2001:470:b:787::/64.
> #NAME NUMBER MARKDUPLICATE INTERFACE
> GATEWAY
> OPTIONS COPY
> HE2 4 0x100 -
On Sat, 2015-09-26 at 19:30 +0100, Simon Hobson wrote:
> Brian J. Murrell <br...@interlinx.bc.ca> wrote:
>
> > ... there doesn't seem to be any mechanism in place in
> > Shorewall to ensure that packets from the LAN with a source IP
> > address
> > in ISP A's
So, back in they way old days when we used to use RFC-1918 address
space in LANs and NAT that at the router, the router was in a perfect
position to apply upstream (i.e. ISP) preference.
Not so much with IPv6.
Because each host in the LAN now has a fully routable IP address, and
multiple of them
When one has multiple upstream IPv6 (can happen with IPv4 also if you
happen to have routable IPv4 space in your LAN from your ISP rather
than NATting on a single address -- but this is probably pretty rare)
connections, there doesn't seem to be any mechanism in place in
Shorewall to ensure that
On Wed, 2015-08-19 at 11:08 -0700, Tom Eastep wrote:
Right -- and it isn't there when I compile this configuration:
shorewall trace -vvv check -r . | less
export COLORTERM='mate-terminal'
export
DBUS_SESSION_BUS_ADDRESS='unix:abstract=/tmp/dbus
On Wed, 2015-08-19 at 12:15 -0700, Tom Eastep wrote:
Note that the first entry in mangle creates tcpre rule 4!! Do the
same
thing searching for tcpre and see what is generating rules 1-3.
Ahhh! I forgot that tcrules plays a part in all of this. Indeed I had
to add 10.75.22.247 to the
Hi Tom,
I'm running shorewall 4.6.11.1 on Fedora 22 as a master for a router
running shorewall-lite. I'm doing transparent proxying per
http://shorewall.net/Shorewall_Squid_Usage.html#Local.
I have a providers entry of:
Squid 3 0x400 - br-lan 10.75.22.247
On Tue, 2015-06-16 at 16:41 -0700, Tom Eastep wrote:
Have you considered adding an 'unreachable' route for the ULA range in
shorewall6-routes?
Indeed and of course. :-) Or OpenWRT's routing configuration.
But I think my question was more about the greater issue of if
Source-Destination
1 - 100 of 373 matches
Mail list logo
