Frees/wan setup problems

Cole Tuininga colet at code-energy.com
Wed Feb 26 11:45:43 EST 2003


On Wed, 2003-02-26 at 11:21, Kenneth E. Lussier wrote:
> On Wed, 2003-02-26 at 09:08, Cole Tuininga wrote:
> > 
> > Ok - here's the situation.  I'm looking doing some work from home, so I
> > want to VPN my home network with my lab network at work.  Here's the
> > setup:
> > 
> > Both networks are basically the same in setup.  They look like:
> > 
> > linux workstations <--> linux masqing box <--> internet
> 
> Can you get from one gateway to another? 

Nope.  

Host 192.168.1.1:

deb-box:~# ping 192.168.2.1
PING 192.168.2.1 (192.168.2.1): 56 data bytes

--- 192.168.2.1 ping statistics ---
10 packets transmitted, 0 packets received, 100% packet loss

Same deal on the other side.

> IOW, can the internal interface
> on one side ping the internal interface on the other? What about
> traceroutes from the gateway as well as from the internal machines?

Traceroute from the gateways give me nothing.  From a host on the inside
of my home network (the 192.168.2.x side), I get:

root at colap:~# 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.


> > On the home network, I use an internal class C network: 192.168.2.0/24
> > and at work we use 192.168.1.0/24.
> > 
> > My ipsec.conf on each side looks like the following:
> > 
> > config setup
> >     interfaces="ipsec0=eth1"
> >     klipsdebug=none
> >     plutodebug=none
> >     plutoload=%search
> >     plutostart=%search
> >     uniqueids=yes
> > 
> > conn %default
> >     keyingtries=0
> >     disablearrivalcheck=yes
> >     authby=rsasig
> > 
> > conn panam-cole
> >     left = 63.127.199.26
> >     leftsubnet = 192.168.2.0/24
> >     leftnexthop = 63.127.199.25
> >     leftrsasigkey = 0sAQNkta3 [snipped for brevity]
> >     right = 209.187.117.100
> >     rightsubnet = 192.168.1.0/24
> >     rightnexthop = 209.187.117.65
> >     rightrsasigkey=0sAQPBb4 [snipped for brevity]
> >     auto = start
> 
> 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 root at 63.127.199.26
[hangs until I control -c]

However, it works fine from the gateway machine.

>From 192.168.1.1:

deb-box:~# ssh root at 63.127.199.26
root at 63.127.199.26's password:

> 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)

> 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.

 
> > 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?

> Thought's on what could be wrong:
> 
> Any one of a million things ;-)

*heh*

> Diagnostic steps:
> 
> traceroute to see where the packets are actually going/coming from.
> Routing is a common problem with ipsec where the traffic comes in the
> ipsec tunnel, but the return traffic ends up going out the default
> gateway via the internet. 

Did I give all necessary info?

-- 
"...it is important to realize that any lock can be picked
 with a big enough hammer...."  
                              -Sun System & Network Admin manual

Cole Tuininga
Lead Developer
Code Energy, Inc
colet at code-energy.com
PGP Key ID: 0x43E5755D





More information about the gnhlug-discuss mailing list