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
Connected to octopus.
Escape character is '^]'.

But from a secondary to the remote primary, it fails:
# telnet octopus 22
telnet: connect to address 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 ( 56(84) bytes of data.
64 bytes from ( icmp_seq=1 ttl=63 time=107 ms
From router.datix.lan ( icmp_seq=2 Redirect Host(New nexthop: datium.datix.lan (
64 bytes from ( icmp_seq=2 ttl=63 time=45.1 ms
From router.datix.lan ( icmp_seq=3 Redirect Host(New nexthop: datium.datix.lan (
64 bytes from ( icmp_seq=3 ttl=63 time=85.2 ms
From router.datix.lan ( icmp_seq=4 Redirect Host(New nexthop: datium.datix.lan (
64 bytes from ( icmp_seq=4 ttl=63 time=80.4 ms
--- 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

Any advice or insight gratefully received.

        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

Reply via email to