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 <d...@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?
--
David A. De Graaf DATIX, Inc. Hendersonville, NC
d...@datix.us www.datix.us
_______________________________________________
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
