Frees/wan setup problems

Kenneth E. Lussier ken.lussier at zuken.com
Wed Feb 26 17:16:49 EST 2003


On Wed, 2003-02-26 at 15:03, Cole Tuininga wrote:

> But not via the VPN:
> 
> traceroute 192.168.2.1
> traceroute to 192.168.2.1 (192.168.2.1), 30 hops max, 38 byte packets
>  1  * * *
> (etc)

What about from the subnet to the gateway?
 
> > Try this.... Create multiple conn sections
> > for each of these:
> 
> > 4) 192.168.1.0/24-to-192.168.2.0/24
> 
> This is what I put in place originally - yes?

Yes.

> > 1) Gateway-to-gateway
> 
> This is the one that crashed my ability to connect from an internal
> machine to the external ip of a gateway - right?

Yes.
 
> > 2) 192.168.1.0/24-to-opposite gateway
> > 3) 192.168.2.0/24-to-opposite gateway
> 
> You're basically saying to just add these two in?  

Yes.

> Will it take care of the problem I mention above?

Maybe....


> I don't think ICMP is being blocked.  When I had the tunnel working
> before, I could ping through without trouble.

I don't think so, either. I think that it is a matter of having the
correct connections set up, and the appropriate routing.
 
> Just so we make sure we're on the same wavelength, here's my iptables
> setup:

The IPTables stuff looked fine.

> > 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??? ;-)
> 
> A barf from when?  Startup?  When I try to send ICMP packets through? 
> TCP packets?

C. All of the above. ;-)
 


> > Run tcpdump -i eth0 and see if the packets are making out of the
> > interface. 
> 
> ping performed from 192.168.1.68 to 192.168.2.1
> tcpdump -i eth0 (internal interface) done on 192.168.1.1
> 
> Here's the relevant packets:
> 
> 14:40:51.681903 192.168.1.68 > 192.168.2.1: icmp: echo request (DF)
> 14:40:52.672484 192.168.1.68 > 192.168.2.1: icmp: echo request (DF)
> 14:40:53.672336 192.168.1.68 > 192.168.2.1: icmp: echo request (DF)
> 14:40:54.672210 192.168.1.68 > 192.168.2.1: icmp: echo request (DF)

It looks like the requests are going out, but the response is not coming
back. You may want to run tcpdump without specifying an interface to see
even more of the traffic. From this it looks like the pings are going
out to the box but are not routed back properly. 
 
> pinging to an internal ip on my home network (192.168.2.69) yielded
> similar results.

It shouldn't have. You should get a response if they are on the same
subnet.

> > > 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.
> 
> How big is this going to be?  Would it be more appropriate to send off
> list or is it ok to send it on list?

The barf output can be quite large. Sometime upwards of 1 or 2 MB.
Probably best to send it off list.

Thanks,
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





More information about the gnhlug-discuss mailing list