But my query is what would be the below deny ACL converted to ??? OLD CONFIG.... nat (server) 0 access-list nat-server access-list nat-server extended deny ip object-group A-NETWORK 172.x.x.0 255.255.255.0
Will permit & deny have same configuration after migration???
Sorry I missed that. Since we don't use access-lists for NAT in 8.3, you'll need to make sure that your NAT statements don't match the traffic that would have been a "deny" ACE in pre-8.3. As long as the traffic doesn't match the NAT line, it won't follow that translation--this is the 8.3 equivalent of the "deny" ACE.
For example, if you have a 192.168.0.x/24 subnet, but you don't want to NAT exempt the host at 192.168.0.100, you need to use 2 different NAT statements that will exclude the host at 192.168.0.100--one line will match 192.168.0.1 through 192.168.0.99 and one will match 192.168.0.101 through 192.168.0.254. You can use objects with the range keyword to accomplish this:
In 8.2 and prior versions, there was a NAT order of operation and in that nat exemption came before anything else. I guess the deny ACL you had was the traffic you did not want to get exempted from NAT.
In 8.3, the NAT order of operation is only based on a NAT table. The order is Manual NAT, Auto NAT and then After-Auto NAT. Now in such a case, i dont think you need to bother about the deny ACLs in the nat exemption.
If you could tell your exact requirement, then i can comment what can be done on 8.3 for that.
Login to the FXOS chassis manager.
Direct your browser to https://hostname/, and log-in using the user-name and password.
Go to Help > About and check the current version:
Check the current version availa...
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...