Hi,
Not sure about the log, but a quick workaround would be to add 172.26 as an
alias to the shorewall gateway.
On Wed, Oct 18, 2023, 15:09 David Watkins wrote:
> Hi,
>
> I'm a long time shorewall user, but with very basic skills, running a
> simple 2 port firewall between my ISP and a home
On Wed, Nov 9, 2022 at 8:15 AM Simon Matter wrote:
>
> > The Fortinet admin has set the following in his FW:
> >
> > set protocol 6
> > set timeout 28800
> ^
> What's this value exactly?
I don't have access to a Fortinet Fortigate system
Hi,
There are hosts in my LAN behind a Shorewall FW that need to keep
Oracle connections alive (tcp 1521) with other hosts that are behind a
remote Fortinet Fortiguard FW.
The Fortinet admin has set the following in his FW:
set protocol 6
set timeout 28800
My bad...
My custom script was actually calling "shorewall debug check"
explicitly. That's because it was for an older shorewall release.
I updated my custom script so it calls "shorewall check -D" instead.
Now I get useful output such as:
ERROR: Duplicate DEST (WHATEVER) in table (WHICHEVER)
According to https://shorewall.org/starting_and_stopping_shorewall.htm#Trace
it seems that the right command isn't "shorewall trace|debug whatever"
anymore but "shorewall whatever -D", eg. shorewall check -D.
That does give me a full log. However, when running "shorewall check"
the error message
Hi,
I eventually solved my problem. It was due to a wrong entry in the rules file.
I had something like:
$PROVIDER $DEST_IP_ADDR - ${IF_LAN}.111
$PROVIDER $DEST_IP_ADDR - ${IF_LAN}.112
where $PROVIDER, $DEST_IP_ADDR and ${IF_LAN} were the same.
The error message was not clear enough,
Hi,
I hit this error message on a shorewall check:
ERROR: Invalid command: debug
This happened only after I added some more lines in the routes file.
They all had the same syntax;:
$PROVIDER $DEST_IP_ADDR - ${IF_LAN}.111
What does "debug" refer to?
Thanks,
Vieri
On Wed, May 4, 2022 at 12:03 PM Tuomo Soini wrote:
>
> > May 4 08:04:22 fw1 kernel: FWGW:wan-lan1:DROP:IN=wan OUT=lan.1
> > MAC=ac:1f:6b:9b:85:06:30:85:a9:8e:b9:a0:08:00 SRC=23.200.66.154
> > DST=10.215.248.214 LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=38801 DF
> > PROTO=TCP SPT=443 DPT=64710
Hi,
I use these rules in the INVALID and NEW sections of the rules file:
FIN(ACCEPT) { SOURCE=all, DEST=all }
RST(ACCEPT) { SOURCE=all, DEST=all }
according to a previous mailing list post:
Hi,
What's the best way to translate these iptables rules to Shorewall?
iptables -I INPUT -m addrtype --dst-type LOCAL -m policy --pol ipsec
--dir in -j NFLOG --nflog-group 5
iptables -I OUTPUT -m policy --pol ipsec --dir out -j NFLOG --nflog-group 5
The idea is to be able to monitor IPSec
Hi,
I was wondering if the following hypothetical rule:
ACCEPT zone1,zone2,zone3:1.2.3.4 zone4 all
means that only host with IP addr. 1.2.3.4 in any of zone1, zone2 or
zone3 can access zone4
or it means that all hosts in zone1 and zone2 as well as the host with
IP addr. 1.2.3.4 in zone3 can
Is FTPS considered insecure?
proftpd example:
ServerName "MH FTP server"
ServerType standalone
DefaultServer on
AccessGrantMsg "User %u has successfully logged into MH FTP server."
RequireValidShell off
UseReverseDNS off
IdentLookups off
Port 0
UseIPv6 off
MaxInstances 30
Umask 022
PassivePorts
On Mon, Feb 28, 2022 at 12:05 PM Matt Darfeuille wrote:
>
> I'm not sure that this is the issue, but Teams requires lots of open
> ports to work.
> I had to open those for the Desktop edition.
True for the desktop version, but the web client only requires https
on tcp port 443.
Thanks,
Vieri
On Mon, Feb 28, 2022 at 12:24 PM Rodrigo Araujo wrote:
>
> I'd say the problem is on the host that might not have all packages updated,
> namely the ca-certificates (or equivalent) package. At a first glance it
> doesn't seem like a firewall problem.
>
> @Vieri, please try to do a yum/apt (or
On Mon, Feb 28, 2022 at 10:52 AM Simon Matter wrote:
>
> DONT_LOAD="nf_nat_sip"
>
> I don't remember exactly but I think I came to the conclusion that the SIP
> conntrack module doesn't hurt and therefore let it be loaded.
I will try to leave it as you did. I unloaded nf_nat_sip and left the
Hi,
Some hosts in the LAN are randomly unable to connect to external https
services. All conections are going through a Shorewall routing
firewall.
One host in the same vlan with src IP addr. 10.215.111.210 is properly
accessing the following site:
curl --verbose --head
Hi,
I'm trying to solve some possible SIP issues in my LAN, and I'd like
to temporarily disable SIP-related Linux kernel modules.
It seems that shorewall loads the modules according to the content of
/usr/share/shorewall/helpers. Instead of touching that file I'd rather
set DONT_LOAD in
Just in case someone comes across a similar issue, there was
absolutely nothing wrong with the shorewall router. The only problem
was with 3 specific hosts which were all HPE iLO 5 systems. I tried
arping to try to update their ARP caches as accessing them via ssh
didn't really give me any useful
On Tue, Jan 25, 2022 at 2:08 PM William Papolis wrote:
>
> I don’t want to diss on Shorewall, in a Shorewall forum
then please don't.
> Maybe there are reasons Shorewall is better? I don’t know what they are
Tom was -- I sure as hell miss him.
___
On Tue, Jan 25, 2022 at 1:21 AM William Papolis wrote:
>
> This isn't a "Shorewall" issue.
>
> It's an "IP ROUTING" issue.
>
> Look at my last response.
Shorewall also sets network system parameters such as arp filtering,
ip routing, etc.
So this could be a "Shorewall issue" because Shorewall
In the failing scenario where a host in vlan 1 with IP addr.
10.215.111.210 cannot ping a host in vlan 18 with IP addr.
10.215.144.251 this is what I see on the SW FW:
# tcpdump -n -i lan -e vlan and host 10.215.144.251
dropped privs to pcap
tcpdump: verbose output suppressed, use -v[v]... for
In the failing scenario where a host in vlan 1 with IP addr.
10.215.111.210 cannot ping a host in vlan 18 with IP addr.
10.215.144.251 this is what I see on the SW FW:
# tcpdump -n -i lan -e vlan and host 10.215.144.251
dropped privs to pcap
tcpdump: verbose output suppressed, use -v[v]... for
Thanks, Bill.
As shown in the dump, my Shorewall system is a router.
I think the problem may lie in routing rules/netmasks/ARP.
I have other hosts in the same vlans as in my first example that
perfectly reply to ICMP.
For instance, host in vlan 1 with IP addr. 10.215.111.210 can
successfully ping
Hi,
I'm puzzled as to why I cannot ping a host with IP addr.
10.215.144.251 from a host with IP addr. 10.215.111.210. They are two
different vlans, but traffic should be allowed.
The tcpdump on the FW shows that the ICMP replies are ot seen from FW
to lan.1. I just don't know why.
This is my
This issue has been fixed upstream.
Gentoo users can:
# emerge --sync
# emerge arptables
The arptables symlink to the legacy program should automatically be
there so no need to tamper with anything else.
Thanks
___
Shorewall-users mailing list
On Wed, Dec 1, 2021 at 1:27 PM Matt Darfeuille wrote:
>
> I just want to point out (1, 'ARPTABLES=').
As well as IPTABLES=, thanks.
Basically, in Gentoo if "nftables" is used the binaries will point to
xtables-nft-multi otherwise they will point to xtables-legacy-multi.
The problem is that on
On Wed, Dec 1, 2021 at 1:10 PM Benny Pedersen wrote:
>
> shorewall works in gentoo, there is no arptables-legecy in gentoo
> portage
I've been using Gentoo as a router for decades now so I know that
shorewall works there.
Except that on a new Gentoo system, it fails because it does not find
the
On Wed, Dec 1, 2021 at 1:10 PM Benny Pedersen wrote:
> emerge -aC arptables
> emerge -a iptables eselect-iptables
>
> then set the needed symlink with eselect
No need to set "-nftables" USE flag on a per-package basis or system-wide?
I'm asking because the current iptables ebuild has "nftbales"
BTW I just noticed that Gentoo Linux seems to have ditched iptables in
favor of enabling nftables by default.
Since Shorewall only works with iptables I guess Gentoo users should
set the -nftables USE flag system-wide (I have not tried that yet).
___
On Wed, Dec 1, 2021 at 12:16 PM Justin Pryzby wrote:
>
> On Wed, Dec 01, 2021 at 11:46:13AM +0100, Vieri Di Paola wrote:
> > Shorewall won't start on a recently built Linux system because it
> > doesn't find the arptables executable.
> > However, /sbin/arp
Hi,
Shorewall won't start on a recently built Linux system because it
doesn't find the arptables executable.
However, /sbin/arptables-legacy is present.
Is it as simple as making a symlink, or am I facing a much bigger
challenge here?
Regards,
Vieri
I found the problem myself. It was due to a DROP rule on an ipset. It
seems that this IP address was added to the set today for some reason.
Sorry for the noise!
___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
Hi,
I am unable to figure out why "lan" hosts can ping 13.107.4.51 and
13.107.4.53 but not 13.107.4.52 (www.msftconnecttest.com).
>From the Shorewall Firewall itself I **can** ping 13.107.4.52.
>From that same firewall if I run the following command I see no ICMP
requests when pinging from a host
On Tue, May 4, 2021 at 12:13 PM Norman and Audrey Henderson
wrote:
>
> Is this normal? Why would it not process the rtrules entry for $FW?
Hi,
Isn't $FW a zone name?
The first parameter for an rtrule should be interface|address|interface:address.
Why don't you specify the interface and/or IP
On Thu, Dec 17, 2020 at 6:20 PM Justin Pryzby wrote:
>
> On Thu, Dec 17, 2020 at 10:46:54AM +0100, Vieri Di Paola wrote:
> > I believe this topic was dealt with some time ago here:
> > https://sourceforge.net/p/shorewall/mailman/shorewall-use
Hi,
I believe this topic was dealt with some time ago here:
https://sourceforge.net/p/shorewall/mailman/shorewall-users/thread/CABLYT9j-KvM0JEwxoZ3xppoL5yxZqQe6qyEj0_wJJ8eecyE3nA%40mail.gmail.com/#msg37123538
Here is my rules file:
# cat /etc/shorewall/rules
?SECTION ALL
?IF $FW_TYPE
INCLUDE
On Wed, Dec 16, 2020 at 2:49 PM Simon Hobson wrote:
>
> Just be aware that if you do have ranges of addresses in more than one
> subnet, then the server will consider all of them "equal" and interchangeable
> - so if you want specific clients to end up in a specific subnet
> than you will need
On Wed, Dec 16, 2020 at 9:20 AM Simon Matter wrote:
>
> I don't know exactly what your problem is but I had a situation where I
> didn't get ISC dhcrelay to work. My solution was the dhcp helper
> http://thekelleys.org.uk/dhcp-helper/ from Simon Kelley.
Thanks, Simon.
I just got it working with
Hi,
I configured dhcrelay on my shorewall router to send DHCP requests to
a remote DHCP server. I need to listen for DHCP requests on on one
interface (say lan.1). However, this interface has multiple IP
addresses/netmasks. The remote DHCP server has only one scope and only
one of the IP
On Tue, Dec 15, 2020 at 10:47 PM Tom Eastep wrote:
>
> You haven't defined soc.50 to Shorewall, so it is rejecting all IPv4
> traffic to/from that interface.
Missed that.
Thank you very much for pointing that out to me.
Vieri
___
Shorewall-users
I don't know if this can help, but the SOC VM admin is claiming that
only ARP traffic is seen there when there should also be plenty of
TCP/UDP traffic.
So I've increased shorewall logging and noticed that some packets are
being rejected. The SOC VM is a ssh and http server, but I cannot
access
Hi,
My Shorewall router has a physical "LAN" interface with several VLANs
(lan.1, lan.13, lan.14, lan.15, etc.) and a physical "SOC" interface
with just one VLAN (interface name 'soc' and vlan name 'soc.50').
The SOC interface is connected to a specific port on my main/root
switch which is
On Tue, Nov 24, 2020 at 12:26 AM Tuomo Soini wrote:
>
> That's not quite enough. When dhcp clients want to renew leases they
> need unicast dhcp access to your dns server. You can do that in rules
> with DHCPfwd macro.
>
> DHCPfwd(ACCEPT) lan1ibs:10.215.137.54
>
> Macro will allow traffic to
Correct me if I'm wrong, but it seems that a reload is enough (no
restart needed) because it seems that the 'dhcp' option simply adds
the udp 67:68 rules on the specified interfaces. In my case, a
shorewall dump shows this kind rule was generated:
ACCEPT udp -- * * 0.0.0.0/0
On Mon, Nov 23, 2020 at 3:12 PM Simon Matter wrote:
>
> > lan1${IF_LAN}.1 routeback,arp_filter=1,proxyarp=1,dhcp
> > ibs $IF_IBS arp_filter=1,dhcp
>
> What is $IF_IBS? Is it a normal ethernet interface?
Yes, IF_IBS=ibs and IF_LAN=lan where ibs and lan are normal eth
Hi,
I configured dhcrelay so that clients in my "lan1" zone should get IP
addr. leases from a server in my "ibs" zone.
This is the command I run:
/usr/sbin/dhcrelay -q -i lan.1 10.215.137.54
BTW, a foreground run shows messages such as:
Forwarded BOOTREQUEST for a4:bb:6d:03:6d:c9 to
On Tue, Oct 27, 2020 at 12:08 PM Simon Matter wrote:
>
>> main10.215.106.193/26 $ADDR_GW_IBS$IF_IBS
> ^^^
> Does is work when you change the about to:
>
> 10.215.106.192/26
I get it now. My mistake.
Thanks a lot,
Hi,
What does this message mean, and what should I look for to fix it?
Error: Invalid prefix for given prefix length.
ERROR: Command "ip -4 route replace 10.215.106.193/26 via
172.28.17.110 dev ibs table 254" Failed
In my routes file I have:
main10.215.106.0/26
On Wed, Oct 7, 2020 at 5:39 PM Tom Eastep wrote:
>
> I work around this with the following rule in both the INVALID and NEW
> sections of my rules file.
>
> FIN(ACCEPT) { SOURCE=all, DEST=all }
>
> I also have this in the same two locations:
>
> RST(ACCEPT) { SOURCE=all, DEST=all }
Thank
On Wed, Oct 7, 2020 at 1:31 PM Simon Matter wrote:
>
> > Hi,
> >
> > If my rules allow HTTP and HTTPS access (ports 80, 443) with an ACCEPT
> > rule such as the following
> >
> > ACCEPTlan1:10.215.144.0/23wantcp,udp80,443
> >
> > I'd like to know why I am seeing the following in
On Tue, Oct 6, 2020 at 10:28 AM Witold Tosta wrote:
>
>> In any case, I'm now using a combination of TPROXY for HTTP and
>> redirect interceptions for HTTPS as follows, and both types of traffic
>> seem to be proxied without errors.
>>
>
> It seems like it might work. TPROXY for unencrypted http
Hi,
If my rules allow HTTP and HTTPS access (ports 80, 443) with an ACCEPT
rule such as the following
ACCEPTlan1:10.215.144.0/23wantcp,udp80,443
I'd like to know why I am seeing the following in the shorewall log
when a user accesses a web page:
kernel:
On Mon, Oct 5, 2020 at 11:46 AM Witold Tosta wrote:
>
> You cannot use TPROXY for a transparent proxy for HTTPS.
So this manual regarding TPROXY is only valid for HTTP, not HTTPS?
https://shorewall.org/Shorewall_Squid_Usage.html#TPROXY
I don't know the internals and limitations of TPROXY.
You
On Mon, Oct 5, 2020 at 8:17 AM Tuomo Soini wrote:
>
> On Mon, 5 Oct 2020 01:42:59 +0200
> Vieri Di Paola wrote:
>
> > > I seriously doubt that the TLS handshake works when you try using
> > > HTTPS. The proxy is a 'man in the middle' in that case.
>
> You
On Sun, Oct 4, 2020 at 7:58 PM Tom Eastep wrote:
>
> On 10/2/20 4:19 AM, Vieri Di Paola wrote:
> > Hi,
> >
> > I have some clients in a LAN that require access to WAN through a
> > transparent Squid web proxy on FW.
> >
> > I have this in mangle:
>
Hi,
I have some clients in a LAN that require access to WAN through a
transparent Squid web proxy on FW.
I have this in mangle:
# METHOD 1:
DIVERT $IF_WAN $PROXY_SOURCE_WAN
tcp - 80
TPROXY(3129)${IF_LAN}:$PROXY_SOURCE_WAN
On Tue, Jul 14, 2020 at 5:11 PM Simon Matter via Shorewall-users
wrote:
>
> > On Sat, Jul 11, 2020 at 9:49 PM Tom Eastep wrote:
> >>
> >> On 7/11/20 2:40 AM, Vieri Di Paola wrote:
> >>
> >> What was your 'shorewall iptrace command?
> >
> >
On Sat, Jul 11, 2020 at 9:49 PM Tom Eastep wrote:
>
> On 7/11/20 2:40 AM, Vieri Di Paola wrote:
>
> What was your 'shorewall iptrace command?
If I just run 'shorewall iptrace' with no filter, won't that just
trace all packets?
> > I saved a tcpdump taken on the Shorewall sy
On Fri, Jul 10, 2020 at 8:30 PM Tom Eastep wrote:
>
> On 7/10/20 1:51 AM, Vieri Di Paola wrote:
> > On Fri, Jul 10, 2020 at 3:20 AM Tom Eastep wrote:
> >
> >> Clearly the firewall is dropping the replies, but I can see no reason
> >> why it should. You could
On Fri, Jul 10, 2020 at 3:20 AM Tom Eastep wrote:
> Clearly the firewall is dropping the replies, but I can see no reason
> why it should. You could try using 'shorewall iptrace' to try to
> understand where.
This is the trace I could get:
# grep -i trace /var/log/messages |grep 10.215.144.251
On Thu, Jul 9, 2020 at 8:39 PM Tom Eastep wrote:
>
> Do you see each packet twice (once inbound and once outbound)?
When the ICMP request/reply succeeds (it's the case of most hosts)
then yes, the requests and replies are duplicated as in this dump:
# tcpdump -n -i lan.1 host 10.215.246.24
Hi,
I've captured a dump while trying to ping host with IP addr.
10.215.246.24 from host with IP addr. 10.215.144.251.
Both are within the same zone 'lan1',but they have different network settings.
The host with IP addr. 10.215.246.24 is a Windows Server with these settings:
netmask
On Sun, Jun 28, 2020 at 1:28 AM Tom Eastep wrote:
>
>
> Can other hosts connect to this site out of the ppp interface?
Now that you mention it, on the Shorewall system itself I'm seeing
something unexpected.
I should be able to access this or any other site through any of my
ppp links (there are
Hi,
When I see packets going out an external interface on a Shorewall
gateway ('net' ppp interface) and nothing coming back, what can that
mean?
In the dump below, 1.1.1.1 is my ppp interface's IP address and
2.2.2.2 is an Internet IP address a client browser in the LAN is
trying to connect to.
On Fri, Jun 26, 2020 at 6:33 PM Tom Eastep wrote:
>
> The only thing that I see in the dump is that you are dropping TCP 3389
> ESTABLISHED packets not marked with value 0xa; that might be the issue
Well, I don't know how I didn't see that, but yes, I'm sending the
packets to Suricata IPS and
On Thu, Jun 25, 2020 at 5:39 PM Tom Eastep wrote:
>
> That traffic is entering through the 'soc' interface. So if you unplug
> the cable to that interface, then the messages will of course stop.
The vlan settings on the connected switch were incorrect.
Thanks,
Vieri
Hi,
It seems I can't access an RDP service (3389) on a host with IP
address 10.215.246.24 from an openvpn client with IP address
192.168.146.98.
Accessing the same RDP server from another client works fine.
I'm not sure it's a firewall issue because I see this:
# tcpdump -n -i tun146 port 3389
Hi,
I recently upgraded both the Linux kernel and Shorewall, and my setup
started to have issues I wasn't seeing before.
I am routing between networks, and I would like to "port mirror"
traffic from some VLANs to one ethernet device, ie. from lan.13,
lan.14 and lan.15 to soc.50.
As you can see
Hi,
I've been using Squid + TPROXY in transparent sslbump mode for quite a
while now, but I'd like to use an explicit proxy with user
authentication instead.
I have Squid on my first Shorewall firewall, and then I have another
Shorewall gateway where all the HTTP requests go through, with
Hi,
This might be trivial, but how can I add a source IP address to an
ipset only when the source port is NOT in an ipset AND NOT in a port
range?
the following gives an error:
ADD(POL_BL:src):info:polbl,add2polbl
net1,net2,net3:!+POL_BL,+GLOBAL_WL,+NORMAL_WL all tcp -
On Mon, Apr 6, 2020 at 3:26 PM Roberto C. Sánchez wrote:
>
> Is there any what that you can run wakeonlan on the Shorewall FW router?
> That should simplify things since that machine will be in the two
> network segments by virtue of being a router between them.
I know, but I need to do this
Hi,
Is it possible to forward WOL magic packet on a network like thie one
I'm showing below?
HOST running "wakeonlan -i 10.215.255.255 " (in loc1 zone)
--- Shorewall FW router --- HOSTS in loc2 zone (MAC_ADDR found here)
An ACCEPT rule from loc1 to loc2 for UDP port 9 does not seem to work.
On Mon, Mar 23, 2020 at 2:03 PM Erich Titl wrote:
>
> >>> IN=ppp3 OUT= MAC= SRC=1.2.3.4 DST=4.3.2.1 LEN=72 TOS=0x00 PREC=0x00
> >>> TTL=48 ID=46761 DF PROTO=UDP SPT=41152 DPT=58129 LEN=52 MARK=0x3
> >>>
> ...
>
> >
> >
> >>> The user has no idea what this UDP connection is for, and I haven't
>
On Mon, Mar 23, 2020 at 12:45 PM Matt Darfeuille wrote:
>
> On 3/23/2020 11:40 AM, Vieri Di Paola wrote:
> > Hi,
> >
> > I set up my Shorewall gateway with the following logic:
> > - accept incoming connections for ports tcp 443, 80, and several others.
> &g
Hi,
I set up my Shorewall gateway with the following logic:
- accept incoming connections for ports tcp 443, 80, and several others.
- all other connection attempts to other ports are dropped and the
source IP address is included in an ipset blacklist so subsequent
connection attempts even to
> How did you select the ipset contents? Did you use one set per country?
> Do you have code to share?
You can try this code out:
https://github.com/chr0mag/geoipsets
Then write your shorewall rules to use either one: xt_geoip or ipsets.
Compare the results.
Good luck,
Vieri
Hi,
My rules are similar to Witek's, but I have to admit that I too have
seen erroneous IP addr./country matching. I used the latest geoIP2
databases from Maxmind and xtables-addons. The xt_geoip module might
be faster, but I've decided to move away from it and use ipsets
instead. At least
On Thu, Feb 13, 2020 at 4:34 AM Tom Eastep wrote:
>
> > After rebooting into the new kernel, shorewall complains with:
> >
> > "Your kernel/iptables do not include state match support."
> >
> > Grepping for the kernel option yields the following even for the new kernel:
> >
> >
On Thu, Feb 13, 2020 at 8:20 AM Witold Tosta wrote:
>
> It seemed to me that way too
> czw., 13 lut 2020 o 05:16 Tom Eastep napisał(a):
>>
>> Vieri's problem appears to be in the driver for his Network Interface
>> Card
Maybe, maybe not. The fact is that I'm seeing the same kernel message
when
On Wed, Feb 12, 2020 at 11:45 AM Witold Tosta wrote:
>
> In my opinion, the xt_geoip modules from xtables-addons have nothing to do
> with your error. I would rather bet on the cooperation of the
> e1000e network card driver with the tcpip stack.
No, if you take a look at the link I posted
Hi,
On a system with shorewall working fine, I decided to build a new
kernel version, and rebuild all kernel modules for that version.
iptables has not been re-compiled after building and symlinking the
new kernel version.
After rebooting into the new kernel, shorewall complains with:
"Your
On Tue, Feb 11, 2020 at 5:33 PM Witold Tosta wrote:
>
> >
> > Now, xt_geoip is never loaded (nor are the other ones).
>
> Could you please explain why you don't want the module xt_geoip to be
> loaded? For Linux system, loading it really doesn't matter.
Why? Well, I've been using xt_geoip and
On Tue, Feb 11, 2020 at 3:49 PM Matt Darfeuille wrote:
>
> If the other modules are not loaded and 'AUTOHELPERS' is set to 'No',
> are you sure that Shorewall is the culprit?
AUTOHELPERS is set to yes (default) for its convenience.
Maybe I should specify a helper for each rule that needs it, and
Hi,
I've blacklisted some kernel modules so they are not autoloaded at
boot time (/etc/modprobe.d).
I've also blacklisted them in Shorewall.
# grep DONT_LOAD /etc/shorewall/shorewall.conf
DONT_LOAD=xt_geoip,xt_iface,xt_TARPIT
However, the geoip module is still getting loaded.
# lsmod | grep
Hi,
The message is a bit scary at first, but it doesn't seem to affect my
setup for now.
It started showing up with kernel 5.x (I have 5.5.0).
On shorewall reload or start:
Adding Providers...
Error: ipv4: FIB table does not exist.
Dump terminated
Also:
# ip route show table default
Error:
Hi,
xtables-addons has changed a bit recently. Teh geoip build script it
ships does not create the BE and LE subdirs, so shorewall complains
with:
ERROR: GEOIPDIR (/usr/share/xt_geoip/LE) does not exist
The files are all in /usr/share/xt_geoip.
I don't know what LE and BE did in the past, and
On Mon, Dec 23, 2019 at 3:25 PM Roberto C. Sánchez wrote:
>
> I thought the wiki was set so that anyone who is logged in can edit or
> create content.
Hi,
I logged in with my gmail account, but this is what the Wiki section reads:
quote
This project has no wiki pages
You must be a project
Hi Roberto,
On Mon, Dec 23, 2019 at 12:57 AM Roberto C. Sánchez
wrote:
>
> Let me encourage you to capture it as a wiki page in GitLab:
> https://gitlab.com/shorewall/code/-/wikis/home
I logged in with my gmail account. Do I need to be a project member to
publish just one simple wiki page? If
Can this be related to the AUTOMAKE option?
On Fri, Dec 6, 2019, 19:36 Connor Schlesiger wrote:
> Hey Matt,
>
> Restarting with 'shorewall -c /etc/shorewall restart' appears to have
> worked! I have always restarted with 'systemctl restart shorewall' or
> 'shorewall restart' without the
Thanks, Matt!
Just one last question. I presume it's advisable to use the same
versions of shorewall and shorewall-lite, but not strictly required.
If there were a version incompatibility between the admin system and
any of the "lite systems" in the network, would Shorewall (on the
admin sys)
On Wed, Dec 4, 2019 at 4:07 PM Matt Darfeuille wrote:
>
> I would suggest you to read/reread (1) as it contains some answers to
> your questions.
It's a great guide, but I at least have a couple of doubts. It doesn't
hurt to clear them up before it's too late ;-).
> It would be also good to
Hi,
I'm trying to move from Shorewall to Shorewall-Lite. Could you please
read through this quick guide and see if I've misunderstood something
(there are a few things I'm not sure of)?
Safely migrating from Shorewall to Shorewall-Lite on a non-Debian
distro (pseudo-algorithm)
CAVEATS:
On Tue, Nov 19, 2019 at 4:41 PM Lennart Sorensen
wrote:
>
> Certain packets (in our case NAT UDP encapsulated IPsec packets) always
> get an RSS value of 0 assigned, no matter what RSS hash or rules
> are applied.
Thank you very much for sharing that information.
Vieri
On Fri, Oct 11, 2019 at 6:11 PM Lennart Sorensen
wrote:
>
> I would not currently recommend the X722. We are having problems with
> it and are hoping intel will eventually fix it with a firmware update,
> but it is taking forever. Unfortunately it is built into the chipset
> of many modern
Hi,
I usually set up port mirroring outside Shorewall, but on a restart I
need to reconfigure it.
I was wondering if I could set up port mirroring within the shorewall
config files.
My first try was to use the started file:
if [ "$COMMAND" = start -o "$COMMAND" = restart -o "$COMMAND" = reload
On Sat, Nov 9, 2019 at 1:48 AM Bill Shirley
wrote:
>
> > 10001: from all fwmark 0x2/0xff lookup CAIB
>
> The only thing you need to do is add a rule to the mangle file (PREROUTING
> section)
> utilizing the SWITCH column to mark all the traffic you want to override to
> CAIB with
> MARK(2):P
Hi,
I have a specific routing requirement that I'll try to explain here.
I define routes in the main table via the routes file (not with my
distro's network manager) such as:
main10.215.198.0/23 $ADDR_GW_IBS$IF_IBS
[lots and lots more to 10.215.x.x via $ADDR_GW_IBS dev
Hi,
On Tue, Nov 5, 2019 at 6:05 PM Tom Eastep wrote:
>
> > Do you mean I should use rpfilter in the "interfaces" file (I've never
> > used routefilter)? Which interface? The one I'm seeing the martian
> > source messages for? Incidentally, adding the rpfilter option to
> > enp8s5 yields a 0 in
Hi,
Routing Rules
0: from all lookup local
1: from all fwmark 0x200/0x200 lookup Tproxy
220:from all lookup 220
999:from all lookup main
[...etc...]
Is it "safe" to insert routing rules with priorities between 221 and
998 for policy based routing? I need to add exceptions to
On Tue, Nov 5, 2019 at 6:13 PM Tom Eastep wrote:
>
> No -- you can simply use 'ip route replace'.
Oh, interesting. However, it's still not as versatile as "inserting" a
new rule in whatever position (priority index) and then deleting it.
I guess I might use some sort of placeholder here and
1 - 100 of 408 matches
Mail list logo
