Re: bypassing PIX limitation

[Paolo Supino <paolo () actcom net il>]

Hi David

   Do you have any unused PIX that you can lend indefinitly? I don't 
have any free and my budget os 0 :-(



TIA
Paolo


David Swafford wrote:

> Hi Paolo,
>  
> In your existing network, are you using any of the 172.28.x.x address 
> space?  If not, then one option that comes to my mind is that you 
> could setup another Pix box who's sole purpose is to connect to the 
> partner's tunnel (if the traffic is not too demanding maybe something 
> small like a PIX 506?)  I would then suggest that you somehow 
> propagate a route that points to the PIX as being the next hop gateway 
> for all 172.28.x.x addresses.  This most likely involves the need to 
> purchase another PIX or maybe just setting another interface on a 
> cisco router running the IOS firewall would work? 
>  
> Just a few thoughts.
>  
> David Swafford.
>  
>  
> > Hi Kevin
> >
> >    The IP address space assigned to me is not part of their public IP
> > address space. I apologize, I explained myself wrong.
> > Hopefully the following information will be clearer: The network behind
> > my PIX is 192.168.99.x (the pix has a public IP address). Our partner
> > uses IP addresses on network 172.28.x.x/16. They want me to use on my
> > network IP addresses on subnet 172.28.150.32/28.
> >
> >
> >
> >
> >
> >
> > TIA
> > Paolo
> >
> >
> >
> > Horvath, Kevin M. wrote:
> >
> >  
> > > When you say carved out of their IP network, I assume you are 
> talking about
> > > the public assigned IP space, as the private ip space is anyones.  
> If this
> > > is correct then whoever wrote their policy needs to go to some 
> basic routing
> > > training as that just doesn't make any sense.  You should be able 
> to nat
> > > traffic across a vpn tunnel, although I have never tried it, since 
> nat is
> > > done before packets are encrypted.  Your problem will be that you 
> have to
> > > assign the outside ip block from the partner to your global 
> statement which
> > > will probably give you issues, as it breaks routing concepts 
> (meaning those
> > > aren't assigned/routed to you so they wont go anywhere, but since 
> they are
> > > going over an ipsec tunnel its plausible).  Even if you get it 
> working from
> > > your side it will be interesting to see how they handle their incoming
> > > public ip space from an ipsec tunnel since its routed to their outside
> > > interface already.  The more and more I think about this the more I 
> realize
> > > it should not even be tried.  Its just a bad idea altogether.  I 
> just hope
> > > you mean private ip not the partners public ip space when you say " 
> carved
> > > out of their overall IP network range"?
> > >
> > > Kevin M. Horvath
> > > CISSP, CCSP, GCIH, INFOSEC, CQS-FW, CQS-VPN, CQS-IDS, CCNA
> > > SAIC - IT Security Division
> > > 703.868.1503
> > >
> > > -----Original Message-----
> > > From: firewall-wizards-bounces () listserv cybertrust com 
> <mailto:firewall-wizards-bounces () listserv cybertrust com>
> > > [mailto:firewall-wizards-bounces () listserv cybertrust com] On Behalf 
> Of Paolo
> > > Supino
> > > Sent: Wednesday, November 08, 2006 7:23 PM
> > > To: Firewall Wizards Security Mailing List
> > > Subject: [fw-wiz] bypassing PIX limitation
> > >
> > > Hi
> > >
> > >  I have a network that is protected by a PIX 515e running 6.3(1). I 
> was
> > > asked to setup a IPSEC VPN with a partner. The partner's security 
> policy
> > > mandates that  a remote encryption domain must use IP addresses on a
> > > subnet carved out of their overall IP network range. The network 
> behind
> > > my PIX uses IP addresses on a subnet that is outside of their IP
> > > network. Adding a second IP to my network isn't supported by the 
> PIX OS.
> > > To bypass this limitation I thought of NATing packets going into 
> the VPN
> > > tunnel.  I've been looking for documentation for such a scenario, but
> > > can't find anything. Can packets going into a VPN tunnel be NATed?
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > TIA
> > > Paolo
> > >
> > > _______________________________________________
> > > firewall-wizards mailing list
> > > firewall-wizards () listserv icsalabs com 
> <mailto:firewall-wizards () listserv icsalabs com>
> > > https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
> > >
> > >
> > >
> > >    
> >
> > _______________________________________________
> > firewall-wizards mailing list
> > firewall-wizards () listserv icsalabs com 
> <mailto:firewall-wizards () listserv icsalabs com>
> > https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
> >
> >  
>  
>
> _______________________________________________
> firewall-wizards mailing list
> firewall-wizards () listserv icsalabs com 
> <mailto:firewall-wizards () listserv icsalabs com>
> https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
>
>
>
>
>
> ______________________________________________________
>
> Founded in Faith - Preserved with Pride - Sustained by Spirit
> ______________________________________________________
>
>
> Upcoming Events:
> ALTER OPEN HOUSE
> November 16
> 7 - 9 p.m.
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> firewall-wizards mailing list
> firewall-wizards () listserv icsalabs com
> https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
>  

_______________________________________________
firewall-wizards mailing list
firewall-wizards () listserv icsalabs com
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards