Link to home
Start Free TrialLog in
Avatar of AGBrown
AGBrownFlag for United Kingdom of Great Britain and Northern Ireland

asked on

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

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
ASKER CERTIFIED SOLUTION
Avatar of batry_boy
batry_boy
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of Les Moore
> 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.
Avatar of AGBrown

ASKER

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?
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?
Avatar of AGBrown

ASKER

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.
Avatar of AGBrown

ASKER

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 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...
Avatar of AGBrown

ASKER

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
Avatar of AGBrown

ASKER

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.