On 09/24/2017 01:44 PM, 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 <dad@xxxxxxxx> 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. > > That sounds like routing, since ssh just does a TCP connection as far as > the networking side goes. It's possible it's your firewalls getting in the way. Pushing NFS through a firewall isn't easy unless you use fixed ports and put appropriate holes in the firewall. Another possibility is that, in most cases, IPSEC does NATting and a connection from a machine behind an IPSEC gateway will appear to come from the IPSEC gateway itself and not the host that it actually came from. With a network like: "A" <--> "GW A" <--> Internet <--> "GW B" <--> "B" a connection from A to B will appear to B as if it's coming from the "public" (internet-facing) side of "GW A" and not "A" itself. Thus the firewall on B must permit incoming connections from "GW A"'s public interface. I haven't done a boatload of dual gateway VPNs (we typically use Cisco gear where you use a single gateway and split tunnel ACLs to manage routing) and that's what we deal with (the clients' connections all appear to come from the VPN gateway's public IP). At least it's something to look at. Running tcpdump or wireshark on B while trying to ssh to B from A should reveal what's going on. >> Ping works perfectly between all machines, primary or secondary. > [...] >> For autofs the key subfunction seems to be rpcinfo. > > Probably the easiest thing to test. > > [...] >> 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 > > Both of these look like routing. > >> 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)) > > The redirect message bothers me. > >> 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? > > What does the routing table on the primary look like? And on a > secondary? "netstat -rn" is what I'm after. > > Cheers, > Cameron Simpson <cs@xxxxxxxxxx> (formerly cs@xxxxxxxxxx) > _______________________________________________ > users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx -- ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@xxxxxxxxxxxxxx - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - We look for things. Things that make us go! - - -- The "Paclyds", Star Trek TNG - ---------------------------------------------------------------------- _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
