PIX routing problems

jon-wyatt · ‎12-15-2004

Hope someone can help me with this, it's got me scratching my head.

This problem relates to a pix535 with ten interfaces running 6.3.3.

We have voice traffic coming in from a customer on the outside interface. This traffic is then being routed to servers on an intermediatory interface, obviously with a higher security level.

The traffic isn't making it though the firewall and gives us the error message

Dec 15 14:12:50 535pix %PIX-6-110001: No route to 10.7.44.211 from 10.120.2.14

Which would suggest that we don't have a route set for 10.7.44.211 but we do

route voice_dsl 10.7.44.128 255.255.255.128 172.30.9.1 1

we also have a static for that address too.

static (voice_dsl,outside) 10.7.44.0 10.7.44.0 netmask 255.255.255.0 0 0

and I've tried removing and readding these lines, clearing the xlates afterwards with no joy.

Any ideas?

The following relevant lines are also in our config on this device but I'd be surprised if they were affecting this traffic.

route inside 10.0.0.0 255.0.0.0 172.16.30.221 1

route inside 10.7.44.150 255.255.255.255 172.17.20.221 1

route inside 10.7.44.220 255.255.255.255 172.17.20.221 1

route outside 10.120.2.0 255.0.0.0 172.25.1.221 1

static (inside,outside) 10.7.44.0 10.7.44.0 netmask 255.255.255.0 0 0

Note that all these other lines are required since data traffic passes through the inside interface, and also I have changed the names and ip's slightly as I don;t like making our actually strategy public.

Do you think that the routing error message is indicative of a problem further down the line with the pix? We can traceroute back from the destination device all the way to the source device no problem.

Does the static have to match the route that it will hit exactly?

thanks, any help is appreciated greately.

mostiguy · ‎12-15-2004

Your routes overlap, and I am not quite sure how the pix would handle them.

route inside 10.0.0.0 255.0.0.0 172.16.30.221 1

Says 10.x.x.x is on the inside interface, and should be handled by 172.16.30.221

You then give it 3 more routes for subsets of 10.x.x.x, but handled by other routers.

I'd try doing a show route on the pix, to see what its actual routing table shows, as opposed to what the configuration file looks like.

jon-wyatt · ‎12-16-2004

The show route gives exactly the same set of routes.

Can the PIX not handle overlapping ranges then? I thought it would just choose the more specific route.

I probably need to work out which routes are needed specifically now then and add the relevant statics.

This device doesn't currently have a default route, I'm considering adding the inside interface as the default route and then I can remove all the wide ranging routes currently pointing to the inside interface. I'd need to plan that change very carefully though.

I know that routers don't always show configuration settings that are considered to 'be default', do pix's operate in any similar way?

thanks,.

scoclayton · ‎12-16-2004

The PIX can handle overlapping routes. Just like IOS, it uses a best match algorithm. The routes on your PIX are most likely not the issue. I would be willing to bet a nickle that the issue resides somewhere in your xlate table and most likely, somewhere in your statics. Static statements are *not* done on a best match basis. They are read top to bottom as they appear in the config. If there is a static statement higher in the list that could apply to the traffic, it will be applied before the static that you listed in the original post could be hit. This incorrect static would then put the packet on the wrong interface and then it would do a route lookup. Since the proper routes point out a different interface than the one the packet is now on, the route lookup fails and the syslog message you are seeing is generated. (Read through this a few times and see if it makes a little more sense)

Now, with that said, the ultimate solution is to make your static statements as exact as possible. In other words, don't tell the PIX that 10.0.0.0/8 resides on the inside interface when you have 10.7.41.0/24 sitting on a seperate DMZ interface. In most cases however, this may be a bit of a challenge based on the history of how networks get pieced together. So, you can "trick" the PIX by making sure your more specific static statements ar higher in the ordered list than the more general (catch-all) statics.

This is a hard concept to get so let me know if I can explain this any better. I've done it a million times so if you want me to take a look at the config, feel free to post it.

Good luck.

Scott

jon-wyatt · ‎12-17-2004

Excellent! That was exactly what the problem was. There were two statics for 10.1.44.0/24, one for the inside interface and one for the voice interface. Removing the inside interface one solved our problems immediately. Thanks a lot.

Interestingly, there was a static much higher in the list which covered this range with a wider mask for the inside interface so it seems that the PIX does examine all statics but chooses the most specific one, if the static ranges match then it chooses the first.

Thanks again.

Jon.