Re: Pix 501 and two internal neworks.

Teedee · ‎12-06-2002

Have a PIX 501 that is moving, via nat, traffic from the inside to the outside interface with no issues (ISP on the outside interface). The problem that I have run into is this, residing within the lan on the inside interface is another network via a gateway that must be accessed.

inside ip address 10.145.254.72

other network on the inside is 10.146.1.x with a gateway of 10.145.254.x

From the console I am able to ping the 10.146.1.x lan with no problems from the ethernet side however I am unable to do so. Additonally from the console I am able to ping out to the ISP and beyond as well as the rest of the 10.145.254.0 lan. From the ethernet side am able to ping the entire 10.145.254.lan (including the gateway box) as well as to the ISP and beyond.

Have tried route inside 10.146.1.x 255.255.255.255 10.145.254.x with no luck.

Anyone have any ideas?

Thanks much!

tvanginneken · ‎12-07-2002

Hi,

there is something wrong with your subnet mask. You should NOT use 255.255.255.255 to define a route to a another NETWORK. You use this subnetmask (4 times 255) only to define a route to a specific HOST.

Try something like this:

(depending of the subnetmasks you are using)

route inside 10.146.1.0 255.255.255.0 10.145.254.x

or

route inside 10.146.1.0 255.255.0.0 10.145.254.x

or

route inside 10.146.1.0 custom_subnetmask 10.145.254.x

(where 10.145.254.x is the ip address of the internal router)

Also hold in mind the pix does not automatically allow icmp (=ping) packets through the firewall. You will have to create an icmp access-list for this.

Kind Regards,

Tom

Teedee · ‎12-07-2002

Hi Tom,

Thanks for your information - actually I am trying to get to a specific host,

10.146.1.1 through 10.145.254.70, sorry about that I should have been more clear.

The issue is that the .1 needs to be accessed and I am somewhat confused why I am able to ping him via the console but not the ethernet side. Do you have any suggestions for access-lists for this? The program that needs to be accessed is MS program?

Thanks!

Tony....

tvanginneken · ‎12-07-2002

Hi Tony,

I am going to try this setup on Monday in my office. I'll post my findings on Monday (if you can wait that long?).

Are there any messages in the logs indicating that packets are being blocked?

If you haven't logging enabled , try it this way:

logging buffered 7

logging on

You can then view the log with the 'show log' command. Be carefull with those commands, because it can degrade the performance. Level 7 generates the most output (but is handy for debugging ). Level 0 only displays emergencies.

Kind Regards,

Tom

Teedee · ‎12-07-2002

Hi Tom,

Thanks for your assistance!

I am going to head out to the site for a bit and see what I can see by viewing the log, once I have enabled it. I will send a post to you from here and show what I have discovered.

Thanks,

Tony....

Teedee · ‎12-07-2002

HI Tom,

Well have enabled the logging feature per your suggestion and have discovered the following denial statement:

106011: Deny inbound (No xlate) icmp src inside:10.145.254.75 dst inside:10.146.1.101 (type8, code 0)

It appears to be access-list issue, any ideas?

Thanks,

Tony.....

tvanginneken · ‎12-07-2002

Hi,

the pix always wants to translate the packets it has to forward. The 'nat/global' and the 'static' commands are used for this address translation when packets go into the pix in one interface, and come out of the pix on another interface. That's the normal operation mode of the pix.

But in your situation traffic goes into the pix and comes out of the pix on the same (inside) interface. The pix doesn't know how to perform the translation, hence the message '.....(No xlate)....'.

I don't have an exact answer for this problem, but you can try two things:

1. you can circumvent the problem by making 10.145.254.70 (your internal router, right?) the new default gateway for your network hosts. Add a default route (for the internet) to this router pointing to the pix.

2 add a 'nat 0' statement to your pix (but I'm not sure this wil work). When you do this, the pix knows that translation is not needed when it finds a match in the access-list. Do it like this:

access-list no_nat permit icmp 10.145.254.0 255.255.255.0 10.146.1.0 255.255.255.0

access-list no_nat permit icmp 10.146.1.0 255.255.255.0 10.145.254.0 255.255.255.0

access-list no_nat permit ip 10.145.254.0 255.255.255.0 10.146.1.0 255.255.255.0

access-list no_nat permit ip 10.146.1.0 255.255.255.0 10.145.254.0 255.255.255.0

nat (inside) 0 access-list no_nat

ps: I assumed 255.255.255.0 as your netmask, you should change it to the one you're using. I hope this will work. I can do some more test on Monday.

Kind Regards,

Tom

gfullage · ‎12-08-2002

You mention numerous times you "can't ping from the ethernet side", what does this mean exactly? Are you saying you can ping 10.146.1.1 from the PIX console, but you can't ping it from the 10.145.254.0 network?

If so, then you have your default gateway on all your workstations set to the PIX's inside address, correct? So when you ping to something in another subnet it's going to send it to the PIX. The PIX however, will have to route the packet back out the same interface it came in on, which the PIX doesn't do. You can see by your syslog that both the source and the destination are on the inside network, this will never work.

You can either add permanent static routes into the workstations, pointing them to the 1600 router for just that network. In Windows, you do this with:

> route -p add 10.146.1.0 maks 255.255.255.0 10.145.254.70

or as the previous engineer said, make the default route on all these machines the internal router. On the router put a default route pointing to teh PIX inside interface. When you ping to the 10.146.1.0 network it will be sent to the router and everything will work. When you ping to the Internet, it'll go to the router, the router will send it to teh PIX and it will also send an ICMP redirect to the PC to tel it to use the PIX from now on for that network.