[Webinar] Streamline your web hosting managementRegister Today

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 496
  • Last Modified:

PIX 506E with internal network - getting access to device inside with IP

I have a PIX 506E with the inside interface set up for using
    configure factory-default
The outside interface is set up with an IP address, and then I've set the route using
    route outside 0 0 foo.foo.foo.foo 1

Inside the network I have a device with an IP address of I can't change it, and I want to get to it on port 443. Is it possible to get to that device using static translation, and is it just a case of implementing a static rule and putting an entry in the access-list for the outside interface?


  • 5
  • 3
1 Solution
You are right in the fact that you have to have a static translation and an ACL statement allowing the inbound 443 traffic to that IP address of  However, there is one additional thing you will need.  You will need a route to the network segment since it is not on the same network that your PIX inside interface is on,

This can either be done by a static route, or by turning on RIP or OSPF routing protocol support if you are running this on your network.  The simplest way is to put in a static route, such as:

route inside 10.0.0.x

where 10.0.0.x is the IP address of the router interface located on the network.  You will have to have some L3 device (layer 3 of the OSI model is where routing occurs).

So, in summary, here is a list of the commands to implement to get what you want.  I've used the following info in my example commands: - public IP address that is statically translated to inside address - inside router IP address on network segment which is the gateway to get to the inside network segment


static (inside,outside) netmask
access-list acl_in permit tcp any host eq 443
access-group acl_in in interface outside
route inside

Hope this helps!
> I have a device with an IP address of I can't change it,
Does this device share the same network with all the 10.0.0.x hosts? No vlans, no routers, nothing else to go between the 192.168.1.x and the 10.0.0.x networks?
The PIX itself cannot have multiple inside IP's, but if you have a vlan capable switch you can set up a virtual vlan interface on the pix...
Not sure what else to tell you without some feedback as to how this device is connected to the network.
AGBrownAuthor Commented:
These look like good answers, but unfortunately there is nothing on the inside of the firewall other than a server or two.

Does this mean that if I change the inside PIX interface to, say using
    ip address inside
I would be able to access the device? I assume if I do that I would have to remove dhcpd on the inside first, and also change the route for the inside interface?
The eGuide to Automating Firewall Change Control

Today‚Äôs IT environment is constantly changing, which affects security policies and firewall rules. Discover tips to help you embrace this change through process improvement & identify areas where automation & actionable intelligence can enhance both security and business agility.

If there is nothing but a couple of servers on the inside network, meaning no hosts (workstations), then you have to have an IP address on the PIX inside interface that is on the same subnet as the servers.

So, yes, if you change the PIX inside IP address to (assuming the other server doesn't have this IP address already) using the command you stated in your post above, then you should be able to ping from the PIX.

Also, you are correct in that you need to remove the DHCP with a "no dhcpd enable inside" and then redo the address range for DHCP addresses being given out, for example:

dhcpd address inside

Of course, use whatever range is suitable for the above command.

However, as for the "route for the inside interface" it sounds like from your wording of the above post that you don't have any inside network segments other than the segment which implies that you don't have an internal router and therefore should not have any static inside routes to have to change.  Is this the case?
AGBrownAuthor Commented:
I do have
    route inside
is this unnecessary?

I about to try the ip address change.
AGBrownAuthor Commented:
In fact this just seems to be the default set when I execute the "ip address inside" command, so don't worry about that last bit.

I think the IP address change worked, but the device isn't responding and I'm not sure why. Its quite late so I have to leave this until tuesday now, so I'll get back to you then.

Thanks for your help so far.
Yes, the route statement you listed in the above post is unnecessary.  The PIX doesn't need to be explicitly told about the route to a network segment for which it has one of it's interfaces on.  For example, after you changed the IP address of the inside interface to, the PIX now knows that to get to the network it needs to send the traffic to its inside interface.

The only reasons I can think of that the server would not respond to a ping from the PIX after you changed the inside interface's IP address are as follows:

1)  The device you're trying to ping has some sort of personal firewall or host-based IDS/IPS installed that it disallowing echo replies from that device.  Are you aware of any software or configuration on that server that would prevent echo replies?
2)  The server has an incorrect default gateway set AND an incorrect subnet mask set.  Even if only the subnet mask set on the server was incorrect , you would still get an echo reply back to the PIX if the PIX is set as it's default gateway.  And if the default gateway was incorrect and just the subnet mask was correct, you would still get an echo reply back from the server to the PIX via ARP.  Can you post the output of an "ipconfig /all" from that server you are trying to ping?

There are other things of course that could be causing this, such as a bad ethernet cable to the server, the ethernet adapter being disabled, a bad switch port, etc. and the list could go on and on.  You may want to check out these things if you haven't already.

One other thing I wanted to ask if you've tried.  Have you tried pinging the PIX inside interface from the server?  In other words, from a command prompt on, ping and see what you get...just curious.

Also, are you familiar with the capture command on the PIX?  It's like a watered down packet sniffer that can show you traffic through the PIX.  You may want to construct an ACL that will show you traffic to/from the server in question and see what the capture shows you.  For example, to show you all traffic that the PIX sees going to or coming from the server at, here's how to do it:

access-list server_traffic permit ip any host
access-list server_traffic permit ip host any
capture pixcap access-list server_traffic interface inside

Once those statements are in place, try a few pings from the PIX to the server and then from the server back to the PIX.  Then issue this command on the PIX:

show capture pixcap

It will show you the results of the capture, if any.  Let me know what you get and we can troubleshoot further.

AGBrownAuthor Commented:

That's a great reply, thank you. The server is actually not a windows server, and I was trying to avoid going on-site to find out the IP address as its a long trip. Once I'm on site, I can set the IP address to the network anyway.

I can use windows ping through the vpn to get to the inside interface on the pix. I was hoping to use nmap to scan the address range in case the server wasn't actually on, but that didn't work through the vpn. I didn't think of using ping on the PIX itself ... doh! I'll try that this evening before I go on-site.

Re: capture. I was using debug packet and debug icmp, they were giving me some info (helped me see that nmap wasn't working, and that I was hitting the static 443 on the outside interface even though it wasn't loading anything). Again, I'll try capture this evening.

So in summary. I'm going to double check the IP address on the server device. If its as it should be it would be useful to track down why I couldn't get to it, more for future knowledge than anything else, as once I've been to the device to check it I can reset it to the network anyway.

Thanks again for your help, I'll let you know the outcome.

AGBrownAuthor Commented:
Thanks for the help batry_boy, I'll play with all of this now I have time again. In the end, the server wasn't on anyway, it hadn't been reset as I had requested and was on some random fixed IP instead.

Featured Post

Evaluating UTMs? Here's what you need to know!

Evaluating a UTM appliance and vendor can prove to be an overwhelming exercise.  How can you make sure that you're getting the security that your organization needs without breaking the bank? Check out our UTM Buyer's Guide for more information on what you should be looking for!

  • 5
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now