«

I'm trying to access a static on the outside interface of our Pix,
from the inside interface. Basically we run NAT on the inside with
private IP, and I have a public global list on the outside. I also
have a static IP pointed to a 3rd DMZ interface for web services. I
need to be able to access that static from the inside interface and my
config is not letting me.

Is this possible?

I'd appreciate anyones' help. I can't seem to figure it out.


The particular static we're trying to reach is 2.1.1.158.

The pix version is 6.2 and these are 525's.


Config below, sanitized with IPs changed and some VPN stuff removed.


PIX Version 6.2(1)
nameif ethernet0 outside security0
nameif ethernet1 inside security100
nameif ethernet2 perimeter security10
nameif ethernet3 store security20
enable password xxxx encrypted
passwd xxxx encrypted
hostname xxxx
domain-name xxxx.com
fixup protocol ftp 21
fixup protocol http 80
fixup protocol h323 h225 1720
fixup protocol h323 ras 1718-1719
fixup protocol ils 389
fixup protocol rsh 514
fixup protocol rtsp 554
fixup protocol sqlnet 1521
fixup protocol sip 5060
fixup protocol skinny 2000
no fixup protocol smtp 25
names
access-list nonat permit ip 192.168.0.0 255.255.0.0 192.168.4.0
255.255.255.0
access-list nonat permit ip 192.168.0.0 255.255.0.0 192.168.2.0
255.255.255.0
access-list nonat permit ip 192.168.0.0 255.255.0.0 192.168.3.0
255.255.255.0
access-list inside_access_in permit ip any any
access-list inside_access_in permit tcp any any
access-list inside_access_in permit udp any any
access-list inside_access_in permit icmp any any
access-list store_access_in permit ip host 192.168.3.251 host
192.168.1.251
access-list store_access_in permit ip 192.168.252.0 255.255.255.0 any
access-list store_access_in permit icmp any any
access-list store_access_in permit ip host 192.168.3.252 host
192.168.1.252
access-list outside_access_in permit tcp any host 2.1.1.158 eq https
access-list outside_access_in permit tcp any host 2.1.1.158 eq telnet
access-list outside_access_in permit tcp any host 2.1.1.158 eq www
access-list outside_access_in permit tcp any host 2.1.1.157 eq smtp
access-list outside_access_in permit icmp any any
access-list split permit ip 192.168.0.0 255.255.0.0 192.168.4.0
255.255.255.0
access-list perimeter_access_in permit icmp any any
access-list perimeter_access_in permit ip any any
access-list perimeter_access_in permit tcp any any
access-list perimeter_access_in permit udp any any
pager lines 24
logging console debugging
logging monitor debugging
logging buffered debugging
interface ethernet0 auto
interface ethernet1 auto
interface ethernet2 auto
interface ethernet3 auto
mtu outside 1500
mtu inside 1500
mtu perimeter 1500
mtu store 1500
ip address outside 2.1.1.133 255.255.255.224
ip address inside 192.168.1.254 255.255.255.0
ip address perimeter 192.168.2.250 255.255.255.0
ip address store 192.168.3.254 255.255.255.0
ip audit info action alarm
ip audit attack action alarm
ip local pool vpnpool 192.168.4.1-192.168.4.99
no failover
failover timeout 0:00:00
failover poll 15
failover ip address outside 0.0.0.0
failover ip address inside 0.0.0.0
failover ip address perimeter 0.0.0.0
failover ip address store 0.0.0.0
pdm location 192.168.0.0 255.255.0.0 inside
pdm history enable
arp timeout 14400
global (outside) 1 2.1.1.135-2.1.1.154 netmask 255.255.255.224
global (outside) 1 2.1.1.155
global (perimeter) 1 192.168.2.100-192.168.2.240 netmask 255.255.255.0
nat (inside) 1 0.0.0.0 0.0.0.0 0 0
nat (perimeter) 1 0.0.0.0 0.0.0.0 0 0
static (perimeter,outside) 2.1.1.158 192.168.2.3 netmask
255.255.255.255 0 0
static (inside,perimeter) 192.168.2.254 192.168.1.2 netmask
255.255.255.255 1000 500
static (inside,perimeter) 192.168.2.253 192.168.19.5 netmask
255.255.255.255 1000 500
static (inside,perimeter) 192.168.2.252 192.168.20.25 netmask
255.255.255.255 1000 500
static (inside,perimeter) 192.168.2.251 192.168.20.30 netmask
255.255.255.255 1000 500
static (inside,perimeter) 192.168.2.99 192.168.20.200 netmask
255.255.255.255 1000 500
static (inside,perimeter) 192.168.2.98 192.168.5.206 netmask
255.255.255.255 1000 500
static (inside,perimeter) 192.168.2.97 192.168.250.201 netmask
255.255.255.255 1000 500
static (perimeter,outside) 2.1.1.157 192.168.2.2 netmask
255.255.255.255 1000 500
static (inside,perimeter) 192.168.2.95 192.168.5.119 netmask
255.255.255.255 1000 500
static (inside,perimeter) 192.168.2.90 192.168.5.25 netmask
255.255.255.255 1000 500
static (inside,store) 192.168.0.0 192.168.0.0 netmask 255.255.0.0 0 0
access-group outside_access_in in interface outside
access-group inside_access_in in interface inside
access-group perimeter_access_in in interface perimeter
access-group inside_access_in in interface store
route outside 0.0.0.0 0.0.0.0 2.1.1.129 1
route store 10.0.10.0 255.255.255.0 192.168.3.251 1
route inside 192.168.0.0 255.255.0.0 192.168.1.251 1
timeout xlate 0:15:00
timeout conn 0:15:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h323
0:05:00 sip 0:30:00 sip_media 0:02:00
timeout uauth 0:05:00 absolute
aaa-server TACACS+ protocol tacacs+
aaa-server RADIUS protocol radius
aaa-server LOCAL protocol local
snmp-server host inside 192.168.1.30
snmp-server host inside 192.168.250.209
no snmp-server location
no snmp-server contact
snmp-server community xxxxxxx
no snmp-server enable traps
floodguard enable
sysopt connection permit-ipsec
no sysopt route dnat
telnet 192.168.0.0 255.255.0.0 inside
telnet timeout 5
ssh timeout 5
terminal width 80

In article < >,
Jeff <> wrote:
:I'm trying to access a static on the outside interface of our Pix,
:from the inside interface. Basically we run NAT on the inside with
rivate IP, and I have a public global list on the outside. I also
:have a static IP pointed to a 3rd DMZ interface for web services. I
:need to be able to access that static from the inside interface and my
:config is not letting me.

:Is this possible?

No, but you probably don't care. Just configure up a static between
the inside and DMZ interface using "outside nat".

e.g., if you need to reach dmz internal IP 192.168.45.69 via
the IP 2.1.1.158, then

static (dmz, inside) 2.1.1.158 192.168.45.69 netmask 255.255.255.255

Notice that the order of the interfaces is reversed relative to
a normal static, which normally has (high-security, low-security).
When the order is reversed, you have outgoing static processing.


Now, if you need to be able to access the DMZ host under *both*
IP addresses, 192.168.45.69 and 2.1.1.158, then you are in for problems.


Do you really need to access the DMZ host by its outside IP?
Or would it be good enough to be able to access it by its host *name*?
If your requirements are to access by *name*, then the PIX can
do DNS manipulation for you provided the DNS request crosses the PIX.
(If your DNS server is on your inside, then configure your DNS
server to return different information if queried by the inside
than the outside gets.)
--
Aleph sub {Aleph sub null} little, Aleph sub {Aleph sub one} little,
Aleph sub {Aleph sub two} little infinities...

(Walter Roberson) wrote in message news:<brvilk$md5$>...
> In article < >,
> Jeff <> wrote:
> :I'm trying to access a static on the outside interface of our Pix,
> :from the inside interface. Basically we run NAT on the inside with
> rivate IP, and I have a public global list on the outside. I also
> :have a static IP pointed to a 3rd DMZ interface for web services. I
> :need to be able to access that static from the inside interface and my
> :config is not letting me.
>
> :Is this possible?
>
> No, but you probably don't care. Just configure up a static between
> the inside and DMZ interface using "outside nat".
>
> e.g., if you need to reach dmz internal IP 192.168.45.69 via
> the IP 2.1.1.158, then
>
> static (dmz, inside) 2.1.1.158 192.168.45.69 netmask 255.255.255.255
>
> Notice that the order of the interfaces is reversed relative to
> a normal static, which normally has (high-security, low-security).
> When the order is reversed, you have outgoing static processing.
>
>
> Now, if you need to be able to access the DMZ host under *both*
> IP addresses, 192.168.45.69 and 2.1.1.158, then you are in for problems.
>
>
> Do you really need to access the DMZ host by its outside IP?
> Or would it be good enough to be able to access it by its host *name*?
> If your requirements are to access by *name*, then the PIX can
> do DNS manipulation for you provided the DNS request crosses the PIX.
> (If your DNS server is on your inside, then configure your DNS
> server to return different information if queried by the inside
> than the outside gets.)

Yeah, that's the problem. We have to access both the private DMZ IP,
as well as the outside static IP.


The basic problem is we have a vendor's website out on the net that
references our site (which resolves to that static). Our web
developers in house want to be able to test that site, but it's
another domain that we don't control. Whenever they try and resolve
that IP, they get the outside address and boom, no access. We have
both outside "real" DNS and internal DNS, but we'd have to re-create
that vendors' zone file internally and that could get messy.

You know, I'm just going to tell them that they have to put it in
their hosts file for now. Screw em.


Hey, I appreciate the technical help though. For some reason, however,
this was working when we were using version 5.X software on our old
PIX. We were using conduits, though, so that may be it.