01-05-2012 08:11 AM - edited 03-04-2019 02:50 PM
Guys, looking for a bit of help regarding a static nat statement with a route-map.
So i've got a router as follows...
interface GigabitEthernet0/1.X
encapsulation dot1Q X
ip vrf forwarding XXX
ip address 10.95.111.249 255.255.255.0
ip nat inside
ip virtual-reassembly in
interface GigabitEthernet0/0.X
encapsulation dot1Q X
ip vrf forwarding XXX
ip address 192.168.100.2 255.255.255.248
ip nat outside
standby 6 ip 192.168.100.6
standby 6 preempt
standby 6 name vLANXXX-GRPX
with a static NAT statement...
ip nat inside source static 10.111.85.22 192.168.100.6 vrf XXX route-map POLICY-NAT redundancy vLANXXX-GRPX
and the route-map with ACL
route-map POLICY-NAT permit 10
match ip address POLICY-NAT
ip access-list extended POLICY-NAT
deny ip host 10.111.85.22 host 10.122.75.24
deny ip host 10.111.85.22 host 10.122.75.25
deny ip host 10.111.85.22 host 10.122.75.26
!
I'm confused how the above is working.
If a user in the WAN comes in via 192.168.100.6 (this address is the HSRP address) they are NAT'd to 10.111.85.22 - all good there it works as intended but not sure how. I dont understand how this is working based around the route-map in the NAT statement. The route-map states
route-map POLICY-NAT permit 10
match ip address POLICY-NAT
!
ip access-list extended POLICY-NAT
deny ip host 10.111.85.22 host 10.122.75.24
deny ip host 10.111.85.22 host 10.122.75.25
deny ip host 10.111.85.22 host 10.122.75.26
Which to me states do not NAT anything between 10.111.85.22 host 10.122.75.24, 10.111.85.22 host 10.122.75.24 and 10.111.85.22 host 10.122.75.26 and do not NAT anything else because of the implicit deny at the end of the route map statements. So how is the inbound from outside to inside working between 192.168.100.6 to 10.111.85.22 and the 3 deny rules also work.
The purpose of the POLICY-NAT is to prevent 10.111.85.22 being sourced NAT to 192.168.100.6 when a connection is generated from the insdie 10.111.85.22 to 10.122.75.24, 10.122.75.25 or 10.122.75.26 on the outside.
Any help would be appreciated.
Cheers,
Solved! Go to Solution.
01-05-2012 11:17 AM
Your route-map only applies to the inside or sessions initiated from inside (ip nat inside source...). And because this is a static nat entry it nails up a nat entry so that sessions initiated from 192.168.100.6 are nat'd to 10.111.85.22. And as the previous poster noted you must include permit ip any any. If you still have issue let us know as there are some special considerations when nat'ing inside vrf.
Ryan
01-06-2012 05:27 AM
Hi,
In general when we do static NAT, it means when the connection initiated from inside to outside it will carry out with the public nated IP and when comes from outside it will be in its way.
And when we do static nat means open it can be accessible from anywhere in the internet.
So if customer doesnt want the nated ip accessible from all over the internet and accessible from only particular sources then we can bind the access rules with help of route-map.
Here is the simple example and which I have implemented for one of my customer.
ip nat inside source static tcp 10.10.10.10 3389 193.106.106.206 3389 extendable
This is accessble from anywher in the internet.
After some days customer asked me to allow the nated ip from particular sources only, so I used route-map feature like below...
ip nat inside source static tcp 10.10.10.10 3389 193.106.106.206 3389 route-map outside-connect extendable
route-map outside-connect permit 10
match ip address outside_access
ip access-list extended outside_access
permit tcp host host 198.64.146.184 eq 3389
permit tcp host host 198.64.206.194 eq 3389
So after defined the NAT statement with route-map, the nated IP only accessing from the above allowed IP's only.
Hope the above give a good way to understand the route-map bind in NAT statement.
Please rate all the helpfull posts.
Regards,
Naidu.
01-05-2012 08:48 AM
Currently it will not work at all because the access-list does not contain a permit statement.
As a result, the route-map will never have a match either.
For this to work as intended, you need to end the access-list with an implicit permit.
regards,
Leo
01-05-2012 11:17 AM
Your route-map only applies to the inside or sessions initiated from inside (ip nat inside source...). And because this is a static nat entry it nails up a nat entry so that sessions initiated from 192.168.100.6 are nat'd to 10.111.85.22. And as the previous poster noted you must include permit ip any any. If you still have issue let us know as there are some special considerations when nat'ing inside vrf.
Ryan
01-06-2012 01:24 AM
Ok thanks guys i'll take a look. All i want to achieve is a none bidirectional NAT. I only want to NAT inbound connections from 192.168.100.6 to 10.111.85.22. If 10.111.85.22 generates a connection i do not want the source to be re-written to 192.168.100.6
Cheers
01-06-2012 02:25 AM
Ok i've sorted this and got it working. Here is my config...
ip nat inside source static 10.111.85.22 192.168.100.6 vrf XXX route-map POLICY-NAT redundancy vLANXXX-GRPX
!
ip access-list extended POLICY-NAT
deny ip 10.111.X.X 0.0.0.X 10.122.X.X 0.0.0.X
!
route-map POLICY-NAT permit 10
match ip address POLICY-NAT
What this does is anything from the outside destined to 192.168.100.6 is NAT'd to 10.111.85.22, all good there. If 10.111.85.22 generates a connection to 10.122.x.x (which is out of the ip nat outside interface) it NAT exempts and doesn't re-write the source to 192.168.100.6. This is how i want the solution to work.
Its interesting to see the route-map only influences the NAT statement if the connection is generated from the inside.
And just for clarification if i remove route-map POLICY-NAT from the NAT statement the source is re-written to 192.168.100.6 if 10.111.85.22 generates a connection outbound.
Make sense?
Cheers
01-06-2012 05:27 AM
Hi,
In general when we do static NAT, it means when the connection initiated from inside to outside it will carry out with the public nated IP and when comes from outside it will be in its way.
And when we do static nat means open it can be accessible from anywhere in the internet.
So if customer doesnt want the nated ip accessible from all over the internet and accessible from only particular sources then we can bind the access rules with help of route-map.
Here is the simple example and which I have implemented for one of my customer.
ip nat inside source static tcp 10.10.10.10 3389 193.106.106.206 3389 extendable
This is accessble from anywher in the internet.
After some days customer asked me to allow the nated ip from particular sources only, so I used route-map feature like below...
ip nat inside source static tcp 10.10.10.10 3389 193.106.106.206 3389 route-map outside-connect extendable
route-map outside-connect permit 10
match ip address outside_access
ip access-list extended outside_access
permit tcp host host 198.64.146.184 eq 3389
permit tcp host host 198.64.206.194 eq 3389
So after defined the NAT statement with route-map, the nated IP only accessing from the above allowed IP's only.
Hope the above give a good way to understand the route-map bind in NAT statement.
Please rate all the helpfull posts.
Regards,
Naidu.
09-03-2021 12:46 PM
hi,
I‘m not sure, but is this statement really true?
So after defined the NAT statement with route-map, the nated IP only accessing from the above allowed IP's only.
I‘ve tested the static nat with a route-map but it‘s still possible to access the nat ip from the reverse direction with an ip-address which is‘nt part of the respective ACL…
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide