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@xxxxxxxx> 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@xxxxxxxxxxxxxx - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - grasshopotomus: A creature that can leap to tremendous heights... - - ...once. - ---------------------------------------------------------------------- _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
