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
dad@xxxxxxxx www.datix.us
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
