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(a)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(a)alldigital.com -
- AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 -
- -
- grasshopotomus: A creature that can leap to tremendous heights... -
- ...once. -
----------------------------------------------------------------------