Home page logo

firewall-wizards logo Firewall Wizards mailing list archives

From: "Paul Melson" <pmelson () gmail com>
Date: Mon, 20 Feb 2006 16:55:47 -0500

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

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


firewall-wizards mailing list
firewall-wizards () honor icsalabs com

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]