I have a couple of hundred users accessing the outside via:
global (outside) 1 188.8.131.52-184.108.40.206 netmask 255.255.255.224
global (outside) 1 220.127.116.11 netmask 255.255.255.224
It seems that the first people that connect after a restart grab the NAT addresses and everyone else gets the PAT. It there a reason that I shouldn't give most of the registered IP's back to the ISP and just keep a smaller group? My ISP appears to be holding any PTR changes hostage until I relinquish some addresses. At issue is that my PTR is set to one of the IP's in the middle of the NAT group. Each time the firewall is reset, the mail server locks into a different outside address which causes reverse DNS to fail. Can I force the mail server to a particular address (the one the PTR is set to)?
For typical web surfing there is no real advantage to a large NAT pool and there is no real reson to not give back some addresses other than to save yourself some grief. It looks like you have a fairly small range, I don't see why your ISP would hassel you. But in any event, you can get rid of the NAT pool by doing these two commands:
no global (outside) 1 18.104.22.168-22.214.171.124 netmask 255.255.255.224
This will drop any current connections on these ip addresses. Then to set up your mail server use the static command:
The only time I can think of "needing" a large NAT pool is if you have a large user base for an application that does not work with PAT - but that's mostly a thing of the past.
As a side note - the inherited config that you are currently running is a direct copy and paste out of the PIX documentation that provides an example of setting up outbound connectivity. That section is a bit dated.
That part won't affect my slice of the job market, but I also recall that multimedia has an impact. Not sure how much - the trouble with unfamiliar networks is it's hard to tell who is doing what to whom and why.
In the end, Mark confirmed my suspicions and I went ahead a blew away the global range and added a static route to cover AOL, etc. I will just let it simmer and listen for squeaks.
We have configured the outside and inside Interface with official ipv6 adresses, set a default route on outside Interface to our router, we also have definied a rule , which also gets hits, to permit tcp from inside Interface to any6.
In Syslog I also se...