RE: VPNs on PIX

["Paul Melson" <pmelson () gmail com>]

-----Original Message-----
Subject: [fw-wiz] VPNs on PIX

> Many of our current customers have VPN connections to us. For some reason,
several of these 
> customers don't like to NAT their addresses - instead, they freely share
either there 
> private IPs with us or even their public IPs (which has two effects: we,
along with the rest 
> of the world, know the IP address of every one of their machines; we allow
their entire 
> network through our network). When one of those customers is using the
same internal network 
> addressing scheme as us (and we, for some reason, feel the need to be able
to provide their 
> entire network access to our own "if needed") we have to NAT them.

Not that you asked, but this is "A Bad Idea(tm)" and is all too common where
PIX firewalls are concerned (because of the all-too-commonly-used 'sysopt
connection permit-ipsec').  Remember, every time you do this, you accept
risk that you cannot manage.  I've never seen a setup that actually needed
to be that way.  I honestly don't know why that command even exists.


> Currently, those customers' endpoint on our end is  a few small Cisco
routers, which then 
> NAT's their addresses to something we decide. The question is, then, can
you do this on a 
> PIX and how? My coworker calls this inbound NATing, and frankly I can't
think of a better 
> term. It's seems like it ought to be possible though.

Yes it can be done on a PIX using the static command (or a global pool if a
large range is used).  It's going to look a lot like the router config.


> Secondly, what is the downfall, if any, to creating a translation on a PIX
for machines on 
> the internal network to reach machines in the DMZ which resolves only to a
public address 
> (which would naturally go to the outside PIX interface by default, and
then fail)?

None that I know of.  Creating a secondary static NAT on the inside for DMZ
hosts is the preferred method of doing this with a PIX.


> Another interesting thing about our network that I only learned today is
that several of our > Internet facing machines are on DMZ1 on a PIX.
> They have a second NIC attached to DMZ2 on the same PIX. On DMZ1, the ip
addresses are our 
> live, routable IP addresses. They claim that those on DMZ2 were initially
configured to be 
> OOB connections. I'm completely blown away by this. I KNOW its not a good
thing, and I have 
> several ideas on why (beyond it NOT being an OOB connection), but can some
of you here 
> provide more? They're AIX boxes, so you know. Though we do have one
Windows internet-facing 
> box...currently living on that DMZ2 interface. <g>

So you've got "OOB" secondary interfaces of internal AIX servers connected
to the same network as an internet-facing Windows server?  And you're having
to make a case for why this is a bad idea?  That sucks for you.  Mostly
because it means that you're firewall admins don't get it.  

If not for the Internet-facing servers, it might not be such a big deal.
They probably just needed some ACLs that restricted which machines on the
inside can talk to services on the management interfaces of those servers.
If they put the Internet-facing server in a new DMZ (which means buying the
4-port card) away from the other servers, it's probably reasonable.


> Also, I haven't responded to the syslog thread yet but I wanted to let
everyone concerned 
> (everyone, right?!) know that we're now looking at providing services for
the DoD. Needless 
> to say, if that happens I'll be getting the dedicated syslog server I
need/want - and a 
> whole new network, pretty much - to meet their security requirements.
Joy-joy!
> The rest of my team hates the idea, I love it. Is there something wrong
with me? Can I get 
> help for it?

This is a good idea.  Surely nothing can go wrong with your apathetic
firewall admins at the helm and the syslog server that nobody wants to
build.  (Is the sarcasm coming across correctly?  I can never tell in
e-mail.)

Anyway, the DoD probably won't be any worse off than it is now.

PaulM


_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards