NAT configuration on a Cisco IOS router ISR G2

[Kevin Melton]

One of our Cisco clients which is a Hospitality client uses a separate Internet connection for their guests.  Several years ago we sold the customer a Cisco 2911 ISR G2.  It has provided great service since that time.

During the growth of the customers network, I have had to effect alot of trunking and subinterfaces on the ISR G2 on the connection that comes from the custemer core.

We  have a layer 3 interface on the customer core, but we keep it shut down.  We have 6 guest networks that the 2911 effectivly governs, in that I have DHCP scopes, excluded addresses, and NATing for each respective network on the 2911.

One of our more recent requirments was that one of the guest networks (Business Partner AV company) needed to have ports 554 both UDP and TCP open inbound.

I created 5 static NAT's from available public routable from a class C we own, nating them to inside addresses in that network.

Now the question:

Does it matter the order of ip nat statements to qualify what is nated to what?  When you look at the Configuratoin, you will see why we are asking the question.

ip nat translation timeout 900

ip nat translation tcp-timeout 3600

ip nat pool SC 70.33.147.150 70.33.147.175 prefix-length 24

ip nat pool 5and7 70.33.147.176 70.33.147.185 prefix-length 24

ip nat pool BHVPN 206.248.224.40 206.248.224.139 prefix-length 24

ip nat pool Rooms 206.248.224.140 206.248.224.239 prefix-length 24

ip nat pool PAV 70.33.147.186 70.33.147.225 prefix-length 24

ip nat inside source list GuestBirdwood interface GigabitEthernet0/1 overload

ip nat inside source list NAT_AVSQUASH interface GigabitEthernet0/1 overload

ip nat inside source list RoomsACL pool Rooms

ip nat inside source list TBHPavilion pool PAV

ip nat inside source list TBHSportsClub interface GigabitEthernet0/1 overload

ip nat inside source list TBHVPN pool BHVPN

ip nat inside source list TBH_5and7 pool 5and7 overload

ip nat inside source static 192.168.51.63 1.2.3.4

ip nat inside source static 192.168.51.64 1.2.3.5

ip nat inside source static 192.168.51.65 1.2.3.6

ip nat inside source static 192.168.51.66 1.2.3.7

ip nat inside source static 192.168.51.67 1.2.3.8

the bolded address are the ones which I have an ACL built for to allow for the 5 static's.  I have an acl applied on the physical interface to allow the 554 ports to come into the public addresses.

Is the NAT line in Red (since it references an ACL applied to the entire 192.168.51.0 network) by virtue that it is first in the config subsequently making my static NAT's null and void?  Or is the configuration legitimate and will work as configured.

Thank You

[Jon Marshall · Accepted solution]

Hi Kevin

Haven't spoken to you in a long time. Hope this are good with you.

To answer your question static NAT should take precedence over dynamic NAT so it does not matter what order your NAT statements appear as in the configuration.

What you may need to do is clear any dynamic NAT translations for those specific IPs just in case that specific port number has been used but it is unlikely.

Jon

[Kevin Melton]

Hello Jon!

It sure is nice to hear from You as well!

I am glad to know that the order (unlike an ACL entry) for NAT does not matter.

The only other quesiton I have is that the ACL which I have I am placing on the physical Ethernet Interface.  I was also unsure whether I may have to make an ACL which is applied only to the subinterface  on the physical interface which corresponds to the VLAN...see below:

interface GigabitEthernet0/2

description CONNECTION back to CORE in VLAN 15

no ip address

ip virtual-reassembly

duplex auto

speed auto

!

interface GigabitEthernet0/2.15

description VLAN 15 Legacy Rooms Network

encapsulation dot1Q 15

ip address 192.168.15.2 255.255.255.0

ip nat inside

ip virtual-reassembly

!

interface GigabitEthernet0/2.51

description VLAN 51 Squash

encapsulation dot1Q 51

ip address 192.168.51.1 255.255.255.0

ip nat inside

ip virtual-reassembly

!

interface GigabitEthernet0/2.52

description VLAN 52 BHSportsClub

encapsulation dot1Q 52

ip address 192.168.52.254 255.255.255.0

ip nat inside

ip virtual-reassembly

!

interface GigabitEthernet0/2.53

description VLAN 53 BHPavilion

encapsulation dot1Q 53

ip address 192.168.53.254 255.255.255.0

ip nat inside

ip virtual-reassembly

!

interface GigabitEthernet0/2.54

description VLAN 54 BHVPN

encapsulation dot1Q 54

ip address 192.168.54.254 255.255.255.0

ip nat inside

ip virtual-reassembly

I have used static NAT's before, and have had success just by placing the ACL on the physical interface and not the subinterface.

I have had a few hit counts on the ACL entries, which does lead me to beleive that the configuration is working.

91 permit tcp any host 1.2.3.4 eq 554

92 permit udp any host 1.2.3.4 eq 554

93 permit udp any host 1.2.3.5 eq 554

94 permit tcp any host 1.2.3.5 eq 554

95 permit udp any host 1.2.3.6 eq 554

96 permit tcp any host 1.2.3.6 eq 554 (7 matches)

97 permit tcp any host 1.2.3.7 eq 554 (8 matches)

98 permit udp any host 1.2.3.7 eq 554

99 permit tcp any host 1.2.3.8 eq 554 (79 matches)

100 permit tcp any host 1.2.3.8 eq 554

The business partner is claiming that they cannot connect in as they have requested.  At this point, I am thinking that perhaps they need additional ports open and just are not aware of that to ask for it.  If you could pls confirm where the ACL should go  physical vs. subinterface I would be grateful.

Thanks Jon!

[Jon Marshall · Accepted solution]

Kevin

Firstly for NAT just check the translation table ie. "sh ip nat translations" to make sure they are in there correctly.

In terms of the acl do you mean an acl for filtering or an acl for NAT ?

It's not clear from your output where you mean to apply it ie. the config you have posted is presumably the LAN interface connecting via a trunk link back to a switch. So there will be a WAN interface connecting to the internet ?

If so i would have thought you would apply the acl inbound on the WAN interface.

Perhaps you could clarify ?

Jon

[Kevin Melton]

Yes I understand the confusion.  Let me clarify.

Jon

The client uses a Metro Ethernet connection for WAN so I see why it looks like I was leading you to beleive that I was applying the ACL to the incorrect interface.  My own answer does make my last question invalid and I see that now.

I have the ACL applied to the correct interface.  The name of the ACL is "securitybhigw2", and you can see it is applied to the Metro E connection facing our provider NTelos... see below:

interface GigabitEthernet0/0

description $ETH-LAN$$ETH-SW-LAUNCH$$INTF-INFO-GE 0/0$

ip address 10.10.10.1 255.255.255.248

shutdown

duplex auto

speed auto

!

interface GigabitEthernet0/1

description FACES NTELOS - 5 MG Metro E Circuit

ip address 209.145.88.94 255.255.255.252

ip access-group securitybhiroomsgw in

ip flow ingress

ip flow egress

ip nat outside

ip virtual-reassembly

duplex auto

speed auto

!

interface GigabitEthernet0/2

description CONNECTION back to CORE in VLAN 15

no ip address

ip virtual-reassembly

duplex auto

speed auto

!

interface GigabitEthernet0/2.15

description VLAN 15 Legacy Rooms Network

encapsulation dot1Q 15

ip address 192.168.15.2 255.255.255.0

ip nat inside

ip virtual-reassembly

I hope that clarifies what I was eluding to.  I now know however that I have the inbound ACL on the correct interface, so that solves that issue I beleive.

[Jon Marshall · Accepted solution]

Kevin

I hope that clarifies what I was eluding to.  I now know however that I have the inbound ACL on the correct interface, so that solves that issue I beleive.

Yes it does. The only other way to do it would be to use outbound acls per guest network on the subinterfaces. If you did it that way you would have to use the real addresses and not the NAT IPs but i can't see an advantage to doing this.

Jon