I use an ipsec tunnel to connect my LAN (192.168.2.h) in North Carolina to my son's LAN (192.168.1.h) in Maryland. We each have a primary machine that manages the ipsec tunnel and several secondary machines. Static routing tables direct traffic for the remote LAN to the local primary machine and thence through the tunnel. Cross-referenced DNS tables effectively join the two LANs as one. We expect all the usual network tools (autofs/nfs, ssh, rsync, etc.) to work thru the tunnel.
Recently we've noticed that autofs/nfs and ssh don't work between a secondary machine and any remote machine. Autofs/nfs and ssh work perfectly between the primaries. Ping works perfectly between all machines, primary or secondary.
For autofs the key subfunction seems to be rpcinfo. From the primary (datium) to the remote primary (octopus) 'rpcinfo -p name' yields good data: # rpcinfo -p octopus program vers proto port service 100000 4 tcp 111 portmapper 100000 3 tcp 111 portmapper 100000 2 tcp 111 portmapper 100000 4 udp 111 portmapper 100000 3 udp 111 portmapper 100000 2 udp 111 portmapper 100005 1 udp 20048 mountd 100005 1 tcp 20048 mountd 100005 2 udp 20048 mountd 100005 2 tcp 20048 mountd 100005 3 udp 20048 mountd 100005 3 tcp 20048 mountd 100024 1 udp 35631 status 100024 1 tcp 58519 status 100003 3 tcp 2049 nfs 100003 4 tcp 2049 nfs 100227 3 tcp 2049 nfs_acl 100021 1 udp 47742 nlockmgr 100021 3 udp 47742 nlockmgr 100021 4 udp 47742 nlockmgr 100021 1 tcp 35983 nlockmgr 100021 3 tcp 35983 nlockmgr 100021 4 tcp 35983 nlockmgr
But from a secondary to the remote primary it fails: # rpcinfo -p octopus octopus: RPC: Port mapper failure - Unable to receive: errno 113 (No route to host)
Similarly, for ssh the basic test seems to be telnet <name> 22. From primary to primary it works correctly: # telnet octopus 22 Trying 192.168.1.2... Connected to octopus. Escape character is '^]'. SSH-2.0-OpenSSH_7.4
But from a secondary to the remote primary, it fails: # telnet octopus 22 Trying 192.168.1.2... telnet: connect to address 192.168.1.2: No route to host
In both failures the complaint is "No route to host", but clearly there is a route to the host, because ping works: # ping octopus PING octopus.dino.lan (192.168.1.2) 56(84) bytes of data. 64 bytes from 192.168.1.2 (192.168.1.2): icmp_seq=1 ttl=63 time=107 ms From router.datix.lan (192.168.2.1): icmp_seq=2 Redirect Host(New nexthop: datium.datix.lan (192.168.2.2)) 64 bytes from 192.168.1.2 (192.168.1.2): icmp_seq=2 ttl=63 time=45.1 ms From router.datix.lan (192.168.2.1): icmp_seq=3 Redirect Host(New nexthop: datium.datix.lan (192.168.2.2)) 64 bytes from 192.168.1.2 (192.168.1.2): icmp_seq=3 ttl=63 time=85.2 ms From router.datix.lan (192.168.2.1): icmp_seq=4 Redirect Host(New nexthop: datium.datix.lan (192.168.2.2)) 64 bytes from 192.168.1.2 (192.168.1.2): icmp_seq=4 ttl=63 time=80.4 ms ^C --- octopus.dino.lan ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3002ms rtt min/avg/max/mdev = 45.154/79.682/107.905/22.475 ms
Each LAN has a router that connects to the internet. All LAN machines use the router's IP for the default gateway. In the router is a static route that sends packets destined for the remote LAN back to the primary machine that handles the ipsec tunnel.
What's the problem here? Why is ping more clever in finding the route?
Any advice or insight gratefully received.
On 08/11/2017 11:12 AM, David A. De Graaf wrote:
What's the problem here? Why is ping more clever in finding the route?
One problem you might have is that your ipsec gateway may have firewall rules that allow ICMP but not other traffic to be forwarded. Can you post the full set of firewall rules somewhere? https://paste.fedoraproject.org/ ?
On 08/11/17 14:28, Gordon Messmer wrote:
On 08/11/2017 11:12 AM, David A. De Graaf wrote:
What's the problem here? Why is ping more clever in finding the route?
One problem you might have is that your ipsec gateway may have firewall rules that allow ICMP but not other traffic to be forwarded. Can you post the full set of firewall rules somewhere? https://paste.fedoraproject.org/ ?
Thanks Gordon Messmer for that idea.
I had suspected the firewall, too, so read the rules with some care, but was reluctant to turn off the firewalls, even briefly. (The other common suspect, selinux, is disabled.) On the remote gateway. octopus, 'ipsec -L' output was dominated by DROP lines from 'fail2ban', but no lines included string "192.168". Remember, autofs and ssh DO WORK between the primary gateways; all the needed services are allowed to pass the firewall. It's got to be a routing issue.
In 'ipsec -L -t nat' I found two entries that might be related: MASQUERADE all -- 192.168.0.0/16 !192.168.0.0/16 MASQUERADE all -- 192.168.0.0/16 !192.168.0.0/16 These are for the convenience of VirtualBox subnets.
So I ran 'systemctl restart firewalld' which started afresh. All the fail2ban lines were gone, as were the MASQUERADE lines.
I did the same on my local gateway, datium.
Sadly, I still get the same failures and successes. 'rpcinfo -p octopus' fails from a secondary, and succeeds from my primary gateway, datium. Same for 'telnet octopus 22'.
I tried to save the above files to https://paste.fedoraproject.org/, but ordinary UNIX cut & paste (highlight with B1, paste with B2) didn't seem to work. Sorry.
On 08/11/2017 01:32 PM, David A. De Graaf wrote:
(The other common suspect, selinux, is disabled.)
That's terrible. Stop turning off SELinux. You don't "find / -exec chmod 777 {} +" do you?
On the remote gateway. octopus, 'ipsec -L' output was dominated by DROP lines from 'fail2ban', but no lines included string "192.168". Remember, autofs and ssh DO WORK between the primary gateways;
Right. Those packets are governed by the INPUT and OUTPUT chains. Packets between any other hosts will be governed by the FORWARD chain. Potentially on both of the ipsec hosts, so we can't really proceed without seeing the rules.
all the needed services are allowed to pass the firewall.
You haven't demonstrated that yet, and I think it's too early to draw that conclusion.
The other thing you could to is run "tcpdump -nn -i any host octopus" on datium. Ping octopus from another machine on datium's subnet to make sure you see those packets in the tcpdump output. If so, then try to telnet to octopus:22 from the same machine. You should see the TCP SYN packet, just like you see the ICMP echo requests. If so, the problem is probably not a routing issue.
I tried to save the above files to https://paste.fedoraproject.org/, but ordinary UNIX cut & paste (highlight with B1, paste with B2) didn't seem to work. Sorry.
So use Shift+Ctrl+C to copy the terminal text and paste that as normal...
David,
Is this still broken? I'd like to trade some debugging attention for a primer on setting up IPSec, which i've never gotten around to.
On 11Aug2017 14:12, David A. De Graaf dad@datix.us wrote:
I use an ipsec tunnel to connect my LAN (192.168.2.h) in North Carolina to my son's LAN (192.168.1.h) in Maryland. We each have a primary machine that manages the ipsec tunnel and several secondary machines. Static routing tables direct traffic for the remote LAN to the local primary machine and thence through the tunnel. Cross-referenced DNS tables effectively join the two LANs as one. We expect all the usual network tools (autofs/nfs, ssh, rsync, etc.) to work thru the tunnel.
Recently we've noticed that autofs/nfs and ssh don't work between a secondary machine and any remote machine. Autofs/nfs and ssh work perfectly between the primaries.
That sounds like routing, since ssh just does a TCP connection as far as the networking side goes.
Ping works perfectly between all machines, primary or secondary.
[...]
For autofs the key subfunction seems to be rpcinfo.
Probably the easiest thing to test.
[...]
But from a secondary to the remote primary it fails: # rpcinfo -p octopus octopus: RPC: Port mapper failure - Unable to receive: errno 113 (No route to host)
Similarly, for ssh the basic test seems to be telnet <name> 22. From primary to primary it works correctly: # telnet octopus 22 Trying 192.168.1.2... Connected to octopus. Escape character is '^]'. SSH-2.0-OpenSSH_7.4
But from a secondary to the remote primary, it fails: # telnet octopus 22 Trying 192.168.1.2... telnet: connect to address 192.168.1.2: No route to host
Both of these look like routing.
In both failures the complaint is "No route to host", but clearly there is a route to the host, because ping works: # ping octopus PING octopus.dino.lan (192.168.1.2) 56(84) bytes of data. 64 bytes from 192.168.1.2 (192.168.1.2): icmp_seq=1 ttl=63 time=107 ms From router.datix.lan (192.168.2.1): icmp_seq=2 Redirect Host(New nexthop: datium.datix.lan (192.168.2.2))
The redirect message bothers me.
Each LAN has a router that connects to the internet. All LAN machines use the router's IP for the default gateway. In the router is a static route that sends packets destined for the remote LAN back to the primary machine that handles the ipsec tunnel.
What's the problem here? Why is ping more clever in finding the route?
What does the routing table on the primary look like? And on a secondary? "netstat -rn" is what I'm after.
Cheers, Cameron Simpson cs@cskk.id.au (formerly cs@zip.com.au)
On 09/24/2017 01:44 PM, Cameron Simpson wrote:
David,
Is this still broken? I'd like to trade some debugging attention for a primer on setting up IPSec, which i've never gotten around to.
On 11Aug2017 14:12, David A. De Graaf dad@datix.us wrote:
I use an ipsec tunnel to connect my LAN (192.168.2.h) in North Carolina to my son's LAN (192.168.1.h) in Maryland. We each have a primary machine that manages the ipsec tunnel and several secondary machines. Static routing tables direct traffic for the remote LAN to the local primary machine and thence through the tunnel. Cross-referenced DNS tables effectively join the two LANs as one. We expect all the usual network tools (autofs/nfs, ssh, rsync, etc.) to work thru the tunnel.
Recently we've noticed that autofs/nfs and ssh don't work between a secondary machine and any remote machine. Autofs/nfs and ssh work perfectly between the primaries.
That sounds like routing, since ssh just does a TCP connection as far as the networking side goes.
It's possible it's your firewalls getting in the way. Pushing NFS through a firewall isn't easy unless you use fixed ports and put appropriate holes in the firewall.
Another possibility is that, in most cases, IPSEC does NATting and a connection from a machine behind an IPSEC gateway will appear to come from the IPSEC gateway itself and not the host that it actually came from. With a network like:
"A" <--> "GW A" <--> Internet <--> "GW B" <--> "B"
a connection from A to B will appear to B as if it's coming from the "public" (internet-facing) side of "GW A" and not "A" itself. Thus the firewall on B must permit incoming connections from "GW A"'s public interface. I haven't done a boatload of dual gateway VPNs (we typically use Cisco gear where you use a single gateway and split tunnel ACLs to manage routing) and that's what we deal with (the clients' connections all appear to come from the VPN gateway's public IP).
At least it's something to look at. Running tcpdump or wireshark on B while trying to ssh to B from A should reveal what's going on.
Ping works perfectly between all machines, primary or secondary.
[...]
For autofs the key subfunction seems to be rpcinfo.
Probably the easiest thing to test.
[...]
But from a secondary to the remote primary it fails: # rpcinfo -p octopus octopus: RPC: Port mapper failure - Unable to receive: errno 113 (No route to host)
Similarly, for ssh the basic test seems to be telnet <name> 22. From primary to primary it works correctly: # telnet octopus 22 Trying 192.168.1.2... Connected to octopus. Escape character is '^]'. SSH-2.0-OpenSSH_7.4
But from a secondary to the remote primary, it fails: # telnet octopus 22 Trying 192.168.1.2... telnet: connect to address 192.168.1.2: No route to host
Both of these look like routing.
In both failures the complaint is "No route to host", but clearly there is a route to the host, because ping works: # ping octopus PING octopus.dino.lan (192.168.1.2) 56(84) bytes of data. 64 bytes from 192.168.1.2 (192.168.1.2): icmp_seq=1 ttl=63 time=107 ms From router.datix.lan (192.168.2.1): icmp_seq=2 Redirect Host(New nexthop: datium.datix.lan (192.168.2.2))
The redirect message bothers me.
Each LAN has a router that connects to the internet. All LAN machines use the router's IP for the default gateway. In the router is a static route that sends packets destined for the remote LAN back to the primary machine that handles the ipsec tunnel.
What's the problem here? Why is ping more clever in finding the route?
What does the routing table on the primary look like? And on a secondary? "netstat -rn" is what I'm after.
Cheers, Cameron Simpson cs@cskk.id.au (formerly cs@zip.com.au) _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org
Allegedly, on or about 11 August 2017, David A. De Graaf sent:
Why is ping more clever in finding the route?
It's a much more basic part of networking.
When you try to connect to a service (mail, HTTP, FTP, telnet, SSH, etc), it has to be there and running, and have nothing in the way (such as a firewall). It's something extra to the network, and behind the barrier, so to speak.
Ping is generally not firewalled. Though people can firewall that off, too, and completely stuff-up their ability to fault-find a network. Likewise with other ICMP traffic (firewalling it can break their networking, while doing nothing that helps with security).
Ping is usually part of the TCP/IP stack software. Ping tests help to confirm network presence, but are useless with confirming whether services are working. e.g. Doing ping www.example.com pings the network hardware and software at that location, it has no interaction with the webserver that it may be running.
On 09/24/17 16:44, Cameron Simpson wrote:
David,
Is this still broken? I'd like to trade some debugging attention for a primer on setting up IPSec, which i've never gotten around to.
On 11Aug2017 14:12, David A. De Graaf dad@datix.us wrote:
I use an ipsec tunnel to connect my LAN (192.168.2.h) in North Carolina to my son's LAN (192.168.1.h) in Maryland. We each have a primary machine that manages the ipsec tunnel and several secondary machines. Static routing tables direct traffic for the remote LAN to the local primary machine and thence through the tunnel. Cross-referenced DNS tables effectively join the two LANs as one. We expect all the usual network tools (autofs/nfs, ssh, rsync, etc.) to work thru the tunnel.
Recently we've noticed that autofs/nfs and ssh don't work between a secondary machine and any remote machine. Autofs/nfs and ssh work perfectly between the primaries.
As of this week, my problem is solved. I can once again access remote machines at the far end of my ipsec tunnel from either the main gateway machine or from any of my secondary machines, using ping, ssh, or autofs/nfs. The remote LAN at my son's house and my LAN are fully integrated through the tunnel.
As Cameron, Gordon and Rick have suggested, routing and firewalls were the culprits. Mostly to blame is my weak comprehension of how firewalls work and especially 'firewall-config'. Let me explain, in the hope that others may avoid the trap I fell into.
My system configuration is fairly common - a main server, datium, connects by ethernet to a consumer-grade router with 4 ethernet ports, a WAN port, and wireless antennae. The WAN port connects to a cable modem and thence to the big, bad internet. A bunch of other computers connect wirelessly or cascade from the router's ethernet ports. All these devices constitute my 192.168.2.H LAN.
The main server, datium, runs EVERYTHING - dhcp, dhs, sendmail, httpd, ipsec, etc. In particular, the router's implementation of dhcp is deactivated; only datium's dhcp is active. In part, that's because the router can't interact with and update datium's dns data files.
Which brings us to - routing. Each secondary machine needs a default gateway - the address to which packets not on the LAN are sent. There are two logical candidates: datium or the router. Using datium puts extra traffic through that machine and creates a single point of failure for existing connections. Using the router would seem preferable since that path would be more direct for external traffic, equal for local traffic, and would remain usable were datium to go briefly offline. A static route in the router directing traffic for the 192.168.1.H network (via the tunnel) back to datium is needed. OK, that can be done.
WRONG!
The router's firewall blocks traffic from secondary machines to the tunnel! And it cannot, must not, be turned off.
Instead, the default gateway must be datium. Datium knows about the tunnel and will direct traffic there or to the LAN or to the router for external traffic. But firewalld must be turned OFF. Else ssh and autofs via the tunnel will be blocked.
I think I understand the firewall in the router. All interrogations from the WAN port to the LAN (anywhere) are blocked, except for a few specific ports, enumerated by me, that are forwarded thru to datium. These include 22 - ssh, 80 - http, etc.
The use of firewalld in the server, datium, is far more mysterious. Which packets are blocked? From where; to where? What does checking a box in the firewall-config GUI actually do? Nothing useful, as far as I can detect. That GUI is not at all enlightening. All I can say with certainty is that turning firewalld OFF makes ssh and autofs work; turning it ON makes them not work.
I see that 'iptables -L' reports a significant list of IP addresses that are being DROP'd, due to the operation of the fail2ban service. So iptables is protecting me even without firewalld. Is there any benefit to be had from running firewalld on this server without causing severe loss of function?
On 09/28/2017 12:15 PM, David A. De Graaf wrote:
On 09/24/17 16:44, Cameron Simpson wrote:
David,
Is this still broken? I'd like to trade some debugging attention for a primer on setting up IPSec, which i've never gotten around to.
On 11Aug2017 14:12, David A. De Graaf dad@datix.us wrote:
I use an ipsec tunnel to connect my LAN (192.168.2.h) in North Carolina to my son's LAN (192.168.1.h) in Maryland. We each have a primary machine that manages the ipsec tunnel and several secondary machines. Static routing tables direct traffic for the remote LAN to the local primary machine and thence through the tunnel. Cross-referenced DNS tables effectively join the two LANs as one. We expect all the usual network tools (autofs/nfs, ssh, rsync, etc.) to work thru the tunnel.
Recently we've noticed that autofs/nfs and ssh don't work between a secondary machine and any remote machine. Autofs/nfs and ssh work perfectly between the primaries.
As of this week, my problem is solved. I can once again access remote machines at the far end of my ipsec tunnel from either the main gateway machine or from any of my secondary machines, using ping, ssh, or autofs/nfs. The remote LAN at my son's house and my LAN are fully integrated through the tunnel.
As Cameron, Gordon and Rick have suggested, routing and firewalls were the culprits. Mostly to blame is my weak comprehension of how firewalls work and especially 'firewall-config'. Let me explain, in the hope that others may avoid the trap I fell into.
My system configuration is fairly common - a main server, datium, connects by ethernet to a consumer-grade router with 4 ethernet ports, a WAN port, and wireless antennae. The WAN port connects to a cable modem and thence to the big, bad internet. A bunch of other computers connect wirelessly or cascade from the router's ethernet ports. All these devices constitute my 192.168.2.H LAN.
The main server, datium, runs EVERYTHING - dhcp, dhs, sendmail, httpd, ipsec, etc. In particular, the router's implementation of dhcp is deactivated; only datium's dhcp is active. In part, that's because the router can't interact with and update datium's dns data files.
Which brings us to - routing. Each secondary machine needs a default gateway - the address to which packets not on the LAN are sent. There are two logical candidates: datium or the router. Using datium puts extra traffic through that machine and creates a single point of failure for existing connections. Using the router would seem preferable since that path would be more direct for external traffic, equal for local traffic, and would remain usable were datium to go briefly offline. A static route in the router directing traffic for the 192.168.1.H network (via the tunnel) back to datium is needed. OK, that can be done.
WRONG!
The router's firewall blocks traffic from secondary machines to the tunnel! And it cannot, must not, be turned off.
Instead, the default gateway must be datium. Datium knows about the tunnel and will direct traffic there or to the LAN or to the router for external traffic. But firewalld must be turned OFF. Else ssh and autofs via the tunnel will be blocked.
I think I understand the firewall in the router. All interrogations from the WAN port to the LAN (anywhere) are blocked, except for a few specific ports, enumerated by me, that are forwarded thru to datium. These include 22 - ssh, 80 - http, etc.
The use of firewalld in the server, datium, is far more mysterious. Which packets are blocked? From where; to where? What does checking a box in the firewall-config GUI actually do? Nothing useful, as far as I can detect. That GUI is not at all enlightening. All I can say with certainty is that turning firewalld OFF makes ssh and autofs work; turning it ON makes them not work.
I see that 'iptables -L' reports a significant list of IP addresses that are being DROP'd, due to the operation of the fail2ban service. So iptables is protecting me even without firewalld. Is there any benefit to be had from running firewalld on this server without causing severe loss of function?
The actual firewall is still iptables. firewalld and its clients make up a system which permits dbus interaction with iptables. If you change things via firewalld, then do an "iptables -L" you'll see those changes reflected in the output.
If you like, you can think of firewalld and its clients firewall-cmd, firewallctl (command-line) and firewall-config (GUI) as just an easier way to interact with iptables and do it on the fly--without having to worry about rule ordering, chains, tables and that sort of thing as the clients will manage those for you.
I don't think firewalld and it's clients don't query the CURRENT state of iptables. They work on what THEIR databases say is set up. This is why the various fail2ban rules appearing in your "iptables -L" list don't appear in the firewalld clients: they didn't set them up--an external program did so firewalld doesn't know about them.
That being said, firewalld comes with some rules "out of the box" that can be too restrictive for your use (they're really intended for desktop-type use). You can certainly modify or delete them as you see fit, or you can go old-school, eschew the use of firewalld and bugger iptables directly. That's what fail2ban does. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - grasshopotomus: A creature that can leap to tremendous heights... - - ...once. - ----------------------------------------------------------------------
On 09/28/2017 05:15 PM, Rick Stevens wrote:
On 09/28/2017 12:15 PM, David A. De Graaf wrote:
On 09/24/17 16:44, Cameron Simpson wrote:
David,
Is this still broken? I'd like to trade some debugging attention for a primer on setting up IPSec, which i've never gotten around to.
On 11Aug2017 14:12, David A. De Graaf dad@datix.us wrote:
I use an ipsec tunnel to connect my LAN (192.168.2.h) in North Carolina to my son's LAN (192.168.1.h) in Maryland. We each have a primary machine that manages the ipsec tunnel and several secondary machines. Static routing tables direct traffic for the remote LAN to the local primary machine and thence through the tunnel. Cross-referenced DNS tables effectively join the two LANs as one. We expect all the usual network tools (autofs/nfs, ssh, rsync, etc.) to work thru the tunnel.
Recently we've noticed that autofs/nfs and ssh don't work between a secondary machine and any remote machine. Autofs/nfs and ssh work perfectly between the primaries.
As of this week, my problem is solved. I can once again access remote machines at the far end of my ipsec tunnel from either the main gateway machine or from any of my secondary machines, using ping, ssh, or autofs/nfs. The remote LAN at my son's house and my LAN are fully integrated through the tunnel.
As Cameron, Gordon and Rick have suggested, routing and firewalls were the culprits. Mostly to blame is my weak comprehension of how firewalls work and especially 'firewall-config'. Let me explain, in the hope that others may avoid the trap I fell into.
My system configuration is fairly common - a main server, datium, connects by ethernet to a consumer-grade router with 4 ethernet ports, a WAN port, and wireless antennae. The WAN port connects to a cable modem and thence to the big, bad internet. A bunch of other computers connect wirelessly or cascade from the router's ethernet ports. All these devices constitute my 192.168.2.H LAN.
The main server, datium, runs EVERYTHING - dhcp, dhs, sendmail, httpd, ipsec, etc. In particular, the router's implementation of dhcp is deactivated; only datium's dhcp is active. In part, that's because the router can't interact with and update datium's dns data files.
Which brings us to - routing. Each secondary machine needs a default gateway - the address to which packets not on the LAN are sent. There are two logical candidates: datium or the router. Using datium puts extra traffic through that machine and creates a single point of failure for existing connections. Using the router would seem preferable since that path would be more direct for external traffic, equal for local traffic, and would remain usable were datium to go briefly offline. A static route in the router directing traffic for the 192.168.1.H network (via the tunnel) back to datium is needed. OK, that can be done.
WRONG!
The router's firewall blocks traffic from secondary machines to the tunnel! And it cannot, must not, be turned off.
Instead, the default gateway must be datium. Datium knows about the tunnel and will direct traffic there or to the LAN or to the router for external traffic. But firewalld must be turned OFF. Else ssh and autofs via the tunnel will be blocked.
I think I understand the firewall in the router. All interrogations from the WAN port to the LAN (anywhere) are blocked, except for a few specific ports, enumerated by me, that are forwarded thru to datium. These include 22 - ssh, 80 - http, etc.
The use of firewalld in the server, datium, is far more mysterious. Which packets are blocked? From where; to where? What does checking a box in the firewall-config GUI actually do? Nothing useful, as far as I can detect. That GUI is not at all enlightening. All I can say with certainty is that turning firewalld OFF makes ssh and autofs work; turning it ON makes them not work.
I see that 'iptables -L' reports a significant list of IP addresses that are being DROP'd, due to the operation of the fail2ban service. So iptables is protecting me even without firewalld. Is there any benefit to be had from running firewalld on this server without causing severe loss of function?
The actual firewall is still iptables. firewalld and its clients make up a system which permits dbus interaction with iptables. If you change things via firewalld, then do an "iptables -L" you'll see those changes reflected in the output.
If you like, you can think of firewalld and its clients firewall-cmd, firewallctl (command-line) and firewall-config (GUI) as just an easier way to interact with iptables and do it on the fly--without having to worry about rule ordering, chains, tables and that sort of thing as the clients will manage those for you.
I don't think firewalld and it's clients don't query the CURRENT state of iptables. They work on what THEIR databases say is set up. This is why the various fail2ban rules appearing in your "iptables -L" list don't appear in the firewalld clients: they didn't set them up--an external program did so firewalld doesn't know about them.
That being said, firewalld comes with some rules "out of the box" that can be too restrictive for your use (they're really intended for desktop-type use). You can certainly modify or delete them as you see fit, or you can go old-school, eschew the use of firewalld and bugger iptables directly. That's what fail2ban does.
I should also have prefaced my comments that I could be completely wrong about firewalld not querying iptables. I don't know. I don't do a lot of mucking about with firewalld. I'm an old hack and generally do my own iptables stuff when I need to. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - "How does that damned three seashell thing work?" - - -- Sylvester Stallone, "Demolition Man" - ----------------------------------------------------------------------
On Thu, Sep 28, 2017 at 05:47:39PM -0700, Rick Stevens wrote:
I should also have prefaced my comments that I could be completely wrong about firewalld not querying iptables. I don't know. I don't do a lot of mucking about with firewalld. I'm an old hack and generally do my own iptables stuff when I need to.
You're right -- it keeps track on its own.
-
Cameron Simpson -
David A. De Graaf -
Gordon Messmer -
Matthew Miller -
Rick Stevens -
Tim