3rd interface for separate subnet traffic 1

[waldadam]

OK, I thougt I would ask the experts first before I delve into this.

Currently in my building there are 2 separate networks. 132.5.50.x public address space (all behind the PIX) and a 10.x.x.x network. The 10.x.x.x network is connected to another business' network via a T1. Currently the machines do not talk to the .50.x network.

What I would like to do is use the 3rd PIX interface for the 10.x.x.x network, and put all the client machines on the .50.x public network, but still allow the client machines to use the 10.x.x.x resources as they do now.

I guess what all this boils down to is how do I do this / what should the routing statement look like?

Thanks

 

[lgarner]

This should work fine. Assuming that the outside interface (security 0) is the public one, the inside i/f (security 100) is teh 132.x.x.x and you create another i/f "dmz" with security somewhere in the middle.

First, you might want to "nat 0" traffic from the inside to the dmz:
nat (inside,dmz) 0 132.2.50.0 255.255.255.0 10.x.x.x 255.x.x.x

This allows inside traffic to appear on the dmz with it's original source IP address.

Also, remember to create ACLs to allow traffic from the dmz to the inside, if needed. Replies to requests from the inside will be permitted, but any connections initiated from the dmz must be explicitely allowed.

The routing statements shouldn't change much. The clients on the 132.x.x.x network will still use the Pix inside i/f for the default route. The 10.x.x.x is directly connected, so no route needed there. Devices on the 10.x.x.x network, or their default gateway, will need a route to 132.x.x.x via the Pix. Or, if you don't use nat 0, then traffic from the inside to dmz will seem to have the dmz's address, so that route won't be needed.

 

[waldadam]

I'll give it a shot.

Also do I need to configure a gateway for the DMZ interface. Everything in this building is using 10.20.4.1 as the default gateway. The DMZ interface IP is 10.20.4.76.

 

[waldadam]

I tried inputing the command the nat (inside,dmz) 0 132.2.50.0 255.255.255.0 10.x.x.x 255.x.x.x

I got the error message: invalid number of interfaces specified. So I tried it via the web interface, and got some other error.

 

[waldadam]

I added the route dmz 10.0.0.0 255.0.0.0 10.20.4.1 now I can ping all the 10.x.x.x machines ie. 10.1.1.17 from the firewall without any problems, but I'm still working on getting the .50.x machines to be able to ping the 10.x.x.x network. I imagine it is something with the NAT I need to do.

 

[lgarner]

Sorry, I had a slight brain malfunction. You'll need to have an access-list to isolate source-destination traffic for the nat 0. The nat command by itself only takes the source address/mask. Plus, the nat command takes only the source, or inbound, interface name. D'oh.

So:
access-list no_nat permit ip 132.2.50.0 255.255.255.0 10.0.0.0 255.0.0.0.0
nat (inside) 0 access-list no_nat

For the ping: ICMP is different, and you have to have an access list to permit echo-replies to go from dmz to inside. That's because there's no connection, so they aren't "replies" in the tcp sense. They're really new packets.

access-list dmz_inbound permit icmp any any echo-reply
access-list dmz_inbound permit icmp any any time-exceeded
access-list dmz_inbound permit icmp any any unreachable
access-group dmz_inbound in interface dmz

This should work better

 

[waldadam]

OK I tried the above, but still can't get to any of the 10.x.x.x hosts from the .50.x machines.

I opened all traffice between the DMZ and the internal interface. I tried pinging 10.20.4.1 as well as going to it's webserver and share with no luck.

Do I need to remove the static route I added for the above config to work?

Thanks for all your help!!

 

[lgarner]

Hmmm. Do the 10.x.x.x computers, like 10.1.1.17, know how to get to 132.2.50.0 via the Pix DMZ?

You could also try enabling PAT. Use the same no_nat access list as above, remove the "nat (inside) 0" statement, and add (changing the "1" to something else if you already have a "nat 1", to avoid confusion):

nat (inside) 1 access-list no_nat
global (dmz) 1 interface

This will cause all 132.2.50 addresses to appear as the dmz interface address. Maybe this will actually work in your situation. In the meantime, this setup might help determine if the ping problem is in the client's outbound echo or in the echo-reply. I suspect that the replies aren't getting back.

Also, you can enable "debug icmp trace" on the Pix console to watch icmp traffic. Very good for troubleshooting- I should have mentioned it sooner.

 

[waldadam]

Oh geese, I forgot about the route back. Duh.

I get someone on their end to work on it.

Thanks again.

 

[waldadam]

OK, once the route back was added, everything worked like a charm! You da Man!

 

[waldadam]

From the 132.2.50.x hosts I can now ping all the 10.20.4.x, but I can't ping anything but 10.20.4.x, like 10.1.1.17. Is it something on my end (Pix) or is it something on the othern end of things (Return route)?

 

[waldadam]

Never mind, it was on their end. He hadn't added the return route to the other routers / gateways.

 

[lgarner]

Glad it worked. Sometimes it's the simple things.