RE: [fw-wiz] VPNs on PIX



-----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@xxxxxxxxxxxxxxxxxx
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards



Relevant Pages

  • Re: Very basic question
    ... as the router/leased line is managed by my telecoms provider (British ... it's a very large site with 30 Internet-facing servers. ... As this router has not been suplied with a firewal we have ...
    (microsoft.public.windows.server.networking)
  • Best-practices for moving from a private (.local) to a public domain (.com)
    ... We have recently purchased a.com domain name and are running web and ... that routes the packets to and from the proper internal servers. ... internet-facing hosts to have the proper domain name? ... resources, if those resources are sometimes shared? ...
    (microsoft.public.windows.server.networking)
  • RE: Very basic question
    ... it's a very large site with 30 Internet-facing servers. ... We have recently purchased a leased line that comes with a managed Cisco ... As this router has not been suplied with a firewal we have ...
    (microsoft.public.windows.server.networking)
  • Re: Controlling server security -- to domain or not to domain?
    ... I agree with you on internet-facing servers... ... >the confines of the network (putting them in a logical ... affords additional ...
    (microsoft.public.security)