mailing list archives
RE: VPNs on PIX
From: "Paul Melson" <pmelson () gmail com>
Date: Mon, 20 Feb 2006 16:55:47 -0500
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
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
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
(which would naturally go to the outside PIX interface by default, and
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
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, 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
- VPNs on PIX Brian Loe (Feb 20)
- RE: VPNs on PIX Paul Melson (Feb 23)