I'm experiencing an issue with a route map that I can't figure out. I posted before about route maps however this is a different issue. Below is the configuration.
ip nat inside source static 192.168.10.112 18.104.22.168 route-map NoNat
Sh route-map NoNat output:
route-map NoNat, permit, sequence 10 Match clauses: ip address (access-lists): NAT-VPN Set clauses: Policy routing matches: 0 packets, 0 bytes
NAT-VPN Extended ACL
10 deny ip 192.168.10.0 0.0.0.255 10.4.9.0 0.0.0.255 20 deny ip 192.168.10.0 0.0.0.255 174.53.0 0.0.255.255 30 deny ip 192.168.10.0 0.0.0.255 22.214.171.124 0.0.0.255 60 permit ip any any
126.96.36.199 is used in several site-to-site VPNs and I stood up a new tunnel recently using only this IP on our LAN. The issue is, when the traffic from the other end of the tunnel tries to talk to 188.8.131.52, it does not work when this route-map is attached to the static NAT. As soon as I remove the route-map, communication takes place. I don't understand how this is possible considering the extended ACL is not referencing any subnet on the other end of the tunnel. Since no subnet in the encryption domain is listed in the extended ACL, traffic should be permitted and NAT will take place. I don't understand how this route map is impacting communication with this tunnel.
Hello You have multiple static routes with the same nexthop as your advertised default so they are really not required. I assume 192.168.10.x / 10.1.21.x are not locally connected to this rtr and they reside internally being advertised by ospf
Regards your Nat It seems you have quite a large inside global addressing 6.5.120.x for NAT can you confirm if the below is what you trying to achieve?
example: route-map NONAT_HOST permit 10 match ip address NONAT
ip nat inside source static 192.168.10.100 184.108.40.206 route-map NoNat ip nat inside source static 192.168.10.112 220.127.116.11 route-map NoNat etc….
ip access-list extended NONAT deny ip host 10.1.21.30 10.6.1.0 0.0.0.255 permit ip host 10.1.21.30 any <----- static nat this host for any traffic other than the above subnet deny ip host 10.1.21.31 10.6.1.0 0.0.0.255 permit ip host 10.1.21.31 any <---- static nat this host for any traffic other than the above subnet permit ip any host 10.205.13.7 <---- static nat any host connecting to this host
Now in the translation table you should have static entries for all above which should enable external hosts to connect to the inside hosts, which I assume you will have so this failure seems to relate to the route map logic.
So can you try the following:
ip access-list extended NONAT_new permit ip host 10.1.21.30 10.6.1.0 0.0.0.255 permit ip host 10.1.21.31 10.6.1.0 0.0.0.255
route-map NONAT_HOST deny 5 match ip address NONAT_new
route-map NONAT_HOST permit 10 no match ip address NONAT
Please rate and mark as an accepted solution if you have found any of the information provided useful. This then could assist others on these forums to find a valuable answer and broadens the community’s global network.
Listen: https://smarturl.it/CCRS9E25 Follow us: twitter.com/ciscochampions
With applications and users everywhere, the networks are now, more than ever, being tasked with delivering consistent protection while providing an exceptional user exper...
Listen: https://smarturl.it/CCRS9E24 Follow us: https://twitter.com/CiscoChampion
Cisco Radio Aware Routing addresses several of the challenges faced when merging IP routing and radio communications in mobile networks, especially those exhibiti...
Listen: https://smarturl.it/CCRS9E23 Follow us: https://twitter.com/CiscoChampion The Wi-Fi 6E Catalyst 9136 access point takes advantage of the 6-GHz band to produce a network that is more reliable and secure, with higher throughput, more ...
When moving from OSPFv2 to OSPFv3, there are many changes in the format of the LSAs Type, but the most known changes are: IP prefix informations are no longer carried in Type-1 LSA and Type-2 LSA, new LSAs Type 8 and 9 are added to carry these prefixes.