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