C9300 NAT

[lorro]

Hi

Really hoping someone can help with this. I'm trying to setup NATing on a C9300 switch. It's an Advanced license so should be enabled. I'm trying to provide internet access for a guest network so am configuring it in a separate vrf. The config I have at the moment is:

ip access-list standard nat-list

 10 permit 192.168.1.0 0.0.0.255

!

int Gi1/0/15

  no switch

  vrf forwarding Guests

  ip address x.x.x.x 255.255.255.0

  ip nat outside

!

int vlan 400

  vrf forwarding Guests

  ip address 192.168.1.1 255.255.255.0

  ip nat inside

!

int Gi1/0/17

  switchport access vlan 400

  spanning-tree portfast

!

ip nat inside source list nat-list interface Gi1/0/15 vrf Guests overload

!

ip route vrf Guests 0.0.0.0 0.0.0.0 x.x.x.x

!

I also have a DHCP pool for the 192.168.1.0 network setup. When I connect a device to Gi1/0/17, I get an IP in the 192.168.1.x range and can ping the svi address. I can also ping the IP assigned to Gi1/0/15 so I'm sure the vrf is ok but the device traffic is never nat'd! The vrf config is:

vrf definition Guests
description Guests Internet Only
rd 192.168.1.0:24
!
address-family ipv4
exit-address-family

!

I can ping from the switch using ping vrf Guests 8.8.8.8 source vlan 400 which gets an entry in 'show ip nat translations'

I've tried moving the vlan 400 config to a routed port, which didn't help. I also initially had Gi1/0/15 as an svi which also didn't work. I tried the 'ip nat enable' labels instead of ip nat inside/outside but I don't have the ip nat source command to actually use it.

Any help greatly appreciated! 

[marce1000]

 - It seems that you have correctly set up the VRF and the NAT configuration on your Cisco C9300 switch. However, there are a few potential issues that could be causing the NAT not to work as expected. Here are some troubleshooting steps you can try:

Verify NAT Translation: Double-check that the NAT translation entry is present in the NAT translation table using the command show ip nat translations vrf Guests.

Verify ACL: Make sure the ACL nat-list is correctly matching the source IP range of your guest network. You can verify this by checking the output of the command show access-lists nat-list.

Verify Routing: Ensure that the default route is correctly configured in the VRF. Check the output of the command show ip route vrf Guests to verify that the default route is pointing to the correct next hop IP address.

Verify Interface Configuration: Confirm that the interface Gi1/0/15 is connected to the correct external network and that it is up/up. You can verify the interface status using the command show interfaces Gi1/0/15.

Verify DHCP: Make sure that the DHCP pool for the guest network is correctly configured and that DHCP requests from clients are being received and responded to. You can verify this by checking the DHCP binding table using the command show ip dhcp binding.

Verify NAT Overload: Ensure that the NAT overload (PAT) configuration is working correctly. Verify that there are no other conflicting NAT configurations on the switch that might be interfering with the NAT translation for the guest network.

Verify IP Connectivity: Check the IP connectivity from the guest network to the internet. You can use the traceroute command from a client in the guest network to a public IP address, such as traceroute 8.8.8.8, to identify any potential issues.

If after checking these aspects you are still unable to resolve the issue, it would be helpful to provide the output of relevant show commands (e.g., show ip nat translations, show access-lists, show ip route) for further analysis.

 M.

[lorro]

Hi

Thanks for the reply, show ip nat trans vrf Guests doesn't show any translations until I do a ping vrf Guests 8.8.8.8 source vlan 400. The switch is at a remote site so I left a Webex phone connected to Gi1/0/17 (on vlan 400) so it should be generating traffic trying to connect to Webex. The show ip dhcp binding shows the phone has got an address from the pool:

192.168.1.11 0168.2c7b.5db5.a6 May 22 2023 11:19 AM Automatic Active Vlan400

The Gi1/0/15 is definitely connected to the internet, the ping vrf Guests works. The show access-list does show hits but it only goes up when I ping from vlan 400. Using debug ip nat details doesn't trigger any output when I shut/no shut the interface with the ip phone connected, only when I ping from vlan 400. 

sh ip nat trans
Pro Inside global Inside local Outside local Outside global
icmp 31.121.32.130:1024 192.168.1.1:13 8.8.8.8:13 8.8.8.8:1024

sh ip access-list nat-list
Standard IP access list nat-list
10 permit 192.168.1.0, wildcard bits 0.0.0.255 (62 matches)

sh ip route vrf Guests
Extended Host Mode is enabled

Routing Table: Guests
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, m - OMP
n - NAT, Ni - NAT inside, No - NAT outside, Nd - NAT DIA
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
H - NHRP, G - NHRP registered, g - NHRP registration summary
o - ODR, P - periodic downloaded static route, l - LISP
a - application route
+ - replicated route, % - next hop override, p - overrides from PfR
& - replicated local route overrides by connected

Gateway of last resort is 31.121.32.129 to network 0.0.0.0

S* 0.0.0.0/0 [1/0] via 31.121.32.129
31.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 31.121.32.128/29 is directly connected, GigabitEthernet1/0/15
L 31.121.32.130/32 is directly connected, GigabitEthernet1/0/15
192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.1.0/24 is directly connected, Vlan400
L 192.168.1.1/32 is directly connected, Vlan400

Thanks again

[MHM Cisco World]

icmp 31.121.32.130:1024 192.168.1.1:13 8.8.8.8:13 8.8.8.8:1024 <<- all is OK still why the Port of destination is also NATing ?

[MHM Cisco World]

show ip nat translation <<- if you have entry that Good 
show ip nat verbose
show ip nat statistic 

[Flavio Miranda]

Hi

 I think IOS XE have restriction with VRF Aware NAT. 

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipaddr_nat/configuration/xe-3s/nat-xe-3s-book/iadnat-match-vrf.html#GUID-C3DA78F1-231C-4C7C-B57E-53B1EF32B385

[lorro]

Thanks for this, I don't seam to have the Match-in-vrf command available on the switch so. I tried updating it to 17.11.01 but still can't see the command. So, to check if this was the issue, I moved the other routing config on the switch to it's own vrf and removed the Guests vrf from this config so it wasn't in a vrf at all. Unfortunately I had exactly the same behaviour. Pings from the vlan svi were NAT'd but not the traffic from the IP phone connected to the switch.

[paul driver]

Hello
try the following example:
no ip nat inside source list nat-list interface Gi1/0/15 vrf Guests overload
ip nat pool NAT 10.10.10.2 10.10.10.50 prefix 24
ip nat inside source list nat-list pool NAT vrf Guests mathc-in-vrf

[lorro]

Thank you. I don't have the match-in-vrf available on the switch. I tried swapping the configs around so the other routing table was in vrf and this one wasn't and had the same issue.

[MHM Cisco World]

check the license, it seem to me you need license to run VRF in cat9k 

[lorro]

Hi

Thank you, it does require a network-advantage license, we have already bought the upgrade and applied it to the switch:

------------------------------------------------------------------------------
Technology-package Technology-package
Current Type Next reboot
------------------------------------------------------------------------------
network-advantage Smart License network-advantage
None Subscription Smart License None

[lorro · Accepted solution]

Thank you everyone for your help, I ended up getting a 930 ISR as a workaround for the issue but was recently working on a PoC for another project and was using vrfs on a 9300 to simplify the setup and stumbled on the fix. I had (quite embarrassingly) forgotten that the switch I was working on at the time was an access switch so didn't have ip routing enabled. As soon as I enabled routing, it worked perfectly

[Rich R]

Thanks for the update <smile>