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?