Dual Static Statements on PIX

[thule]

I have a PIX 525UR Bundle with a 4 port card in it that I have two DMZs set up on. DMZ2 is connected to a 3725 ATM router that directly connects me to our main office. My inside network is on 10.0.0.0/8. I assigned the dmz2 interface the network address 172.17.1.1/16 and the 3725 as 172.17.1.2/16. I have half a class "C" block of IP for the outside, (68.*.*.*).

I am using static to translate my servers to the outside interface

static (inside,outside) 68.*.*.20 10.10.1.20 netmask 255.255.255.255 0 0

I was told I could also use this statement to static them to the dmz2 port

static (inside,dmz2) 68.*.*.20 10.10.1.20 netmask 255.255.255.255 0 0

When I do this only about half of the machines (about 40) that I have statics set for can get to the remote site connected to the 3725. The rest won't route. But if we put in a route for 10. on the remote side to return traffic they all go through. It sounds as if the translation to the dmz2 interface is not working on all statics.

Pix software version 6.2(2)
I have one global statement:

global (outside) 1 68.*.* 126

Has anyone run accross this problem. The techs on the other end seem to thing it might be a software problem with the 6.2 release.

Any suggestions?

 

[chicocouk]

Your description seems to make no sense ... You translate hosts on an internal range of 10.x.x.x/8 to 68.*.*.*/24, and then include a return route pointing towards the 10 network?

The remote site won't need to know about the 10. network ... It only sees traffic from the 68./24 network that you translated. But if they have another way to route to the 68. network they'll use that instead ... and possibly try to come in through the external interface on your pix, hit the static rules on that interface, and depending on the acls on that interface, be allowed or not ...

I can't understand why you're translating your inside hosts to an address on your outside interface to then route them out the dmz ... have I missed something?

Also, is there any particular reason for the 6.2 release problem theory?

CCNA, MCSE, Cisco Firewall specialist, VPN specialist, wannabe CCSP

 

[thule]

Sorry the 10. return route is on the remote site....

their return route scenario is

ip route 68.*.*.0 255.255.255.128 192.168.1.10
ip route 10.0.0.0 255.0.0.0 192.168.1.10

My return route:

ip route 68.*.*.0 255.255.255.129 172.17.1.1 (my pix interface)
ip route 10.0.0.0 255.0.0.0 172.17.1.1

My atm ima interface is 192.168.1.10 (my side)
remote ima interface is 192.168.1.9 (remote side)

The intention (for DNS translation for Novell Groupwise and others) was to send my 68 numbers out the dmz2 port of the pix for the Waco office and to send them out the outside interface for the rest of the world. (all these static numbers are servers that support distance learning ( I work for a small college). So students at the the main campus can connect via a dedicated line and students outside the network can connect from anywhere off campus. Where we have been running into problems is in the connectors that send from the 68 to 68 (ip range) accross the network.

I think I found and corrected the problem today, but of course testing during office hours is hard to do. I found that my ACL on my outside interface allowed all traffic if I temporarily set it to all ip any any. Since then I have written a rule to allow our waco campus all traffic through. The thing I though strange was trace routes between the lines all show to be going down the dedicated pipe, however the outside ACL still seems to be checking the 68. subnet and applying filters.

I am not a PIX guru (not even close) but this seems to me to be a problem in the way the pix is routing between the DMZ port and the inside port. Why would it pass the traffic to the outside port first before giving it to the inside.

Can you see why I am totaly confused?

I appreciate any and all ideas that you might have on this one....

 

[chicocouk]

Just having a think about this, but have you made a typo there with your return routes? Shouldn't the return routes have the same mask on both routers, ie, it should be;

ip route 68.*.*.0 255.255.255.128 192.168.1.10 (theirs)
and
ip route 68.*.*.0 255.255.255.128 172.17.1.1 (yours)

rather than the

ip route 68.*.*.0 255.255.255.129 172.17.1.1

you quote for yours? Would the .129 mask on your router break the return route for half your hosts?

CCNA, MCSE, Cisco Firewall specialist, VPN specialist, wannabe CCSP

 

[thule]

Fat finger typing on my end it is a 128