On Wed, 2003-02-26 at 11:45, Cole Tuininga wrote: > > Traceroute from the gateways give me nothing.
Well that *IS* interesting. If the gateways can't talk to each other, then nothing behind them can. Try this.... Create multiple conn sections for each of these: 1) Gateway-to-gateway 2) 192.168.1.0/24-to-opposite gateway 3) 192.168.2.0/24-to-opposite gateway 4) 192.168.1.0/24-to-192.168.2.0/24 This will allow the most traffic to traverse the tunnels. > From a host on the inside > of my home network (the 192.168.2.x side), I get: > > [EMAIL PROTECTED]:~# traceroute -n 192.168.1.68 > traceroute to 192.168.1.68 (192.168.1.68), 30 hops max, 38 byte packets > 1 192.168.2.1 0.384 ms 0.508 ms 0.388 ms > 2 * * * > 3 * * * > etc, etc. Again, this is fairly interesting. 192.168.2.1 doesn't know what to do with the traffic. Either that, or ICMP is being blocked. You can try forcing a route between the two gateways, which might help. Can you send me the output of a pluto barf? (BTW... Who *NAMES* these things??? ;-) > > > > It's not essential, but you might want to a gateway-to-gateway conn > > section : > > > > conn workgateway-homegateway > > left = 63.127.199.26 > > leftnexthop = 63.127.199.25 > > leftrsasigkey = 0sAQNkta3 > > right = 209.187.117.100 > > rightnexthop = 209.187.117.65 > > rightrsasigkey=0sAQPBb4 [snipped for brevity] > > auto = start > > Will this allow the internal ip's of the gateways (192.168.1.1 and > 192.168.2.1) to talk to each other over the VPN? Interestingly, now > that I've added this, I can no longer connect to my home gateway machine > from an internal machine at work (via masqing) > > >From 192.168.1.68: > > $ ssh [EMAIL PROTECTED] > [hangs until I control -c] > > However, it works fine from the gateway machine. > > >From 192.168.1.1: > > deb-box:~# ssh [EMAIL PROTECTED] > [EMAIL PROTECTED]'s password: Sorry about that. See above where I suggest the other tunnels. My thinking was a bit off on that, and basically what I told you to do was send all traffic between the two through the ipsec tunnel, which will sort of stop all other traffic. My bad ;-) > > That shouldn't really be a big deal. However, for the sake of > > continuity, you might want to grab the latest kernel patches. > > Yeah - I was just trying to avoid having to take these machines down > *again*. 8) Yeah, I know... I had to shut down a system that has an uptime of 364 days. It was painfull, but I did it anyway ;-) > > Are the routing tables set up to send 192.168.1/2.0/24 traffic out > > ipsec0? > > >From my home gateway machine: > > # route -n > Kernel IP routing table > Destination Gateway Genmask Flags Metric Ref Use > Iface > 209.187.117.100 63.127.199.25 255.255.255.255 UGH 0 0 0 > ipsec0 > 63.127.199.24 0.0.0.0 255.255.255.252 U 0 0 0 > eth0 > 63.127.199.24 0.0.0.0 255.255.255.252 U 0 0 0 > ipsec0 > 192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 > eth1 > 192.168.1.0 63.127.199.25 255.255.255.0 UG 0 0 0 > ipsec0 > 0.0.0.0 63.127.199.25 0.0.0.0 UG 0 0 0 > eth0 > > Is there anything fishy/wrong here? The routing table gets set up > automagically when I start ipsec. Nothing especially out of the ordiary, except maybe that you have two routes for the destination of 63.127.199.24, one using eth0 and one using ipsec0. both with the same metric. But then again, that could be my fault ;-) > > > Like I said before, it's rather peculiar because it *was* working. I > > > had to finish assembling the box here at Pan Am so I took it down. When > > > it came back up, the logs claim that the ipsec connection is active, and > > > if I turn on klipsdebug to all I can see that "something is happening", > > > but my pings and ssh's don't make it through. > > > > Are they not making it out, or are they not making it back? > > I don't have access to a machine to use as a sniffer at the moment - any > ideas on how else to check? Run tcpdump -i eth0 and see if the packets are making out of the interface. > Did I give all necessary info? So far, so good... Like I said earlier, if you could sent me a full pluto barf, that would help (it will be quite long, too). Also, if you kill the connection and start it up again, the output of the connection starting from both syslogs would help. C-Ya, Kenny -- ---------------------------------------------------------------------------- "Tact is just *not* saying true stuff" -- Cordelia Chase Kenneth E. Lussier Sr. Systems Administrator Zuken, USA PGP KeyID CB254DD0 http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xCB254DD0 _______________________________________________ gnhlug-discuss mailing list [EMAIL PROTECTED] http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
