Re: [Shorewall-users] Using Shorewall to remove martian warnings from kernel log
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 network. > > Home network is on 192.168.0.x > > My wife has configured her laptop NIC with both a 192.168 address and a > 172.16.x address, so that she can connect to a private development system > at her office (this system uses static IPs only). > > This means that when she connects at home the firewall machine log is > flooded with kernel warnings about 172.16 martian packets. > > I can disable these warnings in the shorewall log but they still appear in > the system log (journalctl). > > Can I use shorewall to drop them before the kernel sees them? or is there > some other way of cleaning up the log? > > Thanks for any help. > ___ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users > ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] TTL on Oracle connections
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 right now (and I'm not the admin of the remote system anyway), but it seems to be a "session timeout" as Fortinet seems to treat every connection as a "session". If that were true I guess it might be the equivalent of net.netfilter.nf_conntrack_tcp_timeout_established which in my case is 86400. If that really were it then I wouldn't have to change anything. The thing is that Fortinet seems to be able to apply a specific timeout to a type of connection -- in this case any connection to port tcp 1521 -- while net.netfilter.nf_conntrack_tcp_timeout_established is system-wide. Or maybe Fortinet's "timeout" refers to something else. > Timeout can mean a lot. Could it be that the FW is doing some NAT and this > is the connection tracking timeout? I do not have that info. > Do you actually see any issues with these connections? Or do you just want > to have a matching configuration? Both. The user has an application which connects to a remote Oracle DB. At some point after x minutes idle the client software fails and complains about a connection error. I've been told that it's because of a timeout at FW level even though I'm guessing this wouldn't happen if the software and/or client/server OS were properly configured with keepalive connections. I'll try to get more info from Fortinet. Thanks ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
[Shorewall-users] TTL on Oracle connections
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 set start-port 1521 set end-port 1521 I don't know how to translate "set timeout 28800" to Shorewall/iptables on Linux. I've searched for timeouts and keepalives at OS level with sysctl such as: net.ipv4.tcp_keepalive_intvl = 75 net.ipv4.tcp_keepalive_probes = 9 net.ipv4.tcp_keepalive_time = 7200 but I believe that wouldn't necessarily apply here in the case of a Shorewall router, or would it? Also, I don't want to change any global OS settings, but I'd rather stick to just tcp 1521. I didn't see anything in shorewall about keepalives or connection timeouts except rate limiting in the rules file and TTL in the mangle file. Nothing that seems to apply to the topic at hand. Any suggestions? ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] ERROR: Invalid command: debug
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) Sorry for the noise, and thanks to all. ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] ERROR: Invalid command: debug
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 I reported in my first post seems to indicate that the current shorewall version still tries to auto-run "shorewall debug check" when it should be running "shorewall check -D" instead. ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] ERROR: Invalid command: debug
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, so I wanted to try the trace
and debug options in case I encounter more of these misconfigurations
in the future.
I ran:
# shorewall trace check
ERROR: Invalid command: trace
The man page says:
shorewall[6] [trace|debug] [options] [check | ck ] [-e] [-d] [-p] [-r] [-T]
[-i] [directory]
# shorewall version -a
shorewall-core: 5.2.8
shorewall: 5.2.8
shorewall6: 5.2.8
shorewall-init: 5.2.8
Incidentally, I get this output when I run the following:
# shorewall debug check
ERROR: Invalid command: debug
Same message as in my first post.
So, are "debug" and "trace" system or Shorewall-specific commands that
have not been installed in my OS?
Thanks,
Vieri
___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users
[Shorewall-users] ERROR: Invalid command: debug
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
___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] ACK replies are dropped
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 WINDOW=123 RES=0x00 ACK URGP=0 > > This is not FIN or RST. Sorry, I thought it was FIN as /usr/share/shorewall/action.FIN contains the ACK tcp flag. > And you don't want to allow this type of > packets, those are so called late replies - eg replies for connections > which have been long gone. That's what puzzles me. When is a reply considered to be late? When it's removed form the conntrack table, I suppose. What is the conntrack table entry timeout? Does the following value have anything to do with it? # sysctl net.netfilter.nf_conntrack_tcp_timeout_established net.netfilter.nf_conntrack_tcp_timeout_established = 86400 I'm trying to understand why I'm getting these late ACK replies because I'm seeing too many of them. Sure, I could hide them from the shorewall log, but I need to make sure they are not a symptom of a problem. Thanks, Vieri ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
[Shorewall-users] ACK replies are dropped
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:
https://sourceforge.net/p/shorewall/mailman/shorewall-users/thread/CABLYT9j-KvM0JEwxoZ3xppoL5yxZqQe6qyEj0_wJJ8eecyE3nA%40mail.gmail.com/#msg37123538
However, I'm still seeing ACK drops as noted in this other post:
https://sourceforge.net/p/shorewall/mailman/message/37178313/
eg.:
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 WINDOW=123 RES=0x00 ACK URGP=0
The shorewall rules man page does not explain how to use the curly brackets.
What is the format of the content within these characters?
I'm wondering if "SOURCE=all, DEST=all" is syntactically correct.
If so, why am I seeing these dropped ACK replies when I have no rules
blocking them (eg. lan1-wan HTTPS traffic from 10.215.248.214 to
23.200.66.154 is allowed, so I'm expecting the ACK not to be dropped)?
Vieri
___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users
[Shorewall-users] shorewall and IPSec traffic monitoring
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 traffic with tools such as tcpdump -i nflog:5. Ref. https://docs.strongswan.org/strongswan-docs/5.9/install/trafficDumps.html Regards, Vieri ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
[Shorewall-users] rules and IP addresses
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 access zone4. Regards, Vieri ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] FTP SSL
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 2990 3000 MultilineRFC2228 on ShowSymlinks off DefaultTransferMode binary MaxClients 30 "ERROR: reached maximum user limit (%m)." MaxClientsPerUser 20 "ERROR: reached maximum connections per user limit (%m)." MaxLoginAttempts 3 DefaultRoot ~ AllowOverwrite on AllowOverride off AllowRetrieveRestart on AllowStoreRestart on DelayEngine on TLSEngine on TLSLog /var/log/proftpd_tls.log TLSProtocol TLSv1 TLSv1.1 TLSv1.2 TLSRequired on TLSRSACertificateFile /etc/ssl/CA-HMN/certs/ftpservers_HM_cert.pem TLSRSACertificateKeyFile /etc/ssl/CA-HMN/certs/ftpservers_HM_key_nopassphrase.pem TLSVerifyClient off TLSOptions AllowClientRenegotiations NoSessionReuseRequired ClamAV on ClamServer 127.0.0.1 ClamPort 3310 DenyAll Include /etc/proftpd/user_list ServerName "MHSC FTP server" Port 21 MasqueradeAddress mhsc.domain.org TransferLog /var/log/proftpd_xfer_mhsc.log ServerName "MHSI FTP server" Port 21 MasqueradeAddress mhsi.domain.org TransferLog /var/log/proftpd_xfer_mhsi.log User ftp Group ftp DebugLevel 0 SystemLog /var/log/proftpd.log WtmpLog off ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] Unable to connect to an HTTPS service
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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] Unable to connect to an HTTPS service
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 equivalent depending on the machine OS > package manager) update/upgrade for at least the ca-certificates, openssl and > gnutls packages and try again. The client hosts are both Windows 10 64bits. The curl client software used for testing is the same (for Windows) and has the same ca-certificates (CAfile: C:\cURL\curl-ca-bundle.crt). In a wireshark pcap file I can see an initial SYN, a SYN,ACK from the Microsoft server, an ACK from my host followed by a "Client Hello" with TLSv1 data. The last packet is an ACK from the Microsoft server, and nothing else. I'm supposing the MS server did not like the Client Hello offer, but why... I'm trying to compare the "Client Hello" data with that of when the same host connects to Teams via 52.113.195.132, or when the "other host in the LAN" properly connects to 52.113.194.132, but I see no difference. On a successful connection, the Server Hello replies with TLS v 1.2 and Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030). I see that even the failing hosts are also offering the same in their "Client Hello" messages. Anyway, if the Teams server is sending back an ACK right after the Client Hello, can I safely discard that there is an issue on the Shorewall router? Thanks, Vieri ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] Do not load specific Linux kernel modules
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 conntrack module alone. Thanks, Simon. Vieri ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
[Shorewall-users] Unable to connect to an HTTPS service
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 https://teams.microsoft.com
* Trying 52.113.194.132:443...
* Connected to teams.microsoft.com (52.113.194.132) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* CAfile: C:\cURL\curl-ca-bundle.crt
* CApath: none
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS header, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS header, Finished (20):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS header, Finished (20):
* TLSv1.2 (IN), TLS header, Certificate Status (22):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use h2
[etc]
Another host in the same vlan with IP addr. 10.215.111.199 is unable
to connect to the exact same site and at the same time
(52.113.194.132):
curl --verbose --head https://teams.microsoft.com
* Trying 52.113.194.132:443...
* Connected to teams.microsoft.com (52.113.194.132) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* CAfile: C:\curl\curl-ca-bundle.crt
* CApath: none
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.0 (OUT), TLS header, Unknown (21):
* TLSv1.3 (OUT), TLS alert, decode error (562):
* error:0A000126:SSL routines::unexpected eof while reading
* Closing connection 0
curl: (35) error:0A000126:SSL routines::unexpected eof while reading
This is what I see with tcpdump while trying the above connection
("wan" is the interface facing Internet):
# tcpdump -n -i wan host 10.215.111.199
dropped privs to pcap
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on wan, link-type EN10MB (Ethernet), snapshot length 262144 bytes
10:58:55.602587 IP 10.215.111.199.60258 > 52.113.194.132.443: Flags
[S], seq 1097095637, win 64240, options [mss 1460,nop,wscale
8,nop,nop,sackOK], length 0
10:58:55.602797 IP 52.113.194.132.443 > 10.215.111.199.60258: Flags
[S.], seq 2635751257, ack 1097095638, win 14600, options [mss
1460,nop,nop,sackOK,nop,wscale 7], length 0
10:58:55.604900 IP 10.215.111.199.60258 > 52.113.194.132.443: Flags
[.], ack 1, win 1026, length 0
10:58:55.880427 IP 10.215.111.199.60258 > 52.113.194.132.443: Flags
[P.], seq 1:518, ack 1, win 1026, length 517
10:58:55.880581 IP 52.113.194.132.443 > 10.215.111.199.60258: Flags
[.], ack 518, win 123, length 0
What makes things "worse" is that if I tamper with this host's "hosts"
file and manually set the name resolution of teams.microsoft.com to
52.113.195.132 (another valid IP addr. for teams.microsoft.com) then
it can finally connect as expected.
There's no shorewall rule to block 52.113.194.132:443 so I don't know
why the TLS handshake is failing.
I'd like to determine if this is a communications issue (ie.
Shorewall) or a client/server hosts problem.
Regards,
Vieri
___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users
[Shorewall-users] Do not load specific Linux kernel modules
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 shorewall.conf. # grep DONT_LOAD shorewall.conf DONT_LOAD=nf_nat_sip,nf_conntrack_sip However, a shorewall restart will not remove the following: # lsmod | grep -i sip nf_conntrack_sip 40960 2 nf_conntrack 176128 25 xt_conntrack,nf_nat_irc,nf_nat,nf_conntrack_tftp,nf_nat_ftp,nf_conntrack_pptp,nf_conntrack_netbios_ns,nf_conntrack_sane,xt_nat,nf_nat_tftp,nf_nat_amanda,nf_conntrack_sip,nf_conntrack_h323,nf_nat_pptp,nf_conntrack_broadcast,nf_conntrack_irc,nf_conntrack_amanda,nf_conntrack_netlink,xt_connmark,nf_conntrack_ftp,xt_CT,nf_nat_h323,nf_conntrack_snmp,nf_nat_snmp_basic,xt_REDIRECT # modprobe -r nf_conntrack_sip modprobe: FATAL: Module nf_conntrack_sip is in use. Is there a way to unload nf_conntrack_sip without rebooting the OS? Regards, Vieri ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] Cannot ping between two hosts
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 tools (limited commands). Nothing worked until I finally rebooted them. All's fine now. So I guess the HP iLO firmware is buggy. Vieri ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] Cannot ping between two hosts
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. ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] Cannot ping between two hosts
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 changes some of these network parameters. It also handles routing tables and routing rules. In any case, you describe a general situation, but I'm giving details on a very specific issue. I appreciate your time, but I need to figure out why I'm seeing this odd behavior. Since you do not seem to be using Shorewall but iptables and system tools, I was wondering if you could share the name of a could "general purpose" Linux networking forum or mailing list. I once subscribed to the netfilter ML, but it was overwhelming. If you have any suggestions as to where I might explain the issue I'm seeing in this topic, I'd appreciate it. Thanks, Vieri ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] Cannot ping between two hosts
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 full protocol decode listening on lan, link-type EN10MB (Ethernet), snapshot length 262144 bytes 00:01:27.495068 9c:7b:ef:b7:7a:a1 > b8:59:9f:cc:bb:5c, ethertype 802.1Q (0x8100), length 78: vlan 1, p 0, ethertype IPv4 (0x0800), 10.215.111.210 > 10.215.144.251: ICMP echo request, id 1, seq 3845, length 40 00:01:27.495095 b8:59:9f:cc:bb:5c > 94:40:c9:26:dc:80, ethertype 802.1Q (0x8100), length 78: vlan 18, p 0, ethertype IPv4 (0x0800), 10.215.111.210 > 10.215.144.251: ICMP echo request, id 1, seq 3845, length 40 00:01:27.495105 9c:7b:ef:b7:7a:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 78: vlan 50, p 0, ethertype IPv4 (0x0800), 10.215.111.210 > 10.215.144.251: ICMP echo request, id 1, seq 3845, length 40 00:01:27.495293 94:40:c9:26:dc:80 > ac:1f:6b:f5:b7:1b, ethertype 802.1Q (0x8100), length 78: vlan 18, p 0, ethertype IPv4 (0x0800), 10.215.144.251 > 10.215.111.210: ICMP echo reply, id 1, seq 3845, length 40 # ip a s lan.18 65: lan.18@lan: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether b8:59:9f:cc:bb:5c brd ff:ff:ff:ff:ff:ff inet 192.168.240.1/24 brd 192.168.240.255 scope global lan.18 valid_lft forever preferred_lft forever # ip a s ext 139: ext: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether ac:1f:6b:f5:b7:1b brd ff:ff:ff:ff:ff:ff inet 192.168.170.1/24 brd 192.168.170.255 scope global ext valid_lft forever preferred_lft forever # ip neigh list | grep 10.215.144.251 10.215.144.251 dev lan.18 lladdr 94:40:c9:26:dc:80 REACHABLE Ignore vlan 50 as it's just for port mirroring traffic to an IDS. So to sum it up: - host with IP addr. 10.215.111.210 and MAC addr. 9c:7b:ef:b7:7a:a1 sends a ping request which hits the FW's lan.18 interface with MAC addr. b8:59:9f:cc:bb:5c - the ICMP request is sent out to the MAC addr. 94:40:c9:26:dc:80 which is that of the DST host with IP addr. 10.215.144.251 - the ICMP reply comes back on the FW's vlan 18 interface and is sent to 10.215.111.210 (SRC addr.) through MAC addr. ac:1f:6b:f5:b7:1b - However, interface "ext" has nothing to do with vlan 1 so why are the reply packets sent there? On the other hand, in the successful scenario where a host in vlan 1 with IP addr. 10.215.111.210 can ping a host in vlan 18 with IP addr. 10.215.144.129 this is what I see on the SW FW: # tcpdump -n -i lan -e vlan and host 10.215.144.129 dropped privs to pcap tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on lan, link-type EN10MB (Ethernet), snapshot length 262144 bytes 00:16:18.875974 9c:7b:ef:b7:7a:a1 > b8:59:9f:cc:bb:5c, ethertype 802.1Q (0x8100), length 78: vlan 1, p 0, ethertype IPv4 (0x0800), 10.215.111.210 > 10.215.144.129: ICMP echo request, id 1, seq 4050, length 40 00:16:18.875992 b8:59:9f:cc:bb:5c > 94:40:c9:26:e2:d2, ethertype 802.1Q (0x8100), length 78: vlan 18, p 0, ethertype IPv4 (0x0800), 10.215.111.210 > 10.215.144.129: ICMP echo request, id 1, seq 4050, length 40 00:16:18.876005 9c:7b:ef:b7:7a:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 78: vlan 50, p 0, ethertype IPv4 (0x0800), 10.215.111.210 > 10.215.144.129: ICMP echo request, id 1, seq 4050, length 40 00:16:18.876104 94:40:c9:26:e2:d2 > b8:59:9f:cc:bb:5c, ethertype 802.1Q (0x8100), length 78: vlan 18, p 0, ethertype IPv4 (0x0800), 10.215.144.129 > 10.215.111.210: ICMP echo reply, id 1, seq 4050, length 40 00:16:18.876115 b8:59:9f:cc:bb:5c > 9c:7b:ef:b7:7a:a1, ethertype 802.1Q (0x8100), length 78: vlan 1, p 0, ethertype IPv4 (0x0800), 10.215.144.129 > 10.215.111.210: ICMP echo reply, id 1, seq 4050, length 40 00:16:18.876133 b8:59:9f:cc:bb:5c > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 78: vlan 50, p 0, ethertype IPv4 (0x0800), 10.215.144.129 > 10.215.111.210: ICMP echo reply, id 1, seq 4050, length 40 # ip neigh list | grep 10.215.144.129 10.215.144.129 dev lan.18 lladdr 94:40:c9:26:e2:d2 REACHABLE Any ideas as to why I'm seeing this? Why is interface "ext" receiving the ICMP replies in the first case? This keeps happening even if I take the FW interface with MAC. addr. ac:1f:6b:f5:b7:1b down. ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
[Shorewall-users] Cannot ping between two hosts
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 full protocol decode listening on lan, link-type EN10MB (Ethernet), snapshot length 262144 bytes 00:01:27.495068 9c:7b:ef:b7:7a:a1 > b8:59:9f:cc:bb:5c, ethertype 802.1Q (0x8100), length 78: vlan 1, p 0, ethertype IPv4 (0x0800), 10.215.111.210 > 10.215.144.251: ICMP echo request, id 1, seq 3845, length 40 00:01:27.495095 b8:59:9f:cc:bb:5c > 94:40:c9:26:dc:80, ethertype 802.1Q (0x8100), length 78: vlan 18, p 0, ethertype IPv4 (0x0800), 10.215.111.210 > 10.215.144.251: ICMP echo request, id 1, seq 3845, length 40 00:01:27.495105 9c:7b:ef:b7:7a:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 78: vlan 50, p 0, ethertype IPv4 (0x0800), 10.215.111.210 > 10.215.144.251: ICMP echo request, id 1, seq 3845, length 40 00:01:27.495293 94:40:c9:26:dc:80 > ac:1f:6b:f5:b7:1b, ethertype 802.1Q (0x8100), length 78: vlan 18, p 0, ethertype IPv4 (0x0800), 10.215.144.251 > 10.215.111.210: ICMP echo reply, id 1, seq 3845, length 40 # ip a s lan.18 65: lan.18@lan: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether b8:59:9f:cc:bb:5c brd ff:ff:ff:ff:ff:ff inet 192.168.240.1/24 brd 192.168.240.255 scope global lan.18 valid_lft forever preferred_lft forever # ip a s ext 139: ext: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether ac:1f:6b:f5:b7:1b brd ff:ff:ff:ff:ff:ff inet 192.168.170.1/24 brd 192.168.170.255 scope global ext valid_lft forever preferred_lft forever # ip neigh list | grep 10.215.144.251 10.215.144.251 dev lan.18 lladdr 94:40:c9:26:dc:80 REACHABLE Ignore vlan 50 as it's just for port mirroring traffic to an IDS. So to sum it up: - host with IP addr. 10.215.111.210 and MAC addr. 9c:7b:ef:b7:7a:a1 sends a ping request which hits the FW's lan.18 interface with MAC addr. b8:59:9f:cc:bb:5c - the ICMP request is sent out to the MAC addr. 94:40:c9:26:dc:80 which is that of the DST host with IP addr. 10.215.144.251 - the ICMP reply comes back on the FW's vlan 18 interface and is sent to 10.215.111.210 (SRC addr.) through MAC addr. ac:1f:6b:f5:b7:1b - However, interface "ext" has nothing to do with vlan 1 so why are the reply packets sent there? On the other hand, in the successful scenario where a host in vlan 1 with IP addr. 10.215.111.210 can ping a host in vlan 18 with IP addr. 10.215.144.129 this is what I see on the SW FW: # tcpdump -n -i lan -e vlan and host 10.215.144.129 dropped privs to pcap tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on lan, link-type EN10MB (Ethernet), snapshot length 262144 bytes 00:16:18.875974 9c:7b:ef:b7:7a:a1 > b8:59:9f:cc:bb:5c, ethertype 802.1Q (0x8100), length 78: vlan 1, p 0, ethertype IPv4 (0x0800), 10.215.111.210 > 10.215.144.129: ICMP echo request, id 1, seq 4050, length 40 00:16:18.875992 b8:59:9f:cc:bb:5c > 94:40:c9:26:e2:d2, ethertype 802.1Q (0x8100), length 78: vlan 18, p 0, ethertype IPv4 (0x0800), 10.215.111.210 > 10.215.144.129: ICMP echo request, id 1, seq 4050, length 40 00:16:18.876005 9c:7b:ef:b7:7a:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 78: vlan 50, p 0, ethertype IPv4 (0x0800), 10.215.111.210 > 10.215.144.129: ICMP echo request, id 1, seq 4050, length 40 00:16:18.876104 94:40:c9:26:e2:d2 > b8:59:9f:cc:bb:5c, ethertype 802.1Q (0x8100), length 78: vlan 18, p 0, ethertype IPv4 (0x0800), 10.215.144.129 > 10.215.111.210: ICMP echo reply, id 1, seq 4050, length 40 00:16:18.876115 b8:59:9f:cc:bb:5c > 9c:7b:ef:b7:7a:a1, ethertype 802.1Q (0x8100), length 78: vlan 1, p 0, ethertype IPv4 (0x0800), 10.215.144.129 > 10.215.111.210: ICMP echo reply, id 1, seq 4050, length 40 00:16:18.876133 b8:59:9f:cc:bb:5c > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 78: vlan 50, p 0, ethertype IPv4 (0x0800), 10.215.144.129 > 10.215.111.210: ICMP echo reply, id 1, seq 4050, length 40 # ip neigh list | grep 10.215.144.129 10.215.144.129 dev lan.18 lladdr 94:40:c9:26:e2:d2 REACHABLE Any ideas as to why I'm seeing this? Why is interface "ext" receiving the ICMP replies in the first case? ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] Cannot ping between two hosts
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 (request & reply) a host in vlan 18 with IP addr. 10.215.144.129. Same dst IP addr. range, same dst vlan, etc., but in my first post, the ICMP replies were reaching the SW FW but not the SRC host in vlan 1. Very odd. I'm trying to search for the difference between the DST host with IP addr. 10.215.144.129 and the one with IP addr. 10.215.144.251. Thanks, Vieri ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
[Shorewall-users] Cannot ping between two hosts
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 rule: ACCEPTlan1:10.215.111.210lan18:10.215.144.251-10.215.144.253all # tcpdump -n -i lan.18 host 10.215.144.251 dropped privs to pcap tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on lan.18, link-type EN10MB (Ethernet), snapshot length 262144 bytes 13:38:24.465826 IP 10.215.111.210 > 10.215.144.251: ICMP echo request, id 1, seq 3381, length 40 13:38:24.466057 IP 10.215.144.251 > 10.215.111.210: ICMP echo reply, id 1, seq 3381, length 40 13:38:29.452923 IP 10.215.111.210 > 10.215.144.251: ICMP echo request, id 1, seq 3382, length 40 13:38:29.453124 IP 10.215.144.251 > 10.215.111.210: ICMP echo reply, id 1, seq 3382, length 40 ^C 4 packets captured 4 packets received by filter 0 packets dropped by kernel # tcpdump -n -i lan.1 host 10.215.144.251 dropped privs to pcap tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on lan.1, link-type EN10MB (Ethernet), snapshot length 262144 bytes 13:38:39.453736 IP 10.215.111.210 > 10.215.144.251: ICMP echo request, id 1, seq 3384, length 40 13:38:44.462989 IP 10.215.111.210 > 10.215.144.251: ICMP echo request, id 1, seq 3385, length 40 13:38:49.453419 IP 10.215.111.210 > 10.215.144.251: ICMP echo request, id 1, seq 3386, length 40 13:38:54.462301 IP 10.215.111.210 > 10.215.144.251: ICMP echo request, id 1, seq 3387, length 40 ^C 4 packets captured 17 packets received by filter 0 packets dropped by kernel This is a dump taken while pinging: https://drive.google.com/file/d/1vEuySlF4SQVMREJBztncRy2a2P2SuD2K/view?usp=sharing Any ideas? Regards, Vieri ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] arptables-legacy
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 Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] arptables-legacy
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 my system the iptables command points to xtables-legacy-multi whereas the arptables symlink is non-existant. I guess it must have been a Gentoo installation error as portage updates quite frequently. Thanks ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] arptables-legacy
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 arptables bianry. However, I *do* see this one: /sbin/arptables-legacy That's why I think Gentoo needs to be explicitly told that it should install iptables-compatible software. Otherwise, it will not and Shorewall will fail. ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] arptables-legacy
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" logic in it: https://gitweb.gentoo.org/repo/gentoo.git/tree/net-firewall/iptables/iptables-1.8.7.ebuild As well as the arptables ebuild: https://gitweb.gentoo.org/repo/gentoo.git/tree/net-firewall/arptables/arptables-0.0.5-r1.ebuild as in the form of: eselect arptables set xtables-nft-multi ebtables also has similar logic: https://gitweb.gentoo.org/repo/gentoo.git/tree/net-firewall/ebtables/ebtables-2.0.11-r3.ebuild ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] arptables-legacy
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). ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] arptables-legacy
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/arptables-legacy is present. > > Is it as simple as making a symlink, or am I facing a much bigger > > challenge here? > > What distribution and version is it Gentoo 5.10.52-gentoo-x86_64 > Did you try creating a symlink No because I did not have time to do so as it was supposed to replace a production server. I'm asking here so I can plan my next move. I'm wondering if arptables is obsolete, or if I may find other issues of this type. I prefer to have your thoughts before trying anything. Thanks, Vieri ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
[Shorewall-users] arptables-legacy
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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
[Shorewall-users] trouble with ICMP requests
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 https://lists.sourceforge.net/lists/listinfo/shorewall-users
[Shorewall-users] trouble with ICMP requests
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 in lan/lan1/lan13 zones: # tcpdump -n -i wan host 13.107.4.52 and icmp dropped privs to tcpdump tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on wan, link-type EN10MB (Ethernet), capture size 262144 bytes ^C 0 packets captured 36 packets received by filter 0 packets dropped by kernel The wan interface is for the wan zone (internet). However, I do see ICMP requests coming in on the local interface: # tcpdump -n -i lan.1 host 13.107.4.52 and icmp dropped privs to tcpdump tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on lan.1, link-type EN10MB (Ethernet), capture size 262144 bytes 11:07:30.787799 IP 10.215.111.210 > 13.107.4.52: ICMP echo request, id 1, seq 30901, length 40 11:07:35.570882 IP 10.215.111.210 > 13.107.4.52: ICMP echo request, id 1, seq 30902, length 40 If I trace ICMP traffic for the other 2 IP addresses I can see both requests and replies on the wan interface: # tcpdump -n -i wan host 13.107.4.51 and icmp dropped privs to tcpdump tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on wan, link-type EN10MB (Ethernet), capture size 262144 bytes 11:10:32.783603 IP 10.215.111.210 > 13.107.4.51: ICMP echo request, id 1, seq 30918, length 40 11:10:32.798775 IP 13.107.4.51 > 10.215.111.210: ICMP echo reply, id 1, seq 30918, length 40 11:10:33.788524 IP 10.215.111.210 > 13.107.4.51: ICMP echo request, id 1, seq 30919, length 40 11:10:33.803409 IP 13.107.4.51 > 10.215.111.210: ICMP echo reply, id 1, seq 30919, length 40 I have no special rule for 13.107.4.52 so I don't understand why the ICMP requests (or HTTP requests for that matter) are not going out the wan interface. Any clues? A shorewall dump taken while pinging from lan.1 host with IP addr. 10.215.111.210 to 13.107.4.52 can be found here: https://drive.google.com/file/d/1yMBPe1skzmg9Y5wzYXvKLsaQyPELHreu/view?usp=sharing Regards, Vieri ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] Routing issue
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 address(es) of your FW instead? Vieri ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] HTTPS ACK dropped
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-users/thread/CABLYT9j-KvM0JEwxoZ3xppoL5yxZqQe6qyEj0_wJJ8eecyE3nA%40mail.gmail.com/#msg37123538 > > I don't understand why you started yet another thread about it, losing track > of > the fact that Tom already responded to this. > > I found a 3 year old thread about the same thing. I didn't look to see if > there were more. > https://sourceforge.net/p/shorewall/mailman/shorewall-users/thread/895182215.2261393.1499675136681%40mail.yahoo.com/#msg35936684 I did not lose track of Tom's answer. I also referenced it on purpose so that the previous answer could be easily found. Thank you for also mentioning the 3-year-old post, but if you take a better look at it, the log messages are different. Back then, I had RST and dropNotSyn messages. Now I have ACK messages. Likewise, the most recent post deals with "ACK PSH FIN" messages. Hence, the reason why I created a new thread, but hey, you might be right. It might be the same thing -- I don't know. > BTW, you're the most frequent person to request support on this list by a wide > margin. Thank you for the very interesting and useful stats. Regards, Vieri ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
[Shorewall-users] HTTPS ACK dropped
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 /opt/fw/${FW_TYPE}_extra/rules.SECTION_ALL.FHM
?ENDIF
?SECTION ESTABLISHED
?IF $FW_TYPE
INCLUDE /opt/fw/${FW_TYPE}_extra/rules.SECTION_ESTABLISHED.FHM
?ENDIF
?SECTION RELATED
?IF $FW_TYPE
INCLUDE /opt/fw/${FW_TYPE}_extra/rules.SECTION_RELATED.FHM
?ENDIF
?SECTION INVALID
# accept FIN and RST to avoid DROP messages when conntrack entries are
deleted (need to be in NEW and INVALID)
FIN(ACCEPT) { SOURCE=all, DEST=all }
RST(ACCEPT) { SOURCE=all, DEST=all }
?SECTION UNTRACKED
?SECTION NEW
# accept FIN and RST to avoid DROP messages when conntrack entries are
deleted (need to be in NEW and INVALID)
FIN(ACCEPT) { SOURCE=all, DEST=all }
RST(ACCEPT) { SOURCE=all, DEST=all }
?IF $FW_TYPE
INCLUDE /opt/fw/${FW_TYPE}_extra/rules.SECTION_NEW.FHM
?ENDIF
However, I'm still getting messages like this one:
kernel: Shorewall:wan-lan1:DROP:IN=wan OUT=lan.1
MAC=ac:1f:6b:9b:85:06:30:85:a9:8e:b6:ab:08:00 SRC=52.114.128.43
DST=10.215.246.222 LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=13414 DF
PROTO=TCP SPT=443 DPT=50137 WINDOW=187 RES=0x00 ACK URGP=0
Please note that lan.1 to wan HTTPS traffic on port 443 is allowed.
I'm worried that these dropped ACKs may be causing some specific
software failures.
How can I make sure they are not dropped?
Or are they normal side-effects if the ACK came in way too late?
Vieri
___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] dhcp relay agent
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 some way of categorising them (e.g. using classes and > allow/deny statements). Right, thanks Simon. ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] dhcp relay agent
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 ISC dhcrelay, but it's actually because I changed the remote DHCP server's configuration. In ISC terminology I'd have to use "shared-network", and in Microsoft's lingo it would have to be superscope + scopes. Basically, I created an "empty" scope for my "relay agent IP address", then the "working" scope for the rest of clients. I can now remove the SNAT rule I added in Shorewall (it works great, but it's not necessary anymore). Thanks again, Vieri ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
[Shorewall-users] dhcp relay agent
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 addresses of lan.1 is within that scope (say, 10.215.111.254/24). When sniffing traffic on the remote DHCP server, I see that the source IP address is one of lan.1's but out of scope (eg. 10.215.144.91). I managed to "fix that" with an SNAT rule, so now I see that the source IP address is the "right one", eg. 10.215.111.254. However, a wireshark dump shows me that within the DHCP protocol messages (DHCP Discover) the "relay agent IP address" is still out of scope (eg. 10.215.144.91). I tried to search the dhcrelay man page to see if I could manually set this address. I don't believe there's any way SW can do this, right? This is more of a protocol issue, right? Regards, Vieri ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] shorewall and port mirroring on vlans
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 mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
[Shorewall-users] shorewall and port mirroring on vlans
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 these ports from $FW. kernel: Shorewall:OUTPUT:ACCEPT:IN= OUT=soc.50 SRC=192.168.245.1 DST=192.168.245.2 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=56827 DF PROTO=TCP SPT=36702 DPT=22 WINDOW=64240 RES=0x00 SYN URGP=0 kernel: Shorewall:INPUT:REJECT:IN=soc.50 OUT= MAC=ac:1f:6b:f5:b7:1a:00:50:56:92:76:e5:08:00 SRC=192.168.245.2 DST=192.168.245.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=22 DPT=36702 WINDOW=14480 RES=0x00 ACK SYN URGP=0 Here's the SW dump while trying to connect via ssh and http from 192.168.245.1 (FW) to 192.168.245.2 (soc50): https://drive.google.com/file/d/1qCtaE9VNG_qzD-_uZltWZjwun4_I61vf/view?usp=sharing What am I missing? ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
[Shorewall-users] shorewall and port mirroring on vlans
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 configured as "tagged VLAN ID 50". There are only a few other ports in this switch that have the same Tagged VLAN ID 50 where there are a few VMware ESXi hosts. These physical hosts run, among others, a virtual machine with one of its virtual interfaces in VLAN ID 50. This interface is supposed to receive all the network traffic I send it via port mirroring (it's a network traffic analyzer). I do not have system access to the SOC virtual machine, but it's network interface is configured like this: eth2 Link encap:Thernet HWaddr 00:50:56:92:76:E5 inet addr:192.168.245.2 Bcast:192.168.245.7 Mask:255.255.255.248 UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1 Now, if I wanted to make sure that there are no VLAN configuration errors in the root switch then would the following two nmap commands prove that the eth2 interface of the SOC VM is reachable through the soc.50 interface on my Shorewall router, hence demonstrating that hey are all in the right VLAN? # nmap -e soc.50 192.168.245.2 Starting Nmap 7.80 ( https://nmap.org ) at 2020-12-10 10:08 CET Nmap scan report for 192.168.245.2 Host is up (0.00030s latency). Not shown: 993 closed ports PORT STATE SERVICE 22/tcp open ssh 80/tcp open http 443/tcp open https 3306/tcp open mysql 5432/tcp open postgresql 5666/tcp open nrpe /tcp open abyss MAC Address: 00:50:56:92:76:E5 (VMware) Nmap done: 1 IP address (1 host up) scanned in 13.30 seconds # nmap -e soc 192.168.245.2 Starting Nmap 7.80 ( https://nmap.org ) at 2020-12-10 10:09 CET Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn Nmap done: 1 IP address (0 hosts up) scanned in 0.59 seconds If the above is OK I now need to find out why the SOC VM admin is reporting that its eth2 interface is not receivng any tcp traffic at all. An example one-minute dump would look something like this: # tcpdump -i eth2 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth2, link-type EN10MB (Ethernet), capture size 65535 bytes 11:10:32.442888 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:15:c5:f9:9a:4d (oui Unknown), length 300 11:10:33.824278 ARP, Request who-has 10.215.144.61 tell 10.215.144.62, length 46 11:10:40.850874 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:15:c5:f9:9a:4d (oui Unknown), length 300 11:10:48.603916 IP 10.215.147.148.netbios-dgm > 10.215.255.255.netbios-dgm: NBT UDP PACKET(138) 11:10:48.603959 IP 10.215.147.148.netbios-dgm > 10.215.255.255.netbios-dgm: NBT UDP PACKET(138) 11:10:50.727001 00:14:22:b1:f0:40 (oui Unknown) > Broadcast, ethertype Unknown (0x88a2), length 60: 0x: 1000 ff01 0x0010: 0x0020: .. 11:10:54.946143 ARP, Request who-has 10.215.145.80 tell 192.168.215.96, length 46 11:10:56.566752 ARP, Request who-has 10.215.246.101 tell 192.168.215.128, length 46 11:10:57.569831 ARP, Request who-has 10.215.246.101 tell 192.168.215.128, length 46 11:10:58.583229 ARP, Request who-has 10.215.246.101 tell 192.168.215.128, length 46 11:11:01.017122 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:15:c5:f9:9a:4d (oui Unknown), length 300 11:11:01.881836 ARP, Request who-has 10.215.144.31 tell 10.215.144.21, length 46 11:11:05.817536 ARP, Request who-has 10.215.144.62 tell 192.168.215.96, length 46 11:11:06.154704 ARP, Request who-has 10.215.144.31 tell 10.215.147.148, length 46 11:11:08.043224 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:13:72:47:1b:dc (oui Unknown), length 300 11:11:11.666233 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:15:c5:f9:9a:4d (oui Unknown), length 300 11:11:22.943389 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:15:c5:f9:9a:4d (oui Unknown), length 300 11:11:34.674216 ARP, Request who-has 10.215.246.101 tell 192.168.215.128, length 46 11:11:35.676505 ARP, Request who-has 10.215.246.101 tell 192.168.215.128, length 46 11:11:35.763314 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:15:c5:f9:9a:4d (oui Unknown), length 300 11:11:35.947354 ARP, Request who-has 10.215.144.62 tell 192.168.215.96, length 46 11:11:36.689890 ARP, Request who-has 10.215.246.101 tell 192.168.215.128, length 46 ^C 22 packets captured 22 packets received by filter 0 packets dropped by kernel This doesn't match the much bigger amount of traffic I see if I tcpdump -n -i soc.50 on the shorewall firewall. So for some reason the traffic is not proper
Re: [Shorewall-users] dhcrelay
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 both directions. Thanks, Tuomo. In this case, the DHCP service is listening on 10.215.137.54 and is in the "ibs" zone, but the DNS servers that are being "provisioned" in the DHCP response are in both the ibs and lan1 zones. You mention that clients should have unicast dhcp access to the DNS servers, so I guess that if they are in lan1, they don't need any specific rule for the DNS servers in the same zone but do require a rule for the DNS servers in another zone (ibs). In other words, the rule would be something like this: DHCPfwd(ACCEPT) lan1ibs:$DHCP_SERVER,$DNS_SERVERS Right? Regards, Vieri ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] dhcrelay
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/00.0.0.0/0
udp spts:67:68 dpts:67:68
Also, "sniffing" the UDP 67 DHCP requests going out on the "ibs" eth
interface should be enough to state that if the reply is not coming
back or if the remote FW does not see the DHCP requests, it should not
be because of a blocking rule in my SW router. Am I right?
Vieri
On Mon, Nov 23, 2020 at 3:12 PM Simon Matter wrote:
>
> > 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 10.215.137.54
> >
> > I allow "all" for now from lan1 to ibs and a tcpdump shos requests
> > only when there should be replies because the service in ibs is active
> > and accessible:
> >
> > IP 10.215.144.91.67 > 10.215.137.54.67: BOOTP/DHCP, Request from
> > a4:bb:6d:03:6d:c9, length 300
> >
> > I only recently added the dhcp option to both interfaces:
> >
> > 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?
>
> Simon
>
>
>
> ___
> Shorewall-users mailing list
> Shorewall-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/shorewall-users
___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] dhcrelay
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
interfaces with udev renaming.
___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users
[Shorewall-users] dhcrelay
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 10.215.137.54
I allow "all" for now from lan1 to ibs and a tcpdump shos requests
only when there should be replies because the service in ibs is active
and accessible:
IP 10.215.144.91.67 > 10.215.137.54.67: BOOTP/DHCP, Request from
a4:bb:6d:03:6d:c9, length 300
I only recently added the dhcp option to both interfaces:
lan1${IF_LAN}.1 routeback,arp_filter=1,proxyarp=1,dhcp
ibs $IF_IBS arp_filter=1,dhcp
I ran a "shorewall reload", not a restart.
Is it necessary to restart shorewall instead of reloading it?
Vieri
___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] routing error when reloading shorewall
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, Simon. ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
[Shorewall-users] routing error when reloading shorewall
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 $ADDR_GW_IBS$IF_IBS I get the above error as soon as I add the following line: main10.215.106.193/26 $ADDR_GW_IBS$IF_IBS Does anyone know why? Vieri ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] accept HTTP request / drop HTTP reply
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 you very much.
Wouldn't it be safe to enable this by default?
In which circumstances would you NOT recommend this?
Vieri
___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] accept HTTP request / drop HTTP reply
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 the shorewall log
> > when a user accesses a web page:
> >
> > kernel: Shorewall:wan-lan1:DROP:IN=wan OUT=lan.1
>
> Just an idea, is there some VLAN involved or why is the out interface
> named lan.1?
Yes, the HTTP client made a request from VLAN 1 (lan.1) to WAN. The
reply is rightfully coming from wan and going to lan.1.
Why do you ask?
My interfaces file contains:
lan ${IF_LAN} routeback,arp_filter=1,proxyarp=1
lan1${IF_LAN}.1 routeback,arp_filter=1,proxyarp=1
Vieri
___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] mangle TPROXY
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 traffic and SSL BUMP > for HTTPS. > > Let us know, Vieri, if this worked for you. Yes, Witek, it works fine. I just want to point out that it was also working when using https_port tproxy sslbump in Squid and TPROXY() in SW just as long as I specified one port at a time. The system was behaving as a MITM and analyzing HTTPS traffic on all ports. Anyway, from a pragmatic point of view if TPROXY can't be used on HTTPS then I'll be using REDIRECT. Thanks, Vieri ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
[Shorewall-users] accept HTTP request / drop HTTP reply
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: Shorewall:wan-lan1:DROP:IN=wan OUT=lan.1 MAC=ac:1f:6b:9b:85:06:30:85:a9:8e:b6:ab:08:00 SRC= DST=10.215.144.48 LEN=103 TOS=0x00 PREC=0x00 TTL=63 ID=63665 DF PROTO=TCP SPT=443 DPT=58011 WINDOW=140 RES=0x00 ACK PSH FIN URGP=0 Why is this packet dropped? I'm expecting it to be an HTTPS reply which should be allowed by the above rule. What can I do to debug this? Regards, Vieri ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] mangle TPROXY
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 seem to be setting your system up as in
https://shorewall.org/Shorewall_Squid_Usage.html#Firewall, right?
If so, that guide states that "HTTPS (normally TCP port 443) cannot be
proxied transparently" and only gives a config example with port 80.
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.
squid:
http_port 3129 tproxy
https_port 3130 intercept ssl-bump generate-host-certificates=on
dynamic_cert_mem_cache_size=16MB cert=/etc/ssl/squid/proxyserver.pem
mangle:
DIVERT $IF_WAN $PROXY_SOURCE_WAN
tcp - 80
TPROXY(3129)${IF_LAN}:$PROXY_SOURCE_WAN $PROXY_DESTINATION_WAN
tcp 80
TPROXY(3129)${IF_LAN}.1:$PROXY_SOURCE_WAN $PROXY_DESTINATION_WAN
tcp 80
TPROXY(3129)${IF_LAN}.12:$PROXY_SOURCE_WAN $PROXY_DESTINATION_WAN
tcp 80
TPROXY(3129)${IF_LAN}.13:$PROXY_SOURCE_WAN $PROXY_DESTINATION_WAN
tcp 80
TPROXY(3129)${IF_LAN}.14:$PROXY_SOURCE_WAN $PROXY_DESTINATION_WAN
tcp 80
TPROXY(3129)${IF_LAN}.15:$PROXY_SOURCE_WAN $PROXY_DESTINATION_WAN
tcp 80
TPROXY(3129)${IF_LAN}.16:$PROXY_SOURCE_WAN $PROXY_DESTINATION_WAN
tcp 80
TPROXY(3129)${IF_LAN}.17:$PROXY_SOURCE_WAN $PROXY_DESTINATION_WAN
tcp 80
rules:
REDIRECT lan:$PROXY_SOURCE_WAN 3130tcp 443,8886
- !$PROXY_EXCLUSION_WAN
REDIRECT lan1:$PROXY_SOURCE_WAN 3130tcp 443,8886
- !$PROXY_EXCLUSION_WAN
REDIRECT lan12:$PROXY_SOURCE_WAN 3130tcp 443,8886
- !$PROXY_EXCLUSION_WAN
REDIRECT lan13:$PROXY_SOURCE_WAN 3130tcp 443,8886
- !$PROXY_EXCLUSION_WAN
REDIRECT lan14:$PROXY_SOURCE_WAN 3130tcp 443,8886
- !$PROXY_EXCLUSION_WAN
REDIRECT lan15:$PROXY_SOURCE_WAN 3130tcp 443,8886
- !$PROXY_EXCLUSION_WAN
REDIRECT lan16:$PROXY_SOURCE_WAN 3130tcp 443,8886
- !$PROXY_EXCLUSION_WAN
REDIRECT lan17:$PROXY_SOURCE_WAN 3130tcp 443,8886
- !$PROXY_EXCLUSION_WAN
REDIRECT lan18:$PROXY_SOURCE_WAN 3130tcp 443,8886
- !$PROXY_EXCLUSION_WAN
Thanks,
Vieri
___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] mangle TPROXY
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 can't do transparent proxy for https. You can "SSL bump", as in MITM, with Squid since v. 3, just as long as the organization/users import the proxy's certificate. HTTPS is transparently proxied. ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] mangle TPROXY
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:
> >
> > # METHOD 1:
> > DIVERT $IF_WAN $PROXY_SOURCE_WAN
> > tcp - 80
> > TPROXY(3129)${IF_LAN}:$PROXY_SOURCE_WAN $PROXY_DESTINATION_WAN
> > tcp 80
> > TPROXY(3129)${IF_LAN}.1:$PROXY_SOURCE_WAN $PROXY_DESTINATION_WAN
> > tcp 80
> > TPROXY(3129)${IF_LAN}.12:$PROXY_SOURCE_WAN $PROXY_DESTINATION_WAN
> > tcp 80
> > TPROXY(3129)${IF_LAN}.13:$PROXY_SOURCE_WAN $PROXY_DESTINATION_WAN
> > tcp 80
> > TPROXY(3129)${IF_LAN}.14:$PROXY_SOURCE_WAN $PROXY_DESTINATION_WAN
> > tcp 80
> > TPROXY(3129)${IF_LAN}.15:$PROXY_SOURCE_WAN $PROXY_DESTINATION_WAN
> > tcp 80
> > TPROXY(3129)${IF_LAN}.16:$PROXY_SOURCE_WAN $PROXY_DESTINATION_WAN
> > tcp 80
> > TPROXY(3129)${IF_LAN}.17:$PROXY_SOURCE_WAN $PROXY_DESTINATION_WAN
> > tcp 80
> > DIVERT $IF_WAN $PROXY_SOURCE_WAN
> > tcp - 443
> > TPROXY(3130)${IF_LAN}:$PROXY_SOURCE_WAN $PROXY_DESTINATION_WAN
> > tcp 443
> > TPROXY(3130)${IF_LAN}.1:$PROXY_SOURCE_WAN $PROXY_DESTINATION_WAN
> > tcp 443
> > TPROXY(3130)${IF_LAN}.12:$PROXY_SOURCE_WAN $PROXY_DESTINATION_WAN
> > tcp 443
> > TPROXY(3130)${IF_LAN}.13:$PROXY_SOURCE_WAN $PROXY_DESTINATION_WAN
> > tcp 443
> > TPROXY(3130)${IF_LAN}.14:$PROXY_SOURCE_WAN $PROXY_DESTINATION_WAN
> > tcp 443
> > TPROXY(3130)${IF_LAN}.15:$PROXY_SOURCE_WAN $PROXY_DESTINATION_WAN
> > tcp 443
> > TPROXY(3130)${IF_LAN}.16:$PROXY_SOURCE_WAN $PROXY_DESTINATION_WAN
> > tcp 443
> > TPROXY(3130)${IF_LAN}.17:$PROXY_SOURCE_WAN $PROXY_DESTINATION_WAN
> > tcp 443
> > ## non-standard port
> > DIVERT $IF_WAN $PROXY_SOURCE_WAN
> > tcp - 8886
> > TPROXY(3130)${IF_LAN}:$PROXY_SOURCE_WAN $PROXY_DESTINATION_WAN
> > tcp 8886
> > TPROXY(3130)${IF_LAN}.1:$PROXY_SOURCE_WAN $PROXY_DESTINATION_WAN
> > tcp 8886
> > TPROXY(3130)${IF_LAN}.12:$PROXY_SOURCE_WAN $PROXY_DESTINATION_WAN
> > tcp 8886
> > TPROXY(3130)${IF_LAN}.13:$PROXY_SOURCE_WAN $PROXY_DESTINATION_WAN
> > tcp 8886
> > TPROXY(3130)${IF_LAN}.14:$PROXY_SOURCE_WAN $PROXY_DESTINATION_WAN
> > tcp 8886
> > TPROXY(3130)${IF_LAN}.15:$PROXY_SOURCE_WAN $PROXY_DESTINATION_WAN
> > tcp 8886
> > TPROXY(3130)${IF_LAN}.16:$PROXY_SOURCE_WAN $PROXY_DESTINATION_WAN
> > tcp 8886
> > TPROXY(3130)${IF_LAN}.17:$PROXY_SOURCE_WAN $PROXY_DESTINATION_WAN
> > tcp 8886
> >
> > I am also required to add an ACCEPT rule from LAN* to FW for ports tcp
> > 80,443,8886.
> > Finally, I also need to set SSL_ports and Safe_ports in squid conf to
> > include 8886 which is non-standard.
> >
> > So, METHOD 1 seems to work.
>
> I seriously doubt that the TLS handshake works when you try using HTTPS.
> The proxy is a 'man in the middle' in that case.
>
> >
> > However, using a list of port numbers, ranges or ipsets does not seem to
> > work.
> >
> > For instance, the following in mangle does not work as expected.
> >
> > # METHOD 2
> > DIVERT $IF_WAN $PROXY_SOURCE_WAN
> > tcp - 80,443,8886
> > TPROXY(3129) ${IF_LAN}:$PROXY_SOURCE_WAN $PROXY_DESTINATION_WAN
> > tcp 80,443,8886
> > TPROXY(3129) ${IF_LAN}.1:$PROXY_SOURCE_WAN $PROXY_DESTINATION_WAN
> > tcp 80,443,8886
> > TPROXY(3129) ${IF_LAN}.12:$PROXY_SOURCE_WAN $PROXY_DESTINATION_WAN
> > tcp 80,443,8886
> > TPROXY(3129) ${IF_LAN}.13:$PROXY_SOURCE_WAN $PROXY_DESTINATION_WAN
> > tcp 80,443,8886
> > TPROXY(3129) ${IF_LAN}.14:$PROXY_SOURCE_WAN $PROXY_DESTINATION_WAN
> > tcp 80,443,8886
> > TPROXY(3129) ${IF_LAN}.15:$PROXY_SOURCE_WAN $PROXY_DESTINATION_WAN
> > tcp 80,443,8886
> > TPROXY(3129) ${IF_LAN}.16:$PROXY_SOURCE_WAN $PROXY_DESTINATION_WAN
> > tcp 80,443,8886
> > TPROXY(3129) ${IF_L
[Shorewall-users] mangle TPROXY
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 $PROXY_DESTINATION_WAN
tcp 80
TPROXY(3129)${IF_LAN}.1:$PROXY_SOURCE_WAN $PROXY_DESTINATION_WAN
tcp 80
TPROXY(3129)${IF_LAN}.12:$PROXY_SOURCE_WAN $PROXY_DESTINATION_WAN
tcp 80
TPROXY(3129)${IF_LAN}.13:$PROXY_SOURCE_WAN $PROXY_DESTINATION_WAN
tcp 80
TPROXY(3129)${IF_LAN}.14:$PROXY_SOURCE_WAN $PROXY_DESTINATION_WAN
tcp 80
TPROXY(3129)${IF_LAN}.15:$PROXY_SOURCE_WAN $PROXY_DESTINATION_WAN
tcp 80
TPROXY(3129)${IF_LAN}.16:$PROXY_SOURCE_WAN $PROXY_DESTINATION_WAN
tcp 80
TPROXY(3129)${IF_LAN}.17:$PROXY_SOURCE_WAN $PROXY_DESTINATION_WAN
tcp 80
DIVERT $IF_WAN $PROXY_SOURCE_WAN
tcp - 443
TPROXY(3130)${IF_LAN}:$PROXY_SOURCE_WAN $PROXY_DESTINATION_WAN
tcp 443
TPROXY(3130)${IF_LAN}.1:$PROXY_SOURCE_WAN $PROXY_DESTINATION_WAN
tcp 443
TPROXY(3130)${IF_LAN}.12:$PROXY_SOURCE_WAN $PROXY_DESTINATION_WAN
tcp 443
TPROXY(3130)${IF_LAN}.13:$PROXY_SOURCE_WAN $PROXY_DESTINATION_WAN
tcp 443
TPROXY(3130)${IF_LAN}.14:$PROXY_SOURCE_WAN $PROXY_DESTINATION_WAN
tcp 443
TPROXY(3130)${IF_LAN}.15:$PROXY_SOURCE_WAN $PROXY_DESTINATION_WAN
tcp 443
TPROXY(3130)${IF_LAN}.16:$PROXY_SOURCE_WAN $PROXY_DESTINATION_WAN
tcp 443
TPROXY(3130)${IF_LAN}.17:$PROXY_SOURCE_WAN $PROXY_DESTINATION_WAN
tcp 443
## non-standard port
DIVERT $IF_WAN $PROXY_SOURCE_WAN
tcp - 8886
TPROXY(3130)${IF_LAN}:$PROXY_SOURCE_WAN $PROXY_DESTINATION_WAN
tcp 8886
TPROXY(3130)${IF_LAN}.1:$PROXY_SOURCE_WAN $PROXY_DESTINATION_WAN
tcp 8886
TPROXY(3130)${IF_LAN}.12:$PROXY_SOURCE_WAN $PROXY_DESTINATION_WAN
tcp 8886
TPROXY(3130)${IF_LAN}.13:$PROXY_SOURCE_WAN $PROXY_DESTINATION_WAN
tcp 8886
TPROXY(3130)${IF_LAN}.14:$PROXY_SOURCE_WAN $PROXY_DESTINATION_WAN
tcp 8886
TPROXY(3130)${IF_LAN}.15:$PROXY_SOURCE_WAN $PROXY_DESTINATION_WAN
tcp 8886
TPROXY(3130)${IF_LAN}.16:$PROXY_SOURCE_WAN $PROXY_DESTINATION_WAN
tcp 8886
TPROXY(3130)${IF_LAN}.17:$PROXY_SOURCE_WAN $PROXY_DESTINATION_WAN
tcp 8886
I am also required to add an ACCEPT rule from LAN* to FW for ports tcp
80,443,8886.
Finally, I also need to set SSL_ports and Safe_ports in squid conf to
include 8886 which is non-standard.
So, METHOD 1 seems to work.
However, using a list of port numbers, ranges or ipsets does not seem to work.
For instance, the following in mangle does not work as expected.
# METHOD 2
DIVERT $IF_WAN $PROXY_SOURCE_WAN
tcp - 80,443,8886
TPROXY(3129) ${IF_LAN}:$PROXY_SOURCE_WAN $PROXY_DESTINATION_WAN
tcp 80,443,8886
TPROXY(3129) ${IF_LAN}.1:$PROXY_SOURCE_WAN $PROXY_DESTINATION_WAN
tcp 80,443,8886
TPROXY(3129) ${IF_LAN}.12:$PROXY_SOURCE_WAN $PROXY_DESTINATION_WAN
tcp 80,443,8886
TPROXY(3129) ${IF_LAN}.13:$PROXY_SOURCE_WAN $PROXY_DESTINATION_WAN
tcp 80,443,8886
TPROXY(3129) ${IF_LAN}.14:$PROXY_SOURCE_WAN $PROXY_DESTINATION_WAN
tcp 80,443,8886
TPROXY(3129) ${IF_LAN}.15:$PROXY_SOURCE_WAN $PROXY_DESTINATION_WAN
tcp 80,443,8886
TPROXY(3129) ${IF_LAN}.16:$PROXY_SOURCE_WAN $PROXY_DESTINATION_WAN
tcp 80,443,8886
TPROXY(3129) ${IF_LAN}.17:$PROXY_SOURCE_WAN $PROXY_DESTINATION_WAN
tcp 80,443,8886
Is there a reason why METHOD 2 is apparently wrong?
Would a shorewall dump be useful?
Vieri
___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] Cannot ping between hosts in the same zone but with different netmasks
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? > > > > If I just run 'shorewall iptrace' with no filter, won't that just > > trace all packets? > > > >> > I saved a tcpdump taken on the Shorewall system to a > >> > file and uploaded it here: > >> > > >> > > >> > https://drive.google.com/file/d/1waEUIIMHsPK0c-xAEyKkT2XSgNWrj5t3> > >> /view?usp=sharing > >> > > >> > I can see the reply in this dump, but frankly I don't know why > >> > it's not reaching the host at 10.215.246.24. The only thing I > >> > noticed in this dump is that the destination MAC is > >> > e8:ea:6a:0c:4c:1c. However, I see another MAC on the Shorewall > >> > gateway: > > > > OK, so this is really weird. > > > > Ping from host at 10.215.246.24 to host at 10.215.144.251: > > > > 1) echo request #1: src MAC is correct, dst MAC is that of lan.1 > > interface in Shorewall Firewall > > > > 2) echo request #2: src MAC is that of lan.1 interface in Shorewall > > Firewall, dst MAC is correct > > > > 3) first and only echo reply: src MAC is correct, dst MAC ( > > e8:ea:6a:0c:4c:1c ) is that of an interface on an older Shorewall > > router. > > > > So, that means that this particular client (an HP iLO system based on > > Linux) is still sending replies to an old Shorewall gateway I replaced > > 20 days ago. The interface to which this MAC addr belongs to isn't > > even online. > > I haven't found this MAC addr in any intermediate switch (ARP tables) > > so I'm guessing it must be in the client's ARP cache? > > > > Does this make sense? > > > > What could I try before asking the HP iLO admin to reboot that system? > > You said the HP ilo interface isn't even online but are you really sure > about it? If it's an ilo with dedicated ethernet port then it's usually > online as soon as the server is connected to power, even if the box is > switched off. And if you're looking for a system with ugly behavior, > things like ilo are good candidates because these embedded systems are not > always tested as good as normal operating systems. No, the off-line (ie. "down") interface I was referring to was one of the ethernet interfaces of my OLD shorewall router/gateway. So, just to be clear: a) more than 20 days ago I had a Shorewall gateway which was working fine, The hosts in this thread could ping each other. b) 20 days ago I changed the Shorewall gateway with new hardware and software. Only recently have I come to know that the hosts in this thread could not ping each other anymore. I'm assuming the origin of the problem is the change of the gateway because of the following observations. 1) an echo client with a given netmask sends a request to this HP iLO system with another netmask but attached to the same FW interface (lan.1 in my example) 2) the requests (2) are fine because they have the expected MAC addresses (src and dst). One of these MAC addresses is the one of lan.1 on the "new" Shorewall system. 3) oddly though, the reply captured with tcpdump (1) has a DST MAC address that points to an ethernet interface found on the "old" Shorewall system (this interface was previously used as "lan.1", so it had the same role). 4) the "old" Shorewall system's "lan.1" interface is offline (down). In other words, the old Shorewall system is history and that particular MAC address is nowhere to be found in the network, not even in the core switch. I don't have access to the HP iLO, but is it possible that it is sending the echo replies to the "old" MAC address because it hasn't refreshed its own ARP table? Not even after 20 days? Can I rule out a problem/misconfiguration on the "new" Shorewall gateway? If what I'm stating is correct, it seems that the HP iLO firmware has a bug or is misconfigured. Vieri ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] Cannot ping between hosts in the same zone but with different netmasks
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 system to a > > file and uploaded it here: > > > > > > https://drive.google.com/file/d/1waEUIIMHsPK0c-xAEyKkT2XSgNWrj5t3> > /view?usp=sharing > > > > I can see the reply in this dump, but frankly I don't know why > > it's not reaching the host at 10.215.246.24. The only thing I > > noticed in this dump is that the destination MAC is > > e8:ea:6a:0c:4c:1c. However, I see another MAC on the Shorewall > > gateway: OK, so this is really weird. Ping from host at 10.215.246.24 to host at 10.215.144.251: 1) echo request #1: src MAC is correct, dst MAC is that of lan.1 interface in Shorewall Firewall 2) echo request #2: src MAC is that of lan.1 interface in Shorewall Firewall, dst MAC is correct 3) first and only echo reply: src MAC is correct, dst MAC ( e8:ea:6a:0c:4c:1c ) is that of an interface on an older Shorewall router. So, that means that this particular client (an HP iLO system based on Linux) is still sending replies to an old Shorewall gateway I replaced 20 days ago. The interface to which this MAC addr belongs to isn't even online. I haven't found this MAC addr in any intermediate switch (ARP tables) so I'm guessing it must be in the client's ARP cache? Does this make sense? What could I try before asking the HP iLO admin to reboot that system? Vieri ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] Cannot ping between hosts in the same zone but with different netmasks
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 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 > > Jul 10 10:38:34 inf-fw1 kernel: TRACE: raw:PREROUTING:policy:13 > > IN=lan.1 OUT= MAC=ac:1f:6b:f5:b7:1b:00:50:56:b6:1f:15:08:00 > > SRC=10.215.246.24 DST=10.215.144.251 LEN=60 TOS=0x00 PREC=0x00 TTL=128 > > ID=21549 PROTO=ICMP TYPE=8 CODE=0 ID=512 SEQ=26368 > ... > > Jul 10 10:39:07 inf-fw1 kernel: TRACE: mangle:POSTROUTING:policy:1 IN= > > OUT=lan.1 SRC=10.215.246.24 DST=10.215.144.251 LEN=60 TOS=0x00 > > PREC=0x00 TTL=127 ID=21632 PROTO=ICMP TYPE=8 CODE=0 ID=512 SEQ=27904 > > > > This is an updated dump: > > > > https://drive.google.com/file/d/1ixZz0m7DaTDK54Wiu_sJMLUQxE7fjiVl/view?usp=sharing > > > > You have captured nothing but echo requests. We need to see the echo > replies. Well, that **IS** the issue. If I run the following on the Shorewall Firewall which is the default gateway: # tcpdump -n -i lan.1 "host 10.215.246.24 and host 10.215.144.251 and icmp or ( arp and ( host 10.215.144.251 or host 10.215.246.24 ) )" dropped privs to tcpdump tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on lan.1, link-type EN10MB (Ethernet), capture size 262144 bytes 11:10:15.279599 IP 10.215.246.24 > 10.215.144.251: ICMP echo request, id 512, seq 35584, length 40 11:10:15.279641 ARP, Request who-has 10.215.144.251 tell 10.215.144.91, length 28 11:10:15.279860 ARP, Reply 10.215.144.251 is-at 94:40:c9:26:dc:80, length 46 11:10:15.279880 IP 10.215.246.24 > 10.215.144.251: ICMP echo request, id 512, seq 35584, length 40 11:10:15.279996 IP 10.215.144.251 > 10.215.246.24: ICMP echo reply, id 512, seq 35584, length 40 11:10:20.671694 IP 10.215.246.24 > 10.215.144.251: ICMP echo request, id 512, seq 35840, length 40 11:10:20.671731 IP 10.215.246.24 > 10.215.144.251: ICMP echo request, id 512, seq 35840, length 40 11:10:20.671866 IP 10.215.144.251 > 10.215.246.24: ICMP echo reply, id 512, seq 35840, length 40 11:10:26.171698 IP 10.215.246.24 > 10.215.144.251: ICMP echo request, id 512, seq 36096, length 40 11:10:26.171734 IP 10.215.246.24 > 10.215.144.251: ICMP echo request, id 512, seq 36096, length 40 11:10:26.171875 IP 10.215.144.251 > 10.215.246.24: ICMP echo reply, id 512, seq 36096, length 40 11:10:31.671544 IP 10.215.246.24 > 10.215.144.251: ICMP echo request, id 512, seq 36352, length 40 11:10:31.671567 IP 10.215.246.24 > 10.215.144.251: ICMP echo request, id 512, seq 36352, length 40 11:10:31.671807 IP 10.215.144.251 > 10.215.246.24: ICMP echo reply, id 512, seq 36352, length 40 I can see the duplicated echo requests and a single echo reply. However, if I run 'shorewall iptrace", and then I grep all occurrences of 'TRACE' I can only see echo requests with SRC=10.215.246.24. > And please try to look at it yourself before sending it to me -- I'm not > your personal IP troubleshooter. I did, and I'm lost here as 'shorewall iptrace' did not show the replies. So I saved a tcpdump taken on the Shorewall system to a file and uploaded it here: https://drive.google.com/file/d/1waEUIIMHsPK0c-xAEyKkT2XSgNWrj5t3/view?usp=sharing I can see the reply in this dump, but frankly I don't know why it's not reaching the host at 10.215.246.24. The only thing I noticed in this dump is that the destination MAC is e8:ea:6a:0c:4c:1c. However, I see another MAC on the Shorewall gateway: # ip neigh show | grep 10.215.246.24 10.215.246.24 dev lan.1 lladdr 00:50:56:b6:1f:15 REACHABLE And, still on the Shorewall gateway: # ip neigh show | grep e8:ea:6a:0c:4c:1c # ip a s | grep e8:ea:6a:0c:4c:1c So I'm searching for that MAC addr. I know that the host at 10.215.246.24 is a vmware virtual machine so that MAC could be one of its interfaces. Even if it were, what could I try next? Could the echo replies be reaching the vmware host but not the VM somehow? Also, why are we seeing duplicate requests and when the ping completes, duplicate replies? Thanks for your help, Vieri ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] Cannot ping between hosts in the same zone but with different netmasks
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 Jul 10 10:38:34 inf-fw1 kernel: TRACE: raw:PREROUTING:policy:13 IN=lan.1 OUT= MAC=ac:1f:6b:f5:b7:1b:00:50:56:b6:1f:15:08:00 SRC=10.215.246.24 DST=10.215.144.251 LEN=60 TOS=0x00 PREC=0x00 TTL=128 ID=21549 PROTO=ICMP TYPE=8 CODE=0 ID=512 SEQ=26368 Jul 10 10:38:34 inf-fw1 kernel: TRACE: mangle:PREROUTING:rule:1 IN=lan.1 OUT= MAC=ac:1f:6b:f5:b7:1b:00:50:56:b6:1f:15:08:00 SRC=10.215.246.24 DST=10.215.144.251 LEN=60 TOS=0x00 PREC=0x00 TTL=128 ID=21549 PROTO=ICMP TYPE=8 CODE=0 ID=512 SEQ=26368 Jul 10 10:38:34 inf-fw1 kernel: TRACE: mangle:PREROUTING:policy:24 IN=lan.1 OUT= MAC=ac:1f:6b:f5:b7:1b:00:50:56:b6:1f:15:08:00 SRC=10.215.246.24 DST=10.215.144.251 LEN=60 TOS=0x00 PREC=0x00 TTL=128 ID=21549 PROTO=ICMP TYPE=8 CODE=0 ID=512 SEQ=26368 Jul 10 10:38:34 inf-fw1 kernel: TRACE: mangle:FORWARD:rule:1 IN=lan.1 OUT=lan.1 MAC=ac:1f:6b:f5:b7:1b:00:50:56:b6:1f:15:08:00 SRC=10.215.246.24 DST=10.215.144.251 LEN=60 TOS=0x00 PREC=0x00 TTL=127 ID=21549 PROTO=ICMP TYPE=8 CODE=0 ID=512 SEQ=26368 Jul 10 10:38:34 inf-fw1 kernel: TRACE: mangle:FORWARD:policy:2 IN=lan.1 OUT=lan.1 MAC=ac:1f:6b:f5:b7:1b:00:50:56:b6:1f:15:08:00 SRC=10.215.246.24 DST=10.215.144.251 LEN=60 TOS=0x00 PREC=0x00 TTL=127 ID=21549 PROTO=ICMP TYPE=8 CODE=0 ID=512 SEQ=26368 Jul 10 10:38:34 inf-fw1 kernel: TRACE: filter:FORWARD:rule:3 IN=lan.1 OUT=lan.1 MAC=ac:1f:6b:f5:b7:1b:00:50:56:b6:1f:15:08:00 SRC=10.215.246.24 DST=10.215.144.251 LEN=60 TOS=0x00 PREC=0x00 TTL=127 ID=21549 PROTO=ICMP TYPE=8 CODE=0 ID=512 SEQ=26368 Jul 10 10:38:34 inf-fw1 kernel: TRACE: filter:lan1_frwd:rule:3 IN=lan.1 OUT=lan.1 MAC=ac:1f:6b:f5:b7:1b:00:50:56:b6:1f:15:08:00 SRC=10.215.246.24 DST=10.215.144.251 LEN=60 TOS=0x00 PREC=0x00 TTL=127 ID=21549 PROTO=ICMP TYPE=8 CODE=0 ID=512 SEQ=26368 Jul 10 10:38:34 inf-fw1 kernel: TRACE: filter:~comb266:rule:1 IN=lan.1 OUT=lan.1 MAC=ac:1f:6b:f5:b7:1b:00:50:56:b6:1f:15:08:00 SRC=10.215.246.24 DST=10.215.144.251 LEN=60 TOS=0x00 PREC=0x00 TTL=127 ID=21549 PROTO=ICMP TYPE=8 CODE=0 ID=512 SEQ=26368 Jul 10 10:38:34 inf-fw1 kernel: TRACE: filter:dynamic:return:1 IN=lan.1 OUT=lan.1 MAC=ac:1f:6b:f5:b7:1b:00:50:56:b6:1f:15:08:00 SRC=10.215.246.24 DST=10.215.144.251 LEN=60 TOS=0x00 PREC=0x00 TTL=127 ID=21549 PROTO=ICMP TYPE=8 CODE=0 ID=512 SEQ=26368 Jul 10 10:38:34 inf-fw1 kernel: TRACE: filter:~comb266:return:3 IN=lan.1 OUT=lan.1 MAC=ac:1f:6b:f5:b7:1b:00:50:56:b6:1f:15:08:00 SRC=10.215.246.24 DST 10.215.144.251 LEN=60 TOS=0x00 PREC=0x00 TTL=127 ID=21549 PROTO=ICMP TYPE=8 CODE=0 ID=512 SEQ=26368 Jul 10 10:38:34 inf-fw1 kernel: TRACE: mangle:POSTROUTING:policy:1 IN= OUT=lan.1 SRC=10.215.246.24 DST=10.215.144.251 LEN=60 TOS=0x00 PREC=0x00 TTL=127 ID=21549 PROTO=ICMP TYPE=8 CODE=0 ID=512 SEQ=26368 Jul 10 10:38:56 inf-fw1 kernel: TRACE: raw:PREROUTING:policy:13 IN=lan.1 OUT= MAC=ac:1f:6b:f5:b7:1b:00:50:56:b6:1f:15:08:00 SRC=10.215.246.24 DST=10.215.144.251 LEN=60 TOS=0x00 PREC=0x00 TTL=128 ID=21613 PROTO=ICMP TYPE=8 CODE=0 ID=512 SEQ=27392 Jul 10 10:38:56 inf-fw1 kernel: TRACE: mangle:PREROUTING:rule:1 IN=lan.1 OUT= MAC=ac:1f:6b:f5:b7:1b:00:50:56:b6:1f:15:08:00 SRC=10.215.246.24 DST=10.215.144.251 LEN=60 TOS=0x00 PREC=0x00 TTL=128 ID=21613 PROTO=ICMP TYPE=8 CODE=0 ID=512 SEQ=27392 Jul 10 10:38:56 inf-fw1 kernel: TRACE: mangle:PREROUTING:policy:24 IN=lan.1 OUT= MAC=ac:1f:6b:f5:b7:1b:00:50:56:b6:1f:15:08:00 SRC=10.215.246.24 DST=10.215.144.251 LEN=60 TOS=0x00 PREC=0x00 TTL=128 ID=21613 PROTO=ICMP TYPE=8 CODE=0 ID=512 SEQ=27392 Jul 10 10:38:56 inf-fw1 kernel: TRACE: mangle:FORWARD:rule:1 IN=lan.1 OUT=lan.1 MAC=ac:1f:6b:f5:b7:1b:00:50:56:b6:1f:15:08:00 SRC=10.215.246.24 DST=10.215.144.251 LEN=60 TOS=0x00 PREC=0x00 TTL=127 ID=21613 PROTO=ICMP TYPE=8 CODE=0 ID=512 SEQ=27392 Jul 10 10:38:56 inf-fw1 kernel: TRACE: mangle:FORWARD:policy:2 IN=lan.1 OUT=lan.1 MAC=ac:1f:6b:f5:b7:1b:00:50:56:b6:1f:15:08:00 SRC=10.215.246.24 DST=10.215.144.251 LEN=60 TOS=0x00 PREC=0x00 TTL=127 ID=21613 PROTO=ICMP TYPE=8 CODE=0 ID=512 SEQ=27392 Jul 10 10:38:56 inf-fw1 kernel: TRACE: filter:FORWARD:rule:3 IN=lan.1 OUT=lan.1 MAC=ac:1f:6b:f5:b7:1b:00:50:56:b6:1f:15:08:00 SRC=10.215.246.24 DST=10.215.144.251 LEN=60 TOS=0x00 PREC=0x00 TTL=127 ID=21613 PROTO=ICMP TYPE=8 CODE=0 ID=512 SEQ=27392 Jul 10 10:38:56 inf-fw1 kernel: TRACE: filter:lan1_frwd:rule:3 IN=lan.1 OUT=lan.1 MAC=ac:1f:6b:f5:b7:1b:00:50:56:b6:1f:15:08:00 SRC=10.215.246.24 DST=10.215.144.251 LEN=60 TOS=0x00 PREC=0x00 TTL=127 ID=21613 PROTO=ICMP TYPE=8 CODE=0 ID=512 SEQ=27392 Jul 10 10:38:56 inf-fw1 kernel: TRACE: filter:~comb266:rule:1 IN=lan.1 OUT=lan.1 MAC=ac:1f:6b:f5:b7:1b:00:50:56:b6:1f:15:08:00 SRC=10.215.246.24 DST=10.215.144.251 LEN=60 TOS=0x00 PREC=0x00 TTL=127 ID=21613 PROTO=ICMP TYPE=8 CODE=0 ID=512 SEQ=27392 Jul 10 10:38:56 inf-fw1
Re: [Shorewall-users] Cannot ping between hosts in the same zone but with different netmasks
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 and host 10.215.144.48 and icmp dropped privs to tcpdump tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on lan.1, link-type EN10MB (Ethernet), capture size 262144 bytes 00:52:22.403575 IP 10.215.246.24 > 10.215.144.48: ICMP echo request, id 512, seq 57089, length 40 00:52:22.403608 IP 10.215.246.24 > 10.215.144.48: ICMP echo request, id 512, seq 57089, length 40 00:52:22.403847 IP 10.215.144.48 > 10.215.246.24: ICMP echo reply, id 512, seq 57089, length 40 00:52:22.403880 IP 10.215.144.48 > 10.215.246.24: ICMP echo reply, id 512, seq 57089, length 40 00:52:23.397689 IP 10.215.246.24 > 10.215.144.48: ICMP echo request, id 512, seq 57345, length 40 00:52:23.397723 IP 10.215.246.24 > 10.215.144.48: ICMP echo request, id 512, seq 57345, length 40 00:52:23.398006 IP 10.215.144.48 > 10.215.246.24: ICMP echo reply, id 512, seq 57345, length 40 00:52:23.398043 IP 10.215.144.48 > 10.215.246.24: ICMP echo reply, id 512, seq 57345, length 40 00:52:24.397645 IP 10.215.246.24 > 10.215.144.48: ICMP echo request, id 512, seq 57601, length 40 00:52:24.397676 IP 10.215.246.24 > 10.215.144.48: ICMP echo request, id 512, seq 57601, length 40 00:52:24.397963 IP 10.215.144.48 > 10.215.246.24: ICMP echo reply, id 512, seq 57601, length 40 00:52:24.397999 IP 10.215.144.48 > 10.215.246.24: ICMP echo reply, id 512, seq 57601, length 40 00:52:25.397765 IP 10.215.246.24 > 10.215.144.48: ICMP echo request, id 512, seq 57857, length 40 00:52:25.397784 IP 10.215.246.24 > 10.215.144.48: ICMP echo request, id 512, seq 57857, length 40 00:52:25.398095 IP 10.215.144.48 > 10.215.246.24: ICMP echo reply, id 512, seq 57857, length 40 00:52:25.398122 IP 10.215.144.48 > 10.215.246.24: ICMP echo reply, id 512, seq 57857, length 40 00:52:26.397606 IP 10.215.246.24 > 10.215.144.48: ICMP echo request, id 512, seq 58113, length 40 00:52:26.397631 IP 10.215.246.24 > 10.215.144.48: ICMP echo request, id 512, seq 58113, length 40 00:52:26.397914 IP 10.215.144.48 > 10.215.246.24: ICMP echo reply, id 512, seq 58113, length 40 00:52:26.397950 IP 10.215.144.48 > 10.215.246.24: ICMP echo reply, id 512, seq 58113, length 40 00:52:27.397666 IP 10.215.246.24 > 10.215.144.48: ICMP echo request, id 512, seq 58369, length 40 00:52:27.397696 IP 10.215.246.24 > 10.215.144.48: ICMP echo request, id 512, seq 58369, length 40 00:52:27.397957 IP 10.215.144.48 > 10.215.246.24: ICMP echo reply, id 512, seq 58369, length 40 00:52:27.397992 IP 10.215.144.48 > 10.215.246.24: ICMP echo reply, id 512, seq 58369, length 40 00:52:28.397652 IP 10.215.246.24 > 10.215.144.48: ICMP echo request, id 512, seq 58625, length 40 00:52:28.397687 IP 10.215.246.24 > 10.215.144.48: ICMP echo request, id 512, seq 58625, length 40 00:52:28.397985 IP 10.215.144.48 > 10.215.246.24: ICMP echo reply, id 512, seq 58625, length 40 00:52:28.398019 IP 10.215.144.48 > 10.215.246.24: ICMP echo reply, id 512, seq 58625, length 40 For the "failing ping", I now see this dump (in my previous post, I wasn't seeing any replies at all, only requests and not even duplicated -- beats me): # tcpdump -n -i lan.1 host 10.215.246.24 and host 10.215.144.251 and icmp dropped privs to tcpdump tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on lan.1, link-type EN10MB (Ethernet), capture size 262144 bytes 00:55:18.397038 IP 10.215.246.24 > 10.215.144.251: ICMP echo request, id 512, seq 60161, length 40 00:55:18.397079 IP 10.215.246.24 > 10.215.144.251: ICMP echo request, id 512, seq 60161, length 40 00:55:18.397202 IP 10.215.144.251 > 10.215.246.24: ICMP echo reply, id 512, seq 60161, length 40 00:55:23.896969 IP 10.215.246.24 > 10.215.144.251: ICMP echo request, id 512, seq 60417, length 40 00:55:23.897007 IP 10.215.246.24 > 10.215.144.251: ICMP echo request, id 512, seq 60417, length 40 00:55:23.897177 IP 10.215.144.251 > 10.215.246.24: ICMP echo reply, id 512, seq 60417, length 40 00:55:29.397134 IP 10.215.246.24 > 10.215.144.251: ICMP echo request, id 512, seq 60673, length 40 00:55:29.397170 IP 10.215.246.24 > 10.215.144.251: ICMP echo request, id 512, seq 60673, length 40 00:55:29.397337 IP 10.215.144.251 > 10.215.246.24: ICMP echo reply, id 512, seq 60673, length 40 00:55:34.896823 IP 10.215.246.24 > 10.215.144.251: ICMP echo request, id 512, seq 60929, length 40 00:55:34.896859 IP 10.215.246.24 > 10.215.144.251: ICMP echo request, id 512, seq 60929, length 40 00:55:34.897084 IP 10.215.144.251 > 10.215.246.24: ICMP echo reply, id 512, seq 60929, length 40 00:55:40.396974 IP 10.215.246.24 > 10.215.144.251: ICMP echo request, id 512, seq 61185, length 40 00:55:40.397012 IP 10.215.246.24 > 10.215.144.251: ICMP echo request, id 512, seq 61185, length
[Shorewall-users] Cannot ping between hosts in the same zone but with different netmasks
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 255.255.254.0 default gateway 10.215.246.91 (Shorewall Firewall) The host with IP addr. 10.215.144.251 is a Linux machine with these settings: netmask 255.255.254.0 default gateway 10.215.144.91 (Shorewall Firewall) >From the Shorewall Firewall I can ping any one of these two hosts. The Linux host can ping 10.215.144.91, but it cannot ping 10.215.246.91 or any other IP addr. in the 10.215.246.x-10.215.247.x range. When it tries to ping a host in that range (eg. 10.215.246.24) then I see this on the Shorewall Firewall: # tcpdump -n -i lan.1 host 10.215.246.24 and host 10.215.144.251 dropped privs to tcpdump tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on lan.1, link-type EN10MB (Ethernet), capture size 262144 bytes 17:36:57.093732 IP 10.215.144.251 > 10.215.246.24: ICMP echo request, id 224, seq 256, length 40 Any other host in the 10.215.246.x-10.215.247.x range can however ping hosts in the 10.215.144.x-10.215.145.x range in the 'lan1' zone. So there's something fishy with this Linux host. Any suggestions? The Shorewall dump is here: https://drive.google.com/file/d/1EVOWDi5GvwEB_hvOW6twplPO6YZhy-3q/view?usp=sharing Regards, Vieri ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] HTTP client tries to connect but no answer
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 three: ppp1 has IP addr. 1.1.1.1, ppp2 has 2.2.2.2 and ppp3 has 3.3.3.3). However: # links -bind-address 1.1.1.1 http://4.4.4.4 -> FAILS (timeout) # links -bind-address 2.2.2.2 http://4.4.4.4 -> FAILS (timeout) # links -bind-address 3.3.3.3 http://4.4.4.4 -> connects and displays properly Any other web site other than 4.4.4.4 works fine on all 3 ppp links from the Shorewall system itself. A tcpdump on each failing ppp link while trying to connect shows what was observed in my previous post. Could this be simply that my ISP is failing to route this website properly when connecting through ppp1 and ppp2? Restarting the failing ppp links or rebooting the modems does not change anything. Would a Shorewall dump help somehow, or is it surely an ISP issue? The following workaround solves my problem for the time being, but I'd rather understand what's happening: MARK(3):P 0.0.0.0/0 4.4.4.4 Thanks, Vieri ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
[Shorewall-users] HTTP client tries to connect but no answer
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.
IP 1.1.1.1.42829 > 2.2.2.2.80: Flags [S], seq 2591556487, win 64240,
options [mss 1452,sackOK,TS val 836437644 ecr 0,nop,wscale 7], length
0
IP 1.1.1.1.58787 > 2.2.2.2.80: Flags [S], seq 423725894, win 64240,
options [mss 1452,sackOK,TS val 836439874 ecr 0,nop,wscale 7], length
0
IP 1.1.1.1.58787 > 2.2.2.2.80: Flags [S], seq 423725894, win 64240,
options [mss 1452,sackOK,TS val 836440898 ecr 0,nop,wscale 7], length
0
IP 1.1.1.1.58787 > 2.2.2.2.80: Flags [S], seq 423725894, win 64240,
options [mss 1452,sackOK,TS val 836442978 ecr 0,nop,wscale 7], length
0
IP 1.1.1.1.58787 > 2.2.2.2.80: Flags [S], seq 423725894, win 64240,
options [mss 1452,sackOK,TS val 836447031 ecr 0,nop,wscale 7], length
0
I see nothing in the shorewall log related to 2.2.2.2, and I have no
rule blocking it.
What should I be looking for?
I have CLAMPMSS=Yes on this Shorewall gateway.
Vieri
___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] trouble accessing RDP server through vpn tunnel
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 that was dropping 3389 because of: Inbound RDP Connection with TLS Security Protocol Requested I need to either change the signature action or make sure the RDP clients don't negotiate (eg. force RDP or NLA). Thanks, Vieri ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] rejected traffic when port mirror is up
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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
[Shorewall-users] trouble accessing RDP server through vpn tunnel
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 and host 192.168.146.98 dropped privs to tcpdump tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on tun146, link-type RAW (Raw IP), capture size 262144 bytes 09:12:10.665880 IP 192.168.146.98.51811 > 10.215.246.24.3389: Flags [S], seq 1273664527, win 64240, options [mss 1357,nop,wscale 8,nop,nop,sackOK], length 0 09:12:10.666468 IP 10.215.246.24.3389 > 192.168.146.98.51811: Flags [S.], seq 1353116740, ack 1273664528, win 64240, options [mss 1460,nop,wscale 0,nop,nop,sackO K], length 0 09:12:10.781841 IP 192.168.146.98.51811 > 10.215.246.24.3389: Flags [.], ack 1, win 1028, length 0 09:12:10.784384 IP 192.168.146.98.51811 > 10.215.246.24.3389: Flags [P.], seq 1:20, ack 1, win 1028, length 19 09:12:10.784868 IP 10.215.246.24.3389 > 192.168.146.98.51811: Flags [P.], seq 1:20, ack 20, win 64221, length 19 09:12:10.886544 IP 192.168.146.98.51811 > 10.215.246.24.3389: Flags [R.], seq 20, ack 20, win 0, length 0 09:12:19.496402 IP 192.168.146.98.51812 > 10.215.246.24.3389: Flags [S], seq 3446290954, win 64240, options [mss 1357,nop,wscale 8,nop,nop,sackOK], length 0 09:12:19.496955 IP 10.215.246.24.3389 > 192.168.146.98.51812: Flags [S.], seq 1218676088, ack 3446290955, win 64240, options [mss 1460,nop,wscale 0,nop,nop,sackO K], length 0 09:12:19.588388 IP 192.168.146.98.51812 > 10.215.246.24.3389: Flags [.], ack 1, win 1028, length 0 09:12:19.588423 IP 192.168.146.98.51812 > 10.215.246.24.3389: Flags [P.], seq 1:20, ack 1, win 1028, length 19 09:12:19.903475 IP 192.168.146.98.51812 > 10.215.246.24.3389: Flags [P.], seq 1:20, ack 1, win 1028, length 19 09:12:20.252426 IP 192.168.146.98.51812 > 10.215.246.24.3389: Flags [P.], seq 1:20, ack 1, win 1028, length 19 09:12:20.852404 IP 192.168.146.98.51812 > 10.215.246.24.3389: Flags [P.], seq 1:20, ack 1, win 1028, length 19 09:12:22.065761 IP 192.168.146.98.51812 > 10.215.246.24.3389: Flags [P.], seq 1:20, ack 1, win 1028, length 19 09:12:24.480485 IP 192.168.146.98.51812 > 10.215.246.24.3389: Flags [P.], seq 1:20, ack 1, win 1028, length 19 09:12:29.286545 IP 192.168.146.98.51812 > 10.215.246.24.3389: Flags [P.], seq 1:20, ack 1, win 1028, length 19 09:12:38.898649 IP 192.168.146.98.51812 > 10.215.246.24.3389: Flags [R.], seq 20, ack 1, win 0, length 0 Do you see anything in the shorewall dump that might suggest a FW issue? https://drive.google.com/file/d/1zpinkAFYA8BnaiQ4--YhRxGOKDq559kD/view?usp=sharing Regards, Vieri ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
[Shorewall-users] rejected traffic when port mirror is up
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 in the shorewall dump I posted below, I run something
like this in /etc/shorewall/started:
for lan_vid in 13 14 15
do
run_tc qdisc add dev ${IF_LAN}.${lan_vid} ingress
run_tc filter add dev ${IF_LAN}.${lan_vid} parent :
protocol all u32 match u8 0 0 action mirred egress mirror dev
$IF_SOC_VLAN
run_tc qdisc add dev ${IF_LAN}.${lan_vid} handle 1: root prio
run_tc filter add dev ${IF_LAN}.${lan_vid} parent 1:
protocol all u32 match u8 0 0 action mirred egress mirror dev
$IF_SOC_VLAN
done
This seemed to work fine before, but now I'm seeing a lot of rejected traffic.
For instance, just to list one example as there are many more in the
dump, traffic from host with IP address 10.215.144.80 in lan.1 ('lan1'
zone) to host with IP address_10.215.237.254 in 'ibs' zone on tcp port
2 should be allowed "from lan1 to ibs".
However, I'm seeing this:
kernel: Shorewall:FORWARD:REJECT:IN=soc OUT=ibs
MAC=ac:1f:6b:f5:b7:1a:00:50:56:b6:28:b2:08:00 SRC=10.215.144.80
DST=10.215.237.254 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=10326 DF
PROTO=TCP SPT=54218 DPT=2 WINDOW=5840 RES=0x00 SYN URGP=0
Why? And why is it affecting traffic from lan1 to ibs?
If I physically disconnect the ethernet cable on the 'soc' network
interface then the above mentioned traffic goes through with no
issues.
This is the SW dump:
https://drive.google.com/file/d/1_pdrU-3Ogds8XfSAtmwAr-qsj19635TK/view?usp=sharing
Regards,
Vieri
___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users
[Shorewall-users] explicit web proxy and packet marking
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 multiple providers / ISPs. In transparent tproxy mode, the HTTP requests on the Shorewall gateway are seen as coming from the users' client hosts (SRC IP addresses are the ones of the hosts where the web browsers are actually running). That allows me to mark traffic, and use different providers according to source P address ranges or other criteria. In the explicit setup, the Shorewall gateway only sees one IP address as HTTP source -- the one on the "first" Squid/Shorewall firewall. I presume that in this case there is NO WAY I can set up the Shorewall gateway to mangle traffic one way or the other depending on the "real" src IP address, right? Vieri ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
[Shorewall-users] ADD action exclude both ipset and port range
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 - !+POL_BL_EXCL,49152-65535 Vieri ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] wake-on-lan forwarding magic packet
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 from the other zone for now. I found a "hack" with socat here: https://unix.stackexchange.com/questions/77874/transform-a-udp-unicast-packet-into-a-broadcast/77877#77877 I'll give it a shot. Thanks, Vieri ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
[Shorewall-users] wake-on-lan forwarding magic packet
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. Not being a bridge (SW FW router), is it simply impossible to forward this kind of traffic? Regards, Vieri ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] unknown traffic
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 > >>> found any program using this port (58129 is supposed to be in the > >>> dynamic range). > >> > > You could set up a honeypot if it is always the same port or the same host. Both the SRC host and the port differ. Here's another recent example: IN=ppp3 OUT= MAC= SRC=2.1.3.4 DST=4.3.2.1.168 LEN=72 TOS=0x00 PREC=0x00 TTL=62 ID=3049 DF PROTO=UDP SPT=42001 DPT=39958 LEN=52 MARK=0x3 I don't know why I'm getting this traffic from supposedly "clean" hosts (no apparent threats). BTW if it were always on one port, would I "simply" need to TARPIT(honeypot) that port and then run something like tcpdump on the Shorewall box and on the port in question? If that were true then which interface should tcpdump use? In my examples above, should it be ppp3? Thanks, Vieri ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] unknown traffic
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. > > - 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 "legit" open ports are dropped for x > > amount of time. > > > > In general, this works fine. > > > > However, once in a while I get what seem to be false positives. > > > > For instance a known user usually connects fine to port 443 with an > > external IP address (1.2.3.4). Somehow, at some point Shorewall > > reports the following line in the log: > > > > 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 > > > > Looks like you are showing truncated udp log when you are talking about > tcp ports? I'm not sure I understand what you mean. I'm just pointing out that host with IP addr. 1.2.3.4 usually accesses our "published" HTTPS/HTTP services. No issues there. However, at times I can see that Shorewall reports traffic from that host but on UDP 58129 in this specific case. The user at that host says he/she does not use a program to connect to our public IP addresses via UDP 58129. So I'm trying to find out why this traffic was seen. > > The user has no idea what this UDP connection is for, and I haven't > > found any program using this port (58129 is supposed to be in the > > dynamic range). > > What dinamic range and are you sure of this? The Internet Assigned Numbers Authority (IANA) suggests the range 49152 to 65535 (215+214 to 216−1) for dynamic or private ports. So, 58129 is in this range. Vieri ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
[Shorewall-users] unknown traffic
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 "legit" open ports are dropped for x amount of time. In general, this works fine. However, once in a while I get what seem to be false positives. For instance a known user usually connects fine to port 443 with an external IP address (1.2.3.4). Somehow, at some point Shorewall reports the following line in the log: 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 found any program using this port (58129 is supposed to be in the dynamic range). In any case, there are similar examples with other UDP and TCP ports. So, could this really be unwanted/dangerous traffic, or am I being too conservative? Should I use TARPIT(honeypot) to see what kind of data is being sent in these cases? Does anyone have a working example to actually capture the data? Regards, Vieri ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] geoip problems
> 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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] geoip problems
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 debugging is a lot simpler. I haven't detected any mismatches since, or so it seems so far. You can import/convert Maxmind's databases to ipsets (eg. one ipset per country if you wish). Vieri ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] match state support
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: > > > > CONFIG_NETFILTER_XT_MATCH_STATE=m > > This code can be simulated with these commands at a shell prompt: > > iptables -N foo > iptables -A foo -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT > iptables -A foo -m state --state ESTABLISHED,RELATED -j ACCEPT > > One of the last two commands must succeed, so hopefully the error output > from those commands will give you a clue... I had a chance to do that today. However, I'm unable to figure out what it all means. This is the output for the above commands: iptables: Protocol wrong type for socket. iptables: Protocol wrong type for socket. # egrep 'STATE|CONNTRACK' /usr/src/linux/.config CONFIG_NEED_DMA_MAP_STATE=y CONFIG_PERF_EVENTS_INTEL_CSTATE=y CONFIG_ACPI_SYSTEM_POWER_STATES_SUPPORT=y CONFIG_ACPI_PROCESSOR_CSTATE=y # CONFIG_X86_INTEL_PSTATE is not set CONFIG_NF_CONNTRACK=y CONFIG_NF_CONNTRACK_SECMARK=y CONFIG_NF_CONNTRACK_PROCFS=y CONFIG_NF_CONNTRACK_FTP=y CONFIG_NF_CONNTRACK_IRC=y # CONFIG_NF_CONNTRACK_NETBIOS_NS is not set CONFIG_NF_CONNTRACK_SIP=y CONFIG_NETFILTER_XT_MATCH_CONNTRACK=y CONFIG_NETFILTER_XT_MATCH_STATE=y CONFIG_NF_CONNTRACK_IPV4=y CONFIG_NF_CONNTRACK_IPV6=y # CONFIG_VGASTATE is not set # CONFIG_CPU_HOTPLUG_STATE_CONTROL is not set A Shorewall dump reveals: Modules ip_set 35141 4 ip_set_hash_mac,ip_set_bitmap_port,ip_set_hash_n et,ip_set_hash_ip ip_set_bitmap_port 6270 1 ip_set_hash_ip 24681 14 ip_set_hash_mac13431 1 ip_set_hash_net27712 29 ip_tables 16491 3 iptable_mangle,iptable_filter,iptable_raw iptable_filter 2293 1 iptable_mangle 2066 0 iptable_raw 1918 0 nf_conntrack 109483 21 nf_conntrack_sip,nf_conntrack_proto_sctp,nf_con ntrack_irc,nf_conntrack_ftp,nf_nat_sip,nf_conntrack_tftp,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_proto_udplite,nf_conntrack_netbios _ns,nf_conntrack_proto_gre,nf_conntrack_h323,xt_conntrack,nf_nat_tftp,nf_nat nf_conntrack_amanda 3226 1 nf_nat_amanda nf_conntrack_broadcast 1709 1 nf_conntrack_netbios_ns nf_conntrack_ftp 13086 1 nf_nat_ftp nf_conntrack_h323 66414 0 nf_conntrack_irc6064 1 nf_nat_irc nf_conntrack_netbios_ns 1657 0 nf_conntrack_netlink29038 0 nf_conntrack_pptp 11804 0 nf_conntrack_proto_gre 7067 1 nf_conntrack_pptp nf_conntrack_proto_sctp14239 0 nf_conntrack_proto_udplite 4722 0 nf_conntrack_sane 5607 0 nf_conntrack_sip 24130 1 nf_nat_sip nf_conntrack_tftp 5729 1 nf_nat_tftp nf_log_common 3973 1 nf_log_ipv4 nf_log_ipv4 4447 0 nf_nat 17129 5 nf_nat_sip,nf_nat_irc,nf_nat_ftp,nf_nat_amanda,n f_nat_tftp nf_nat_amanda 1547 0 nf_nat_ftp 2722 0 nf_nat_irc 2291 0 nf_nat_sip 8546 0 nf_nat_tftp 1353 0 xt_LOG 2258 0 xt_NFLOG1529 0 xt_conntrack3656 0 ERROR: Your kernel lacks connection tracking and/or state matching -- Shorewa ll will not run on this system dmesg has this: [ 38.497693] nf_conntrack version 0.5.0 (65536 buckets, 262144 max) [ 38.521205] ctnetlink v0.93: registering with nfnetlink. [ 38.634761] xt_conntrack: cannot load conntrack support for proto=2 [ 38.641262] xt_conntrack: cannot load conntrack support for proto=2 [ 50.687185] xt_conntrack: cannot load conntrack support for proto=2 [ 50.690144] xt_conntrack: cannot load conntrack support for proto=2 [ 59.171524] xt_conntrack: cannot load conntrack support for proto=2 [ 59.178150] xt_conntrack: cannot load conntrack support for proto=2 If you have any suggestions they are very welcome. The reason I'm fiddling with different kernel versions is because of the NFQUEUE "misbehavior" I'm seeing in syslog (reported in another thread). Regards, Vieri ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] do not load some kernel modules
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 using totally different network cards/brands, ie. different drivers. They can't be all buggy... (well, hopefully) It also happened with an Intel igb, Intel xigbe and Broadcom NetExtreme (bnxt_en). I've yet to try out a Mellanox ConnectX5, but I'm ready to bet I'd get the same results. I think I've finally found a way to reproduce the problem, and asked for help on the LKML. The warning messages I reported (which *could* lead to a system hang after a long period running -- a week in my case) disappear if I stop using NFQUEUE. In my specific case I use NFQUEUE balance 0:5 with iptables-1.6.1. As an IPS I'm using suricata 5.0.1 with the following arguments (among others): -q 0 -q 1 -q 2 -q 3 -q 4 -q 5 I've reproduced this behavior with several recent Linux kernel versions. I've also asked for help on the Suricata mailing list. I configure NFQUEUE in Shorewall like so (I know it's not optimized -- I just generate these rules from a script which I need to improve): NFQUEUE(0:5) net1,net2,net3:!+IPS_BL,+POL_BL,+GEO_BL,+GEOIPS_BL,+GLOBAL_WL loc,dmz,fw tcp,udp6502,7071,7070- NFQUEUE(0:5)loc,dmz,fw net1,net2,net3:!+IPS_BL,+POL_BL,+GEO_BL,+GEOIPS_BL,+GLOBAL_WL tcp,udp-6502,7071,7070 NFQUEUE(0:5) net1,net2,net3:!+IPS_BL,+POL_BL,+GEO_BL,+GEOIPS_BL,+GLOBAL_WL loc,dmz,fw icmp NFQUEUE(0:5)loc,dmz,fw net1,net2,net3:!+IPS_BL,+POL_BL,+GEO_BL,+GEOIPS_BL,+GLOBAL_WL icmp NFQUEUE(0:5) net1,net2,net3:!+IPS_BL,+POL_BL,+GEO_BL,+GEOIPS_BL,+GLOBAL_WL loc,dmz,fw udp500,4500- NFQUEUE(0:5)loc,dmz,fw net1,net2,net3:!+IPS_BL,+POL_BL,+GEO_BL,+GEOIPS_BL,+GLOBAL_WL udp-500,4500 NFQUEUE(0:5) net1,net2,net3:!+IPS_BL,+POL_BL,+GEO_BL,+GEOIPS_BL,+GLOBAL_WL loc,dmz,fw 50 NFQUEUE(0:5)loc,dmz,fw net1,net2,net3:!+IPS_BL,+POL_BL,+GEO_BL,+GEOIPS_BL,+GLOBAL_WL 50 NFQUEUE(0:5) net1,net2,net3:!+IPS_BL,+POL_BL,+GEO_BL,+GEOIPS_BL,+GLOBAL_WL loc,dmz,fw 51 NFQUEUE(0:5)loc,dmz,fw net1,net2,net3:!+IPS_BL,+POL_BL,+GEO_BL,+GEOIPS_BL,+GLOBAL_WL 51 NFQUEUE(0:5) net1,net2,net3:!+IPS_BL,+POL_BL,+GEO_BL,+GEOIPS_BL,+GLOBAL_WL loc,dmz,fw tcp61196,61197,61198,21,80,443,3389,10444- NFQUEUE(0:5)loc,dmz,fw net1,net2,net3:!+IPS_BL,+POL_BL,+GEO_BL,+GEOIPS_BL,+GLOBAL_WL tcp-61196,61197,61198,21,80,443,3389,10444 [...] NFQUEUE(0:5)net1,net2,net3:!+IPS_BL,+POL_BL,+GLOBAL_WL,+EMAIL_WL loc,dmz,fw tcp25- NFQUEUE(0:5)loc,dmz,fw net1,net2,net3:!+IPS_BL,+POL_BL,+GLOBAL_WL,+EMAIL_WL tcp-25 [...] NFQUEUE(0:5) net1,net2,net3:!+IPS_BL,+POL_BL,+GEO_BL,+GEOIPS_BL,+GLOBAL_WL loc,dmz,fw tcp,udp6502,7071,7070- NFQUEUE(0:5)loc,dmz,fw net1,net2,net3:!+IPS_BL,+POL_BL,+GEO_BL,+GEOIPS_BL,+GLOBAL_WL tcp,udp-6502,7071,7070 NFQUEUE(0:5) net1,net2,net3:!+IPS_BL,+POL_BL,+GEO_BL,+GEOIPS_BL,+GLOBAL_WL loc,dmz,fw icmp NFQUEUE(0:5)loc,dmz,fw net1,net2,net3:!+IPS_BL,+POL_BL,+GEO_BL,+GEOIPS_BL,+GLOBAL_WL icmp NFQUEUE(0:5) net1,net2,net3:!+IPS_BL,+POL_BL,+GEO_BL,+GEOIPS_BL,+GLOBAL_WL loc,dmz,fw udp500,4500- NFQUEUE(0:5)loc,dmz,fw net1,net2,net3:!+IPS_BL,+POL_BL,+GEO_BL,+GEOIPS_BL,+GLOBAL_WL udp-500,4500 NFQUEUE(0:5) net1,net2,net3:!+IPS_BL,+POL_BL,+GEO_BL,+GEOIPS_BL,+GLOBAL_WL loc,dmz,fw 50 NFQUEUE(0:5)loc,dmz,fw net1,net2,net3:!+IPS_BL,+POL_BL,+GEO_BL,+GEOIPS_BL,+GLOBAL_WL 50 NFQUEUE(0:5) net1,net2,net3:!+IPS_BL,+POL_BL,+GEO_BL,+GEOIPS_BL,+GLOBAL_WL loc,dmz,fw 51 NFQUEUE(0:5)loc,dmz,fw net1,net2,net3:!+IPS_BL,+POL_BL,+GEO_BL,+GEOIPS_BL,+GLOBAL_WL 51 NFQUEUE(0:5) net1,net2,net3:!+IPS_BL,+POL_BL,+GEO_BL,+GEOIPS_BL,+GLOBAL_WL loc,dmz,fw tcp61196,61197,61198,21,80,443,3389,10444- NFQUEUE(0:5)loc,dmz,fw net1,net2,net3:!+IPS_BL,+POL_BL,+GEO_BL,+GEOIPS_BL,+GLOBAL_WL tcp-61196,61197,61198,21,80,443,3389,10444 [...] NFQUEUE(0:5)net1,net2,net3:!+IPS_BL,+POL_BL,+GLOBAL_WL,+EMAIL_WL loc,dmz,fw tcp25- NFQUEUE(0:5)loc,dmz,fw net1,net2,net3:!+IPS_BL,+POL_BL,+GLOBAL_WL,+EMAIL_WL tcp-25 They are in SECTION_ESTABLISHED SECTION_NEW SECTION_RELATED Just in case you have any suggestions... Thanks, Vieri ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] do not load some kernel modules
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 (that particular message, not the rest of the forum topic or related bug report), you will se that the same exact thing occurs on a system without this Intel driver. I now have a system without e1000, but it's still behaving the same way. In fact, it's currently using the bnxt driver. I'm ready to bet that if I use another NIC with a different driver, the same kernel traces will show up. I'm not saying xt_geoip is the culprit. I just need to get it out of the way for now so the kernel isn't tainted. Thanks, Vieri ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
[Shorewall-users] match state support
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 kernel/iptables do not include state match support." Grepping for the kernel option yields the following even for the new kernel: CONFIG_NETFILTER_XT_MATCH_STATE=m Is it because iptables must be recompiled? If so, won't I have trouble when trying to switch from one kernel to another when rebooting? Regards, Vieri ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] do not load some kernel modules
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 xtables-addons for years without issues, but recently I'm having nightmares. With recent kernels on different hardware I get very worrisome kernel traces in syslog. Things like: WARNING: CPU: 6 PID: 0 at net/ipv4/tcp_output.c:915 tcp_wfree.cold+0xc/0x13 It's always about tcp_output.c:915. Oh, and I've tried a whole bunch of kernel versions. I even suffered a system freeze/kernel panic after just one week of system uptime (the traces were the same). Regardless of the root cause, the main issue regarding xt_geoip and xtables-addons modules (that are not properly signed) was that whenever there's a trace, the kernel reports that it's tainted because of out-of-tree modules. People on the Linux Kernel mailing lists will simply ignore my bug reports if the kernel states that it's tainted. Further details here for those who might be curious: https://forums.gentoo.org/viewtopic-p-8419232.html?sid=ef4e980cc09c8f5029c827aa11d42f1b#8419232 So, yes, xt_geoip is great and probably faster than an ipset-based alternative. There's also some doubt as to whether xt_geoip can be used with nftables. Anyway, my main concern now are these dreaded kernel messages. Thanks, Vieri ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] do not load some kernel modules
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 set AUTOHELPERS to no. Anyway, it seems I found a trick that works for me. Instead of blacklisting the modules in modprobe.d, I use the "install" command and pass it a program such as /bin/true. /etc/modprobe.d/blacklist.conf blacklist xt_iface install xt_geoip /bin/true blacklist xt_TARPIT Now, xt_geoip is never loaded (nor are the other ones). Vieri ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
[Shorewall-users] do not load some kernel modules
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 xt_geoip xt_geoip 16384 0 Surely I could uninstall these modules from the system, but I'd rather not. How do I make sure xt_geoip is not loaded by Shorewall? Regards, Vieri ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
[Shorewall-users] Error: ipv4: FIB table does not exist.
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: ipv4: FIB table does not exist. Dump terminated I have iproute2-5.2.0. # shorewall status Shorewall-5.2.3.4 Status at gw2 - Wed Jan 29 09:06:56 CET 2020 Shorewall is running Should I panic or relax? Vieri ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
[Shorewall-users] shorewall geoip support
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 if it was useful. Are we supposed to change the GEOIPDIR variable to point to /usr/share/xt_geoip? Vieri ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] from Shorewall to Shorewall-Lite
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 member in order to add wiki pages. If you have suggestions for how to improve the wiki for this project, consider opening an issue in the issue tracker. unquote I can't see anything that allows me to create a wiki page. No hurry, of course. Happy holidays, Vieri ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] from Shorewall to Shorewall-Lite
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 so, do I need to file a bug report/issue within GitLab? Thanks, Vieri ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] Shorewall Stuck Providers
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 compilation option and it would pick up new > policy, interfaces, rules, etc. I expected it to pick up provider changes > as well. > > Thanks! > > > Connor Schlesiger > > > > Dec. 6, 2019, 1:00 p.m. by matd...@gmail.com: > > > > On 12/6/2019 6:27 PM, Connor Schlesiger wrote: > > Greetings, > > I've been attempting to use an anonymizing VPN service on my Arch Linux > router alongside Shorewall while also allowing SSH access to said machine. > > I decided to try and use providers 'NET' and 'VPN'. However, this did > not work, and I removed the entries in '/etc/shorewall/providers'. But > now after restarting Shorewall and restarting the machine, 'NET' and > 'VPN' persist in '/etc/iproute2/rt_tables'. If I remove them and restart > Shorewall, they return. It seems Shorewall is ignoring any changes I > make to '/etc/shorewall/providers'. > > Any help in clearing providers would be much appreciated. > > > Did compilation happen when you restarted Shorewall? > > -Matt > -- > Matt Darfeuille > > > ___ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users > > > ___ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users > ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] from Shorewall to Shorewall-Lite
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) warn me of this? Or do I need to make sure myself that all of my shorewall/-lite systems are alike? Vieri ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] from Shorewall to Shorewall-Lite
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 make your questions as simple as possible (not
> using variable ...).
Actually, I thought some kind of pseudo-code would be the clearest way
to explain things and avoid confusion.
I try to re-phrase then.
> Also, testing on none-production system might be a good thing.
I do that of course, but there's almost always a surprise when setting
it up on a production system.
> > b) rsync -a root@$SW_TARGET_SYSTEM_1:/etc/shorewall/
> > $SW_ADMINISTRATIVE_SYSTEM_TARGET_1_DIR/
> >
>
> Basically, you need to copy the configuration files from the firewall
> systems to the administrative system.
OK, I guess I can create a directory anywhere and to my liking, "as
long as I add it in CONFIG_PATH within shorewall.conf in that
directory". Is the second half of my sentence correct?
> > c) edit $SW_ADMINISTRATIVE_SYSTEM_TARGET_1_DIR/stoppedrules and add:
> > ACCEPT $SW_TARGET_SYSTEM_1_WHERE_ADM_IFACE:$SW_ADMINISTRATIVE_SYSTEM $FW
> > tcp 22
> >
> > [QUESTION] Is tcp/22 (ssh) enough?
> >
>
> Yes, see (1).
OK, I just wanted to make extra sure that only ssh is used (could be
any port, of course).
> > d) edit $SW_ADMINISTRATIVE_SYSTEM_TARGET_1_DIR/shorewall.conf and
> > modify CONFIG_PATH.
> >
> > [QUESTION] The current value (default) is:
> > CONFIG_PATH=":${CONFDIR}/shorewall:${SHAREDIR}/shorewall"
> > In my current example, does it have to be the following?
> > CONFIG_PATH=":${SW_ADMINISTRATIVE_SYSTEM_TARGET_1_DIR}:${SHAREDIR}/shorewall"
> >
>
> Can not answer this question without more information.
It's part of my earlier question (ignore it here).
> > 2) on shorewall-lite target system:
> >
> > a) install shorewall-lite (without uninstalling shorewall)
> >
>
> See (1).
The guide suggests to uninstall shorewall right away.
Here, I'm trying to keep both systems up so I can quickly revert.
> > b) /usr/share/shorewall-lite/shorecap > /tmp/capabilities
> > rsync -a /tmp/capabilities
> > root@$SW_ADMINISTRATIVE_SYSTEM:$SW_ADMINISTRATIVE_SYSTEM_TARGET_1_DIR/
> > rm /tmp/capabilities
> >
> > [QUESTION] Is the above destination path correct?
> >
>
> Use 'remote-getrc' to do that.
Do you mean I should use remote-getcaps from the adminsitrative
system? Isn't remote-getrc for shorewallrc?
>
> > d) rsync -a /usr/share/shorewall/shorewallrc
> > root@$SW_ADMINISTRATIVE_SYSTEM:$SW_ADMINISTRATIVE_SYSTEM_TARGET_1_DIR/
> > [QUESTION] Is this step necessary if I want to compile the firewall
> > script for testing purposes?
> >
>
> This file is required for compilation only.
So, if I need to compile then can I get it by running remote-getrc
from the administrative system?
> > 3) on shorewall administrative system:
> >
> > a)
> > cd $SW_ADMINISTRATIVE_SYSTEM_TARGET_1_DIR
> > shorewall -e $SW_ADMINISTRATIVE_SYSTEM_TARGET_1_DIR
> > /tmp/fw_$SW_TARGET_SYSTEM_1
> >
>
> Shorewall-lite only requires 'firewall' and firewall.conf'.
OK, but isn't my command generating the same script with a different name?
As far as EXPORTPARAMS is concerned, I'll leave it undefined.
> > = TEST ==
> >
> > To test the new compiled firewall script:
> >
> > 1) on shorewall administrative system:
> > rsync -a /tmp/fw_$SW_TARGET_SYSTEM_1 root@$SW_TARGET_SYSTEM_1:/tmp/
> >
>
> See (A) above.
So I just need to copy over the firewall.conf file as well.
> > PS:
> > 'shorewall remote-getcaps' is the same as using shorecap or as
> > 'shorewall-lite show -f capabilities'?
> >
>
> See (1) -- 'remote-getrc' and 'remote-getcaps' will pull the
> corresponding generated file to the administrative system.
Yes, but (1) indicates that "unlike the shorecap program, the show
capabilities command shows the kernel's current capabilities; it does
not attempt to load additional kernel modules". That's why I was
asking if remote-getcaps is more like shorecap or more like "show
capabilities".
Thanks a lot!
Vieri
___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users
[Shorewall-users] from Shorewall to Shorewall-Lite
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:
SW_ADMINISTRATIVE_SYSTEM=10.215.144.92
SW_TARGET_SYSTEM_1=10.215.144.91
SW_TARGET_SYSTEM_1_WHERE_ADM_IFACE=eth0
SW_ADMINISTRATIVE_SYSTEM_TARGET_1_DIR=/some/partition/elsewhere/shorewall/lite/1
1) on shorewall administrative system:
a) mkdir -p $SW_ADMINISTRATIVE_SYSTEM_TARGET_1_DIR
b) rsync -a root@$SW_TARGET_SYSTEM_1:/etc/shorewall/
$SW_ADMINISTRATIVE_SYSTEM_TARGET_1_DIR/
c) edit $SW_ADMINISTRATIVE_SYSTEM_TARGET_1_DIR/stoppedrules and add:
ACCEPT $SW_TARGET_SYSTEM_1_WHERE_ADM_IFACE:$SW_ADMINISTRATIVE_SYSTEM $FW tcp 22
[QUESTION] Is tcp/22 (ssh) enough?
d) edit $SW_ADMINISTRATIVE_SYSTEM_TARGET_1_DIR/shorewall.conf and
modify CONFIG_PATH.
[QUESTION] The current value (default) is:
CONFIG_PATH=":${CONFDIR}/shorewall:${SHAREDIR}/shorewall"
In my current example, does it have to be the following?
CONFIG_PATH=":${SW_ADMINISTRATIVE_SYSTEM_TARGET_1_DIR}:${SHAREDIR}/shorewall"
2) on shorewall-lite target system:
a) install shorewall-lite (without uninstalling shorewall)
b) /usr/share/shorewall-lite/shorecap > /tmp/capabilities
rsync -a /tmp/capabilities
root@$SW_ADMINISTRATIVE_SYSTEM:$SW_ADMINISTRATIVE_SYSTEM_TARGET_1_DIR/
rm /tmp/capabilities
[QUESTION] Is the above destination path correct?
c) [QUESTION] It's not clear to me where and how EXPORTPARAMS should
be set and why. Default is undefined.
Should I create it?
In which file?
In shorewall.conf
@$SW_ADMINISTRATIVE_SYSTEM:$SW_ADMINISTRATIVE_SYSTEM_TARGET_1_DIR/?
In shorewall.conf @$SW_ADMINISTRATIVE_SYSTEM:/etc/shorewall/?
d) rsync -a /usr/share/shorewall/shorewallrc
root@$SW_ADMINISTRATIVE_SYSTEM:$SW_ADMINISTRATIVE_SYSTEM_TARGET_1_DIR/
[QUESTION] Is this step necessary if I want to compile the firewall
script for testing purposes?
3) on shorewall administrative system:
a)
cd $SW_ADMINISTRATIVE_SYSTEM_TARGET_1_DIR
shorewall -e $SW_ADMINISTRATIVE_SYSTEM_TARGET_1_DIR /tmp/fw_$SW_TARGET_SYSTEM_1
= TEST ==
To test the new compiled firewall script:
1) on shorewall administrative system:
rsync -a /tmp/fw_$SW_TARGET_SYSTEM_1 root@$SW_TARGET_SYSTEM_1:/tmp/
2) on shorewall-lite target system (still has shorewall):
a) shorewall stop && /tmp/fw_$SW_TARGET_SYSTEM_1 start
b) make your tests.
b1) If errors:
/tmp/fw_$SW_TARGET_SYSTEM_1 stop ; shorewall start
Do your research, but at least everything is back up again and working.
b2) If OK:
connect to shorewall administrative system and run:
cd $SW_ADMINISTRATIVE_SYSTEM_TARGET_1_DIR
/sbin/shorewall remote-start $SW_TARGET_SYSTEM_1
and eventually:
/sbin/shorewall remote-reload $SW_TARGET_SYSTEM_1
Thanks,
Vieri
PS:
'shorewall remote-getcaps' is the same as using shorecap or as
'shorewall-lite show -f capabilities'?
___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] shorewall TEE and network congestion
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 ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] shorewall TEE and network congestion
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 intel based servers, so you are rather stuck with it in > that case. I might have to ask this question off-list, but it could be of general interest. What issues are you seeing with the X722? Do you have a link to a bug report? Thanks, Vieri ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
[Shorewall-users] run_tc or how to set up port mirroring with Shorewall
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 ]; then
if [ ! -z "${IF_SOC_VLAN}" ]; then
for lan_vid in 13 14 15
do
run_tc qdisc add dev ${IF_LAN}.${lan_vid} ingress
run_tc filter add dev ${IF_LAN}.${lan_vid} parent :
protocol all u32 match u8 0 0 action mirred egress mirror dev
$IF_SOC_VLAN
run_tc qdisc add dev ${IF_LAN}.${lan_vid} handle 1: root prio
run_tc filter add dev ${IF_LAN}.${lan_vid} parent 1:
protocol all u32 match u8 0 0 action mirred egress mirror dev
$IF_SOC_VLAN
done
fi
fi
This works fine, but is there a better way to do this within Shorewall?
Vieri
___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] create new routing table via providers
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 near the top. Then it's just a matter of issuing: > echo 1 > /proc/net/nf_condition/override_to_CAIB > to enable the bypass Thanks, Bill. I don't know if packet marking several destinations (I have quite a few) is more efficient than adding just one route rule between 2 routing tables. In any case, I can't try your solution just yet because my kernel or iptables or both do not support conditionals. # shorewall show capabilities | grep -i condition Condition Match (CONDITION_MATCH): Not available I'll try to update asap. Thanks for the great idea, though. Vieri ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
[Shorewall-users] create new routing table via providers
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 $IF_IBS] main10.0.0.0/8 $ADDR_GW_CAIB $IF_CAIB Basically, the idea is "route 10.0.0.0/8 via one provider but route specific 10.y.y.y via another provider". However, I also have other routes to specific interfaces or VLANs such as: main10.215.144.42 - $IF_VLAN_13 main10.215.144.43 - $IF_VLAN_15 The problem is that I require a quick way to by-pass the first set (providers IBS and CAIB above), but at the same time keep the second set valid (IF_VLAN_*). This is what shows up in my current 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 1: from all fwmark 0x1/0xff lookup WAN 10001: from all fwmark 0x2/0xff lookup CAIB 10002: from all fwmark 0x3/0xff lookup IBS 2: from 172.16.0.1 lookup WAN 2: from 172.20.11.62 lookup CAIB 2: from 172.28.17.105 lookup IBS 32765: from all lookup balance 32767: from all lookup default Table CAIB: [snip] Table HMAN: [snip] Table IBS: [snip] If I were to quickly by-pass the first set (providers IBS and CAIB) without reloading Shorewall and send all the packets via CAIB, I'd insert a rule with priority 998 such as: from all to 10.0.0.0/8 lookup CAIB That's one run on the command line, quick and easy. However, that would also send traffic normally destined for IF_VLAN_* to CAIB. How can I avoid that (too many rules to change them one by one)? So I thought that if I could create a new table containing the IF_VLAN_* routes with a lower priority value than the main table's then I could insert that rule right after it. It would look something like this (HMAN custom table): 0: from all lookup local 1: from all fwmark 0x200/0x200 lookup Tproxy 220:from all lookup 220 990:from all lookup HMAN 999:from all lookup main 1: from all fwmark 0x1/0xff lookup WAN 10001: from all fwmark 0x2/0xff lookup CAIB 10002: from all fwmark 0x3/0xff lookup IBS 2: from 172.16.0.1 lookup WAN 2: from 172.20.11.62 lookup CAIB 2: from 172.28.17.105 lookup IBS 32765: from all lookup balance 32767: from all lookup default I could then run this from the command line in case I needed it: # ip rule add pref 995 from all to 10.0.0.0/8 lookup CAIB That would keep the IF_VLAN_* routes valid/usable, but at the same time by-pass the IBS/CAIB routes. How can I tell Shorewall to do this for me? I presume it's supposed to be through the providers file. However, I don't understand why the INTERFACE column is required. If I put one like in this example (I picked a random interface for no particular reason): HMAN5 - - $IF_DMZ none then Shorewall generates these routing rules (added to the previous ones): 10004: from all fwmark 0x4/0xff lookup HMAN 2: from 192.168.215.1 lookup HMAN Could I delete them or avoid their generation? I would then set something like this in my rtrules file: 0.0.0.0/0 - HMAN990 and something like this in my routes file: HMAN10.215.144.42 - $IF_VLAN_13 HMAN10.215.144.43 - $IF_VLAN_15 Now, my Routing Rules are: 0: from all lookup local 1: from all fwmark 0x200/0x200 lookup Tproxy 220:from all lookup 220 990:from all lookup HMAN 999:from all lookup main 1013: from 10.215.144.92 to 85.119.192.0/21 lookup CAIB 1: from all fwmark 0x1/0xff lookup WAN 10001: from all fwmark 0x2/0xff lookup CAIB 10002: from all fwmark 0x3/0xff lookup IBS 10004: from all fwmark 0x4/0xff lookup HMAN 2: from 172.16.0.1 lookup WAN 2: from 172.20.11.62 lookup CAIB 2: from 172.28.17.105 lookup IBS 2: from 192.168.215.1 lookup HMAN 32765: from all lookup balance 32767: from all lookup default Table CAIB: [snip] Table HMAN: 10.215.144.42 dev blan.13 scope link 10.215.144.43 dev blan.15 scope link So I can finally run this command whenever I want to by-pass the IBS/CAIB provider routes: # ip rule add pref 995 from all to 10.0.0.0/8 lookup CAIB Is there a better way to do this? Vieri ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] martian source and net_ratelimit
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 /proc/sys/net/ipv4/conf/enp8s5/rp_filter. > > Which is exactly what you want. I suspect that your sysconf > configuration is setting that option to 1. # sysctl -a | grep '\.rp_filter' net.ipv4.conf.all.rp_filter = 0 net.ipv4.conf.blan.rp_filter = 0 net.ipv4.conf.blan/1.rp_filter = 0 net.ipv4.conf.blan/12.rp_filter = 0 net.ipv4.conf.blan/13.rp_filter = 0 net.ipv4.conf.blan/14.rp_filter = 0 net.ipv4.conf.blan/15.rp_filter = 0 net.ipv4.conf.blan/16.rp_filter = 0 net.ipv4.conf.blan/17.rp_filter = 0 net.ipv4.conf.blan/18.rp_filter = 0 net.ipv4.conf.bond0.rp_filter = 0 net.ipv4.conf.default.rp_filter = 0 net.ipv4.conf.enp10s0.rp_filter = 0 net.ipv4.conf.enp5s0.rp_filter = 0 net.ipv4.conf.enp5s0/1.rp_filter = 0 net.ipv4.conf.enp5s0/11.rp_filter = 0 net.ipv4.conf.enp5s0/12.rp_filter = 0 net.ipv4.conf.enp5s0/13.rp_filter = 0 net.ipv4.conf.enp5s0/14.rp_filter = 0 net.ipv4.conf.enp5s0/15.rp_filter = 0 net.ipv4.conf.enp5s0/16.rp_filter = 0 net.ipv4.conf.enp6s0.rp_filter = 0 net.ipv4.conf.enp7s0f0.rp_filter = 0 net.ipv4.conf.enp7s0f1.rp_filter = 0 net.ipv4.conf.enp7s0f2.rp_filter = 0 net.ipv4.conf.enp7s0f3.rp_filter = 0 net.ipv4.conf.enp8s5.rp_filter = 0 net.ipv4.conf.enp8s5/100.rp_filter = 0 net.ipv4.conf.lo.rp_filter = 0 net.ipv4.conf.tun146.rp_filter = 0 net.ipv4.conf.tun147.rp_filter = 0 net.ipv4.conf.tun148.rp_filter = 0 > A martian packet is one that is received on an interface from a host > that is routed out of a different interface. As I mentioned before, it > does not take policy routing into account. > > > > Nov 5 13:40:15 kernel: net_ratelimit: 137 callbacks suppressed > > Nov 5 13:40:15 kernel: IPv4: martian source 10.215.248.9 from > > 10.215.144.91, on dev enp8s5 > > Nov 5 13:40:15 kernel: ll header: : ff ff ff ff ff ff e8 ea > > 6a 0c 4c 1c 08 06j.L... > > Nov 5 13:40:15 kernel: IPv4: martian source 10.215.241.221 from > > 10.215.144.35, on dev enp8s5 > > Nov 5 13:40:15 kernel: ll header: : ff ff ff ff ff ff 00 50 > > 56 92 5b 09 08 06...PV.[... > > Nov 5 13:40:15 kernel: IPv4: martian source 10.215.246.124 from > > 10.215.144.91, on dev enp8s5 > > Nov 5 13:40:15 kernel: ll header: : ff ff ff ff ff ff e8 ea > > 6a 0c 4c 1c 08 06j.L... > > Nov 5 13:40:15 kernel: IPv4: martian source 10.215.144.89 from > > 10.215.144.91, on dev enp8s5 > > Nov 5 13:40:15 kernel: ll header: : ff ff ff ff ff ff e8 ea > > 6a 0c 4c 1c 08 06j.L... > > Nov 5 13:40:15 kernel: IPv4: martian source 10.215.146.23 from > > 10.215.144.47, on dev enp8s5 > > Nov 5 13:40:15 kernel: ll header: : ff ff ff ff ff ff 18 60 > > 24 ef b9 09 08 06...`$. > > Nov 5 13:40:15 kernel: IPv4: martian source 10.215.144.31 from > > 10.215.144.67, on dev enp8s5 > > Nov 5 13:40:15 kernel: ll header: : ff ff ff ff ff ff 00 50 > > 56 b6 05 90 08 06...PV. > > Nov 5 13:40:15 kernel: IPv4: martian source 10.215.247.134 from > > 10.215.144.91, on dev enp8s5 > > Nov 5 13:40:15 kernel: ll header: : ff ff ff ff ff ff e8 ea > > 6a 0c 4c 1c 08 06j.L... > > Nov 5 13:40:15 kernel: IPv4: martian source 10.215.147.32 from > > 10.215.144.23, on dev enp8s5 > > Nov 5 13:40:15 kernel: ll header: : ff ff ff ff ff ff 52 54 > > 00 de a6 34 08 06..RT...4.. > > Nov 5 13:40:15 kernel: IPv4: martian source 10.215.147.13 from > > 10.215.144.91, on dev enp8s5 > > Nov 5 13:40:15 kernel: ll header: : ff ff ff ff ff ff e8 ea > > 6a 0c 4c 1c 08 06j.L... > > Nov 5 13:40:15 kernel: IPv4: martian source 10.215.246.40 from > > 10.215.247.70, on dev enp8s5 > > Nov 5 13:40:15 kernel: ll header: : ff ff ff ff ff ff c4 34 > > 6b 61 b7 bb 08 06...4ka > > > > In fact, I should not be seeing traffic between hosts with IP > > addresses in the 10.215.* range on this enp8s5 interface. This could > > be a loopback on the main switch since there's another NIC on the > > Shorewall router connecting to the same switch. However, enp8s5 is > > connected to a switch port with a specific VLAN ID. If the VLAN > > implementation on this switch is correct, it should be impossible for > > traffic for the 10.215.* hosts to reach the enp8s5 interface. > > Does the martians log prove that there's something wrong on the main switch? > > > > Seems like it. I dumped some traffic on that interface (enp8s5), and I can see that it's mostly ARP requests, DHCPv6, etc., but there's also SMB2. I presume ARP requests can flow through different VLANs, but layer-3 traffic shouldn't. The dump is available here if you'd like to take a look at it: https://drive.google.com/file/d/1v0KiMC
Re: [Shorewall-users] connecting from one provider to another
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 the "main" routing table entries for specific source IP addresses. Thanks, Vieri ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
Re: [Shorewall-users] connecting from one provider to another
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 there and replace it as in my previous example. Thanks for the hint. I'll need to study that. > Because you are complaining about how slow and disruptive 'shorewall > reload' is on this system. I would think that you would want to strip > out as much as possible from the Shorewall config and have it installed > once (at boot time). Unless I use shorewall-lite, I presume. In that case, reloading should be blazing fast... ;-) > Given that lookup in the main table occurs > very early in the routing rules, that table should be used wherever > possible. I will definitely go that route, or at least try to. Tom, you don't know how glad I am to see that you're still sticking around. Big thanks to the other users too who pitch in with their useful insights. Regards, Vieri ___ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
