NAT not working correctly, need different NAT on 2 different outside interfaces

[Richard Bradfield]

We have started using an external SIP service for our phones.Normally traffic goes through an MPLS WAN

when going thru this service we need to NAT the phone subnet from a 10.xx.xx.xx network to a 172.xx.xx.xx network,

but only when going to the SIP service for any other internal service we do not NAT. This part on its own works ok by using below

ip nat inside source static 10.xx.xx.10 172.xx.xx.89 route-map MIFM-Test
ip nat inside source static 10.xx.xx.11 172.xx.xx.90 route-map VOIM-Test

where the route-maps specify the interface and  destination IP addresses that require the NAT

Now the complication comes with our 4G backup interface which is on the Internet., this was in use before the SIP and we use

ip nat inside source route-map NAT interface Cellular0 overload

where in this case the route-map has the ACL that includes networks and addresses that require NAT ( a VPN also goes out this interface)

AS soon as we added the voice subnet and destination addresses to the NAT ACL the phones stopped working

and we could see with the 'sh ip nat tran' that we were getting translations for both the WAN and 4G connections

We are thinking we are doing something wrong with the nat

relevent config below

no ip nat service sip udp port 5060
ip nat inside source route-map NAT interface Cellular0 overload
ip nat inside source static 10.xx.xx.10 172.xx.xx.89 route-map MIFM-Test
ip nat inside source static 10.xx.xx.11 172.xx.xx.90 route-map VOIM-Test

ip access-list extended MIFM
permit ip host 10.xx.xx.10 202.xx.xx.0 0.0.0.31
permit ip host 10.xx.xx.10 202.yy.xx.0 0.0.7.255
permit ip host 10.xx.xx.10 host 8.8.8.8
ip access-list extended NAT
deny ip 172.16.0.0 0.0.255.255 10.0.0.0 0.255.255.255
deny ip 172.16.0.0 0.0.255.255 172.16.0.0 0.0.255.255
deny ip 10.xx.0.0 0.0.255.255 10.0.0.0 0.255.255.255
deny ip 10.xx.0.0 0.0.255.255 172.16.0.0 0.0.255.255
permit ip 10.xx.xx.10 0.0.0.1 202.xx.xx.16 0.0.0.7
permit ip 10.xx.xx.10 0.0.0.1 202.yy.xx.0 0.0.7.255
permit ip 10.xx.xx.10 0.0.0.1 host 8.8.8.8
ip access-list extended VOIM
permit ip host 10.xx.xx.11 202.xx.xx.0 0.0.0.31
permit ip host 10.xx.xx.11 202.yy.xx.0 0.0.7.255
permit ip host 10.xx.xx.11 host 8.8.8.8

route-map NAT permit 1
match ip address NAT
!
route-map VOIM-Test permit 10
match ip address VOIM
match interface Ethernet0.100
!
route-map MIFM-Test permit 10
match ip address MIFM
match interface Ethernet0.100

[Georg Pauwen]

Hello,

add the lines marked in bold:

ip nat inside source route-map NAT interface Cellular0 overload
ip nat inside source static 10.xx.xx.10 172.xx.xx.89 route-map MIFM-Test
ip nat inside source static 10.xx.xx.11 172.xx.xx.90 route-map VOIM-Test

!

ip access-list extended MIFM
permit ip host 10.xx.xx.10 202.xx.xx.0 0.0.0.31
permit ip host 10.xx.xx.10 202.yy.xx.0 0.0.7.255
permit ip host 10.xx.xx.10 host 8.8.8.8

!
ip access-list extended NAT
deny ip 172.16.0.0 0.0.255.255 10.0.0.0 0.255.255.255
deny ip 172.16.0.0 0.0.255.255 172.16.0.0 0.0.255.255
deny ip 10.xx.0.0 0.0.255.255 10.0.0.0 0.255.255.255
deny ip 10.xx.0.0 0.0.255.255 172.16.0.0 0.0.255.255
--> deny ip host 10.x.x.10 host 172.xx.xx.89
--> deny ip host 10.xx.xx.11 host 172.xx.xx.90
permit ip 10.xx.xx.10 0.0.0.1 202.xx.xx.16 0.0.0.7
permit ip 10.xx.xx.10 0.0.0.1 202.yy.xx.0 0.0.7.255
permit ip 10.xx.xx.10 0.0.0.1 host 8.8.8.8

!
ip access-list extended VOIM
permit ip host 10.xx.xx.11 202.xx.xx.0 0.0.0.31
permit ip host 10.xx.xx.11 202.yy.xx.0 0.0.7.255
permit ip host 10.xx.xx.11 host 8.8.8.8

!

route-map NAT permit 1
match ip address NAT
--> match interface Cellular0
!
route-map VOIM-Test permit 10
match ip address VOIM
match interface Ethernet0.100
!
route-map MIFM-Test permit 10
match ip address MIFM
match interface Ethernet0.100

[Georg Pauwen]

Actually, looking at this again, your NAT access list needs to deny what the other two access lists permit. Try the access list below:

ip access-list extended MIFM
permit ip host 10.xx.xx.10 202.xx.xx.0 0.0.0.31
permit ip host 10.xx.xx.10 202.yy.xx.0 0.0.7.255
permit ip host 10.xx.xx.10 host 8.8.8.8
ip access-list extended NAT
deny ip 172.16.0.0 0.0.255.255 10.0.0.0 0.255.255.255
deny ip 172.16.0.0 0.0.255.255 172.16.0.0 0.0.255.255
deny ip 10.xx.0.0 0.0.255.255 10.0.0.0 0.255.255.255
deny ip 10.xx.0.0 0.0.255.255 172.16.0.0 0.0.255.255
--> deny ip host 10.xx.xx.10 202.xx.xx.0 0.0.0.31
--> deny ip host 10.xx.xx.10 202.yy.xx.0 0.0.7.255
--> deny ip host 10.xx.xx.10 host 8.8.8.8
--> deny ip host 10.xx.xx.11 202.xx.xx.0 0.0.0.31
--> deny ip host 10.xx.xx.11 202.yy.xx.0 0.0.7.255
--> deny ip host 10.xx.xx.11 host 8.8.8.8
--> permit ip 10.0.0.0 0.0.0.255 any
ip access-list extended VOIM
permit ip host 10.xx.xx.11 202.xx.xx.0 0.0.0.31
permit ip host 10.xx.xx.11 202.yy.xx.0 0.0.7.255
permit ip host 10.xx.xx.11 host 8.8.8.8

[Richard Bradfield]

Hi Georg,

Thanks for your response.

The Voice subnet needs to get to the same destination whether it is going thru e0.100 the WAN or 4G the Internet.

The default route is advertised by BGP thru the WAN, if that goes then the default route is thru the 4G

so this will not work on the NAT ACL as it will stop it working

-> deny ip host 10.xx.xx.11 202.xx.xx.0 0.0.0.31
--> deny ip host 10.xx.xx.11 202.yy.xx.0 0.0.7.255
--> deny ip host 10.xx.xx.11 host 8.8.8.8

I can fix the problem by using SLA on the WAN  and an EEM script. adding the Voice subnet to the NAT ACL when required.But getting the NAT working properly would be a better fix

[Georg Pauwen]

Hello,

so the Cellular0 is your backup for ALL traffic, and the e0.100 the primary interface for ALL traffic ?

[Richard Bradfield]

Hi Georg

That is correct

[paul driver]

Hello
You say the first part of your NAT you are happy with and its only when you begin to nat traffic via the cellular interface the phones don't work if so it would make sense as you would be natting to a different public ip addressing than Ethernet0.100

[Richard Bradfield]

Hi Paul,

Thanks for your response.

Just to Clarify E0.100 is a WAN interface advertising the default route via BGP. the 4G interface is the backup interface for default traffic, but has a L2L VPN configured on it.  the problem arose once we added

permit ip 10.xx.xx.10 0.0.0.1 202.xx.xx.16 0.0.0.7
permit ip 10.xx.xx.10 0.0.0.1 202.yy.xx.0 0.0.7.255
permit ip 10.xx.xx.10 0.0.0.1 host 8.8.8.8

to the NAT ACL so that if the WAN failed then the voice subnet would connect thru the Internet. This does work if the WAN is disabled.

So we see Ip NAT translations for both interfaces even though traffic should be going thru the WAN

[paul driver]

Hello Richard

---

@Richard Bradfield wrote:

This does work if the WAN is disabled.

So we see Ip NAT translations for both interfaces even though traffic should be going thru the WAN

---

Thank you for clarifying now its much clearer, so given what you have stated, I would say you need to make sure traffic is ONLY forwarded  via the backup interface as/when the primary interface fails and to do that you can incorporate IPSLA tracking.

ip sla 10
icmp-echo x.x.x.x source interface Ethernet0.100
ip sla schedule 1 life forever start-time now
track 10 rtr 1 reachability

access-list 101 permit icmp host < source ip> host <monitored ip> echo
route-map pbr
match ip address 101
set ip next-hop <primary next hop>
set interface Null0

ip local policy route-map pbr
ip route 0.0.0.0 0.0.0.0 Ethernet0.100 <next-hop ip> track 10 name primary link
ip route 0.0.0.0 0.0.0.0 Cellular0 <next hop ip --if possible> 200 name backup link

[Richard Bradfield]

Hi Paul,

Thanks for your response, if only it was that easy. The backup interface has a VPN tunnel on it so has to be up with routes active to he VPN tunnel endpoint, also because of that we need an active NAT on that interface so the VPN traffic does not get Natted

[MHM Cisco World]

Friend 

I think you need gre or vti tunnel,

config outside under tunnel and then protect it with ipsec.

this give you exactly what you want .

https://www.cisco.com/c/en/us/support/docs/ip/generic-routing-encapsulation-gre/9221-quicktip.html