Static NAT inbound correct - Outbound using Interface IP

smolz · ‎04-04-2014

Here is the scenario that i have:

I have a router (2921) that has 2 interfaces:

G0/0 - WAN - 10.254.1.10

G0/1 - LAN - 192.168.1.230

I have a few static NATs for servers that are behind g0/1, this is the only nat config i have except for an 'ip nat inside' and 'ip nat outside' on the interfaces:

ip nat inside source static 192.168.1.231 10.254.1.11
ip nat inside source static 192.168.1.232 10.254.1.12
ip nat inside source static 192.168.1.240 10.254.1.13

I can connect to each of these on their respective NAT'd IP.

The issue that i have is when these servers go out they have the interface IP address! So if i ping a server that is across the way i see

SRC: 10.254.1.10 DST: 10.1.2.11 Protocol: ICMP

I do not understand how this would work?? i have no other NAT configuration in the router.

Jon Marshall · ‎04-04-2014

That does not sound right.

It almost sounds like a bug in the IOS version.

Can you do a ping from one of the internal servers to a remote server as you did in your example and then post the output of "sh ip nat translations".

Can you specify which server is the src IP and what is the dst IP you ping.

Jon

smolz · ‎04-04-2014

Here is the NAT table when pinging from the outside to one of the NAT'd servers:

Pinging from 10.1.2.11 to 10.254.1.13

Cisco2921#sh ip nat trans
Pro Inside global Inside local Outside local Outside global
--- 10.254.1.11 192.168.1.231 --- ---
tcp 10.254.1.12:80 192.168.1.232:80 10.1.2.11:62512 10.1.2.11:62512
tcp 10.254.1.12:443 192.168.1.232:443 10.1.2.11:62491 10.1.2.11:62491
tcp 10.254.1.12:443 192.168.1.232:443 10.1.2.11:62493 10.1.2.11:62493
--- 10.254.1.12 192.168.1.232 --- ---
icmp 10.254.1.13:1 192.168.1.240:1 10.1.2.11:1 10.1.2.11:1
tcp 10.254.1.13:22 192.168.1.240:22 10.1.2.11:62386 10.1.2.11:62386
tcp 10.254.1.13:80 192.168.1.240:80 10.1.2.11:62508 10.1.2.11:62508
tcp 10.254.1.13:80 192.168.1.240:80 10.1.2.11:62510 10.1.2.11:62510
tcp 10.254.1.13:80 192.168.1.240:80 10.1.2.11:62511 10.1.2.11:62511
icmp 10.254.1.10:21531 192.168.1.240:21531 10.1.2.11:21531 10.1.2.11:21531
udp 10.254.1.10:38288 192.168.1.240:38288 10.1.2.1:161 10.1.2.1:161
udp 10.254.1.10:55051 192.168.1.240:55051 10.1.2.1:161 10.1.2.1:161
udp 10.254.1.10:55383 192.168.1.240:55383 10.1.2.1:161 10.1.2.1:161
udp 10.254.1.10:58944 192.168.1.240:58944 10.1.2.1:161 10.1.2.1:161
udp 10.254.1.10:59854 192.168.1.240:59854 10.1.2.1:161 10.1.2.1:161
--- 10.254.1.13 192.168.1.240 --- ---

Here is from an internal server to the same outside host:

Pinging from 192.168.1.240 to 10.1.2.11

Cisco2921#sh ip nat trans
Pro Inside global Inside local Outside local Outside global
--- 10.254.1.11 192.168.1.231 --- ---
tcp 10.254.1.12:80 192.168.1.232:80 10.1.2.11:62517 10.1.2.11:62517
tcp 10.254.1.12:443 192.168.1.232:443 10.1.2.11:62491 10.1.2.11:62491
tcp 10.254.1.12:443 192.168.1.232:443 10.1.2.11:62493 10.1.2.11:62493
--- 10.254.1.12 192.168.1.232 --- ---
tcp 10.254.1.13:22 192.168.1.240:22 10.1.2.11:62386 10.1.2.11:62386
tcp 10.254.1.13:80 192.168.1.240:80 10.1.2.11:62515 10.1.2.11:62515
tcp 10.254.1.13:80 192.168.1.240:80 10.1.2.11:62516 10.1.2.11:62516
tcp 10.254.1.13:80 192.168.1.240:80 10.1.2.11:62518 10.1.2.11:62518
icmp 10.254.1.10:7163 192.168.1.240:7163 10.1.2.1:7163 10.1.2.1:7163
icmp 10.254.1.10:7184 192.168.1.240:7184 10.1.2.1:7184 10.1.2.1:7184
icmp 10.254.1.10:11548 192.168.1.240:11548 10.1.2.11:11548 10.1.2.11:11548
udp 10.254.1.10:38288 192.168.1.240:38288 10.1.2.1:161 10.1.2.1:161
udp 10.254.1.10:53384 192.168.1.240:53384 10.1.2.1:161 10.1.2.1:161
udp 10.254.1.10:58383 192.168.1.240:58383 10.1.2.1:161 10.1.2.1:161
udp 10.254.1.10:58944 192.168.1.240:58944 10.1.2.1:161 10.1.2.1:161
udp 10.254.1.10:59143 192.168.1.240:59143 10.1.2.1:161 10.1.2.1:161
--- 10.254.1.13 192.168.1.240 --- ---

Ruben Cocheno · ‎04-04-2014

and show ip nat statist

Please mark it helpfull if it was the case, and i have this problem too. Double touchdown is amazing. Thanks to make Engineering easy.

smolz · ‎04-04-2014

Cisco2921#sh ip nat statistics
Total active translations: 14 (3 static, 11 dynamic; 11 extended)
Peak translations: 40, occurred 00:57:00 ago
Outside interfaces:
GigabitEthernet0/0
Inside interfaces:
GigabitEthernet0/1
Hits: 6937 Misses: 0
CEF Translated packets: 4504, CEF Punted packets: 26
Expired translations: 399
Dynamic mappings:
-- Inside Source
[Id: 1] access-list remote_ez_internet-list interface GigabitEthernet0/0 refcount 5

Total doors: 0
Appl doors: 0
Normal doors: 0
Queued Packets: 0

Jon Marshall · ‎04-04-2014

access-list remote_ez_internet-list interface GigabitEthernet0/0

what is the above ?

Have you previously had more NAT configuration and then removed it ?

Can you post the full configuration.

JoN

smolz · ‎04-04-2014

That is apparently coming from the EZVPN configuration.

If i run:

sh access-list remote_ez_internet-list
Extended IP access list remote_ez_internet-list
10 deny ip 192.168.1.0 0.0.0.255 10.6.1.0 0.0.0.255 (2 matches)
20 permit ip 192.168.1.0 0.0.0.255 any (14 matches)
Cisco2921#

smolz · ‎04-04-2014

crypto isakmp policy 10
encr aes
hash md5
authentication pre-share
group 2
crypto isakmp keepalive 10
!
!
!
!
!
!
crypto ipsec client ezvpn remote_ez
connect auto
group MSCVPN key cisco
mode network-extension
peer 192.0.2.1
username ezvpn password ezvpn
xauth userid mode local
!
!
!
!
!
interface GigabitEthernet0/0
description --- Connection to DMZ ---
ip address 10.254.1.10 255.255.255.0
ip nat outside
ip virtual-reassembly in
duplex auto
speed auto
crypto ipsec client ezvpn remote_ez
!
interface GigabitEthernet0/1
ip address 192.168.1.230 255.255.255.0
ip nat inside
ip virtual-reassembly in
crypto ipsec client ezvpn remote_ez inside
!
interface Virtual-Template1 type tunnel
ip unnumbered GigabitEthernet0/0
tunnel mode ipsec ipv4
!
interface Vlan1
no ip address
!
!
ip nat inside source static 192.168.1.231 10.254.1.11
ip nat inside source static 192.168.1.232 10.254.1.12
ip nat inside source static 192.168.1.240 10.254.1.13
ip route 0.0.0.0 0.0.0.0 10.254.1.1

amcdonalda303 · ‎01-07-2015

Just an FYI, I had issues similar to this. Fixed with a reload. Also make sure if you're defining NAT translations with route-maps, you use them everywhere, and not assigning the ACL directly...seems to get wonky when that happens.