autofs and ssh fail over ipsec tunnel

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

autofs and ssh fail over ipsec tunnel

David De Graaf
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.


--
        David A. De Graaf    DATIX, Inc.    Hendersonville, NC
        [hidden email]         www.datix.us
_______________________________________________
users mailing list -- [hidden email]
To unsubscribe send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: autofs and ssh fail over ipsec tunnel

Gordon Messmer-2
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/ ?
_______________________________________________
users mailing list -- [hidden email]
To unsubscribe send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: autofs and ssh fail over ipsec tunnel

David De Graaf
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.


--
        David A. De Graaf    DATIX, Inc.    Hendersonville, NC
        [hidden email]         www.datix.us
_______________________________________________
users mailing list -- [hidden email]
To unsubscribe send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: autofs and ssh fail over ipsec tunnel

Gordon Messmer-2
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...
_______________________________________________
users mailing list -- [hidden email]
To unsubscribe send an email to [hidden email]
Loading...