Question on PIX nat pools

I've got a PIX 525 that has a pool of NAT addresses that looks like:

x.y.170.0 - x.y.175.253 x.y.175.254

Recently, a user had problems with Internet access and I noticed her address was mapped to x.y.174.255. Traceroutes went several hops to their destination and began timing out. Pings worked some places and some places not. I'm assuming some device along the line saw it as a directed broadcast and dropped it. Clearing the translation and allowing it to be assigned again worked and the user had normal access.

- Is my assumption about what happened correct?

- Is it possible to exclude the .255 addresses in that range, or do I need to delete it and put in 6 separate ranges?

- What will be the impact to existing sessions? Will they all be reestablished?



Reply to
Loading thread data ...

Hi what subnet mask are you using? The issue is your allowing (in simple terms) through to so in that range is a valid address.

You are probably right in the fact that some routers won't unicast to a .255 but they still should see that it is a valid address if it has the correct subnet mask.

I don't know if this would work, but you can exclude an address from NAT with:

nat 0 access-list

That is generally used for site to site VPN's when you want to connect over a WAN to a private IP address. Try it, if it doesn't work then try specifiy the ranges in separate blocks.


Reply to

The mask is actually, and yes that is a valid address, but an arbitrary router out somewhere on the public Internet wouldn't have access to that, would it?

I'm trying to understand how this would work, I've never seen this before. Wouldn't this exclude a particular source address from getting translated, rather than keeping a particular address in the nat pool from it being translated to?


Reply to

Certainly not. As a general rule nothing knows what is a broadcast or network address except for the directly connected systems. It makes even less sense when referring to a NAT pool. If some random router is blocking traffic for one of your addresses then try to contact the network admin. It could be difficult to track down, though. You could try using traceroute or tracert to try to identify the anomaly, or just talk to your upstream and see if they can help.


Reply to
Sam Wilson Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.