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.