you know, it was wierd... my exact entries on the PIX config were as follows;
>>access-list 100 permit ip 10.1.10.0 255.255.255.0 10.1.1.0 255.255.255.0
and
>>isakmp key xxxxxxxxxxx address 63.x.x.x netmask 255.255.255.255
as pertaining to the tunnel. (If you have a good idea of what constitutes an
IPSec config, then I won't bore you with the other config lines unless you request
it)
I could sometimes get a hitcount of 2 or 3 on this end of the tunnel after a
'clear xlate' or a clean reload of the PIX, and a hitcount of upwards of 120 on
the other end of the tunnel, but I was absolutely unable to route ANYTHING across
the tunnel. All the IPSec gurus(?) at TAC huddled together and postulated that I
would need to generate a GRE tunnel to pass secure NAT traffic within the VPN
tunnel. Having looked at their sample config and its creation of different
loopbacks on the inside router to accomodate GRE, I elected to skip it and instead
subnet my internet router and run a hub off E1 so that people needing access to
the remote network could use Secure Client and a static IP to do it. Until the
local carriers can compensate for overselling Internet/WAN services to businesses
in the technology zones, this is what I'm stuck with until I can get an install
date.
GWA
Chuck Larrieu wrote:
> Hey, G.W. I was a bit curious about your statement regarding PIX to PIX
> IPSec tunnels. Since an IPSec tunnel is generally done from "outside"
> interface to "outside" interface on any device, whether it be PIX, router,
> dedicated VPN gateway, what are you ( and Cisco TAC ) finding?
>
> Host_A----inside
> network-----NAT/PIX/IPSec------whatever-----IPSec/PIX/NAT-----inside
> network----host_B
> Data to host_B--------->nat_applied----->IPSec takes
> over--------->IPSec_undone--->nat_applied----->receives_data
>
> I believe this sequence is correct.
>
> Are you finding the problem is that under the PIX, the nat process
> interferes with the ability of the IPSec tunnels to form? Or that for some
> reason the destination is never reached? In theory there should be no
> problem of course. So are you finding this is just a major bug that Cisco
> needs to correct?
>
> I wonder if at this point in time one should stay with the design along the
> lines of:
>
> Source----->internet----->internet_router---->VPN_Tunnel_gateway-----firewal
> l-------->destination
> ( ordinary traffic is
> |----------------------------------------------------|
> sent directly to the firewall )
>
> Being somewhat new to this fascinating area of routing, I want to learn all
> I can about the pitfalls.
>
> Chuck
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of G.W.
> Akin
> Sent: Thursday, June 15, 2000 7:41 PM
> To: [EMAIL PROTECTED]
> Subject: Re: IPSEC/ VPN query
>
> until PIX 5.1.x code is re-released you should stick with terminating
> your VPN tunnel on the outside interface of the PIX. (e-mail me and
> I'll have a good sample config by then for you to use if you don't have
> one yet...)
> there is, however, one caveat... are you NAT'ing your address space? if
> so, you are chasing the wind in trying to set up a PIX-to-PIX IPSec
> tunnel, and there is no one yet in the TAC who is able to do it.
>
> GWA
>
> ___________________________________
> UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html
> FAQ, list archives, and subscription info: http://www.groupstudy.com
> Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
>
> ___________________________________
> UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html
> FAQ, list archives, and subscription info: http://www.groupstudy.com
> Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
> ---
___________________________________
UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html
FAQ, list archives, and subscription info: http://www.groupstudy.com
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
