Solved

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

Posted on 2006-11-11
9
478 Views
Last Modified: 2013-11-16
I have a PIX 506E with the inside interface set up for 10.0.0.0 using
    configure factory-default 10.0.0.1 255.255.255.0
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 192.168.1.1. 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?

Thanks,

Andy
0
Comment
Question by:AGBrown
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 5
  • 3
9 Comments
 
LVL 28

Accepted Solution

by:
batry_boy earned 500 total points
ID: 17923984
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 192.168.1.1.  However, there is one additional thing you will need.  You will need a route to the 192.168.1.0/24 network segment since it is not on the same network that your PIX inside interface is on, 10.0.0.0/24.

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 192.168.1.0 255.255.255.0 10.0.0.x

where 10.0.0.x is the IP address of the router interface located on the 10.0.0.0/24 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:

1.1.1.1 - public IP address that is statically translated to inside address 192.168.1.1
10.0.0.2 - inside router IP address on 10.0.0.0/24 network segment which is the gateway to get to the inside 192.168.1.0/24 network segment

Commands:

static (inside,outside) 1.1.1.1 192.168.1.1 netmask 255.255.255.255
access-list acl_in permit tcp any host 1.1.1.1 eq 443
access-group acl_in in interface outside
route inside 192.168.1.0 255.255.255.0 10.0.0.2

Hope this helps!
0
 
LVL 79

Expert Comment

by:lrmoore
ID: 17925235
> I have a device with an IP address of 192.168.1.1. 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.
0
 
LVL 12

Author Comment

by:AGBrown
ID: 17927112
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 192.168.1.2 using
    ip address inside 192.168.1.2 255.255.255.0
I would be able to access the 192.168.1.1 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?
0
Surfing Is Meant To Be Done Outdoors

Featuring its rugged IP67 compliant exterior and delivering broad, fast, and reliable Wi-Fi coverage, the AP322 is the ideal solution for the outdoors. Manage this AP with either a Firebox as a gateway controller, or with the Wi-Fi Cloud for an expanded set of management features

 
LVL 28

Expert Comment

by:batry_boy
ID: 17927345
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 192.168.1.2 (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 192.168.1.1 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 192.168.1.50-192.168.1.70 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 192.168.1.0/24 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?
0
 
LVL 12

Author Comment

by:AGBrown
ID: 17927360
I do have
    route inside 10.0.0.0 255.255.255.0 10.0.0.1
is this unnecessary?

I about to try the ip address change.
0
 
LVL 12

Author Comment

by:AGBrown
ID: 17927402
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.
0
 
LVL 28

Expert Comment

by:batry_boy
ID: 17927804
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 192.168.1.2, the PIX now knows that to get to the 192.168.1.0 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 192.168.1.1, ping 192.168.1.1 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 192.168.1.1, here's how to do it:

access-list server_traffic permit ip any host 192.168.1.1
access-list server_traffic permit ip host 192.168.1.1 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.

Regards...
0
 
LVL 12

Author Comment

by:AGBrown
ID: 17929129
batry_boy,

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 10.0.0.0/24 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 192.168.1.1, 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 192.168.1.1 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 10.0.0.0/24 network anyway.

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

Andy
0
 
LVL 12

Author Comment

by:AGBrown
ID: 17972224
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 192.168.1.1 anyway, it hadn't been reset as I had requested and was on some random fixed IP instead.
0

Featured Post

Efficient way to get backups off site to Azure

This user guide provides instructions on how to deploy and configure both a StoneFly Scale Out NAS Enterprise Cloud Drive virtual machine and Veeam Cloud Connect in the Microsoft Azure Cloud.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Suggested Solutions

This article offers some helpful and general tips for safe browsing and online shopping. It offers simple and manageable procedures that help to ensure the safety of one's personal information and the security of any devices.
This past year has been one of great growth and performance for OnPage. We have added many features and integrations to the product, making 2016 an awesome year. We see these steps forward as the basis for future growth.
Both in life and business – not all partnerships are created equal. As the demand for cloud services increases, so do the number of self-proclaimed cloud partners. Asking the right questions up front in the partnership, will enable both parties …
Both in life and business – not all partnerships are created equal. Spend 30 short minutes with us to learn:   • Key questions to ask when considering a partnership to accelerate your business into the cloud • Pitfalls and mistakes other partners…

749 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question