NAT list getting hit for traffic from WAN IP

Unanswered Question
Oct 30th, 2007

I have an 871 setup at home with a fairly basic configuration (NAT, Firewall, EasyVPN, Wireless). What I've noticed is that for traffic going from the WAN interface (FastEthernet4), it seems to be hitting the ACL in place for NAT. My config:

interface Loopback0

ip address 192.168.254.1 255.255.255.255

!

interface FastEthernet4

description Cable Modem Connection

bandwidth 384

ip address dhcp

ip nat outside

ip nat enable

no ip virtual-reassembly

duplex auto

speed auto

!

interface Vlan1

no ip address

bridge-group 1

!

interface BVI1

ip address 192.168.1.1 255.255.255.0

ip nat inside

ip virtual-reassembly

!

ip nat inside source list NATLIST interface FastEthernet4 overload

!

ip access-list extended NATLIST

permit ip 192.168.1.0 0.0.0.255 any

deny ip any any log

!

Seems to work just fine, but I will see this in my logs:

Oct 30 17:21:38 PDT: %SEC-6-IPACCESSLOGP: list NATLIST denied udp 76.22.98.39(0) -> 68.87.69.146(0), 1 packet

Oct 30 17:21:38 PDT: %SEC-6-IPACCESSLOGP: list NATLIST denied udp 76.22.98.39(0) -> 140.142.16.34(0), 1 packet

Oct 30 17:21:56 PDT: %SEC-6-IPACCESSLOGDP: list NATLIST denied icmp 76.22.98.39 -> 24.64.94.41 (0/0), 1 packet

Oct 30 17:23:38 PDT: %SEC-6-IPACCESSLOGP: list NATLIST denied udp 76.22.98.39(0) -> 207.188.29.230(0), 1 packet

Oct 30 17:25:38 PDT: %SEC-6-IPACCESSLOGDP: list NATLIST denied icmp 76.22.98.39 -> 121.18.13.100 (0/0), 2 packets

Oct 30 17:27:38 PDT: %SEC-6-IPACCESSLOGDP: list NATLIST denied icmp 76.22.98.39 -> 24.64.94.41 (0/0), 1 packet

Where 76.22.98.39 is the dynamic IP address from the cable provider. If the traffic isn't passing through the router, why is it trying to NAT it?

IOS Version is 12.4(6)T9

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (1 ratings)
Loading.
johnnylingo Tue, 10/30/2007 - 18:46

Good suggestion, but I removed that, cleared the log, and even rebooted the router. Same thing is still happening.

johnnylingo Wed, 10/31/2007 - 16:43

When I shutdown my internal interface and do a "clear ip nat trans *", it remains empty. Doing a "debug ip nat detailed" doesn't show any hits either.

So it's like the packets never really get NAT'ed, but still are hitting that list somehow.

I can post a full config later.

johnnylingo Fri, 11/02/2007 - 16:57

Here's my config. Network setup is:

192.168.76.0/24 - Network Equipment

192.168.77.0/24 - Workstations

192.168.78.0/24 - EasyVPN Clients

192.168.79.0/24 - Loopback Addresses

Just for kicks, I did try disabling QoS and EasyVPN on my WAN interface. No change.

Attachment: 
Edison Ortiz Fri, 11/02/2007 - 17:09

It is odd but personally just remove deny ip any any log from the NATLIST ACL.

No reason being there since you get an implicit deny.

milan.kulik Mon, 11/05/2007 - 01:26

Hi,

are you sure the suspicious traffic is not coming from your LAN?

There might be a PC in your LAN with a malware (spyware, botnet, etc.) installed, sending out a traffic with a source IP address spoofed, e.g.

BR,

Milan

brom Fri, 11/09/2007 - 07:27

Ahh I think I see the problem here. Your getting the traffic which is originating from the router hitting the ACL and being denied... (as it should be)

The only problem is its logging the events and its annoying.

Here is my solution

ip access-list extended nat-outbound

remark Permitted addresses to NAT

permit ip 192.168.0.0 0.0.0.255 any

remark External IP Address does not need natting (dont log its attempts)

deny ip host any

remark Deny and log all other traffic trying to NAT

deny ip any any log

The biggest problem is your modem seem to be getting a DHCP address. This makes it kinda hard to put its IP address in the access list (unless its the same address every time)

Hope that helps

Ben

FlorianCokl Mon, 10/10/2011 - 05:59

Hello Brom,

I am facing the same situation that I can see a whole bunch of log-entries which state that IP-packets with the source address of the routers own WAN-interface-address are trying to reach a variety of IPs somewhere out there.

I don't feel fine with just ignoring something - in only very rare situations this has been a good advise. I believe this is not a solution.

There's just one naging question you should be able to answer.

Since when needs the routers traffic translation? If the router sends packets because it want's to reach a destination for some reason it uses as source-address the address of the interface the traffic is supposed to leave and send's it directly there, doesn't it?

So why in the world are there thousends of packets denied by the NAT-process (ofcourse, the NATACL doesn't allow this address), all showing the same pattern

(pattern == protocol=udp AND source=ownWANIP AND port=0 AND destination=someIPoutthere AND port=0) as you can see from the following output, cause I think this is supicious and tryed it - wow! How do these packets get to the NAT-process anyway?!

000894: Oct 10 06:57:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.11(0), 1 packet 

000895: Oct 10 06:58:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 195.96.0.3(0), 4 packets 

000896: Oct 10 06:59:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 130.149.17.21(0), 1 packet 

000897: Oct 10 06:59:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.12(0), 1 packet 

000898: Oct 10 07:02:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.11(0), 1 packet 

000899: Oct 10 07:04:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 195.96.0.3(0), 16 packets 

000900: Oct 10 07:05:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 130.149.17.21(0), 2 packets 

000901: Oct 10 07:05:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.12(0), 2 packets 

000902: Oct 10 07:08:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.11(0), 1 packet 

000903: Oct 10 07:09:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 195.96.0.3(0), 5 packets 

000904: Oct 10 07:11:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 130.149.17.21(0), 1 packet 

000905: Oct 10 07:11:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.12(0), 1 packet 

000906: Oct 10 07:13:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.11(0), 1 packet 

000907: Oct 10 07:14:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 195.96.0.3(0), 14 packets 

000908: Oct 10 07:16:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 130.149.17.21(0), 2 packets 

000909: Oct 10 07:16:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.12(0), 2 packets 

000910: Oct 10 07:18:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.11(0), 2 packets 

000911: Oct 10 07:19:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 195.96.0.3(0), 2 packets 

000913: Oct 10 07:22:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 130.149.17.21(0), 2 packets 

000914: Oct 10 07:22:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.12(0), 3 packets 

000915: Oct 10 07:23:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.11(0), 2 packets 

000916: Oct 10 07:24:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 195.96.0.3(0), 8 packets 

000917: Oct 10 07:27:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 130.149.17.21(0), 3 packets 

000918: Oct 10 07:27:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.12(0), 2 packets 

000919: Oct 10 07:29:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.11(0), 3 packets 

000920: Oct 10 07:30:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 195.96.0.3(0), 2 packets 

000921: Oct 10 07:33:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 130.149.17.21(0), 3 packets 

000922: Oct 10 07:33:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.12(0), 3 packets 

000923: Oct 10 07:34:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.11(0), 2 packets 

000924: Oct 10 07:35:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 195.96.0.3(0), 24 packets 

000925: Oct 10 07:38:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 130.149.17.21(0), 2 packets 

000926: Oct 10 07:38:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.12(0), 2 packets 

000928: Oct 10 07:39:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.11(0), 3 packets 

000929: Oct 10 07:43:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 195.96.0.3(0), 1 packet 

000930: Oct 10 07:43:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 130.149.17.21(0), 2 packets 

000931: Oct 10 07:43:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.12(0), 2 packets 

000932: Oct 10 07:44:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.11(0), 2 packets 

000936: Oct 10 07:47:35: %SEC-6-IPACCESSLOGP: list FAE00IN denied tcp 222.173.130.154(6000) -> 212.152.155.204(1433), 1 packet 

000937: Oct 10 07:49:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 195.96.0.3(0), 2 packets 

000938: Oct 10 07:49:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 130.149.17.21(0), 2 packets 

000939: Oct 10 07:49:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.12(0), 2 packets 

000940: Oct 10 07:50:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.11(0), 2 packets 

000941: Oct 10 07:54:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 195.96.0.3(0), 5 packets 

000942: Oct 10 07:54:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 130.149.17.21(0), 1 packet 

000943: Oct 10 07:54:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.12(0), 1 packet 

000946: Oct 10 07:56:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.11(0), 2 packets 

000947: Oct 10 08:00:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 195.96.0.3(0), 7 packets 

000948: Oct 10 08:00:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 130.149.17.21(0), 2 packets 

000949: Oct 10 08:00:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.12(0), 2 packets 

000950: Oct 10 08:01:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.11(0), 1 packet 

000951: Oct 10 08:05:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 195.96.0.3(0), 15 packets 

000952: Oct 10 08:05:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 130.149.17.21(0), 1 packet 

000953: Oct 10 08:05:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.12(0), 1 packet 

000954: Oct 10 08:06:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.11(0), 1 packet 

000956: Oct 10 08:10:26: %SEC-6-IPACCESSLOGDP: list FORNAT denied icmp 212.152.155.204 -> 172.16.0.151 (0/0), 1 packet 

000957: Oct 10 08:10:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 195.96.0.3(0), 6 packets 

000958: Oct 10 08:10:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 130.149.17.21(0), 1 packet 

000959: Oct 10 08:10:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.12(0), 1 packet 

000960: Oct 10 08:11:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.11(0), 1 packet 

000961: Oct 10 08:14:49: %SEC-6-IPACCESSLOGP: list FAE00IN denied tcp 216.133.175.69(2087) -> 212.152.155.204(5900), 1 packet 

000962: Oct 10 08:16:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.11(0), 1 packet 

000963: Oct 10 08:16:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 195.96.0.3(0), 11 packets 

000964: Oct 10 08:16:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 130.149.17.21(0), 2 packets 

000966: Oct 10 08:16:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.12(0), 2 packets 

000968: Oct 10 08:21:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.11(0), 1 packet 

000969: Oct 10 08:21:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 195.96.0.3(0), 6 packets 

000970: Oct 10 08:21:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 130.149.17.21(0), 1 packet 

000971: Oct 10 08:21:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.12(0), 1 packet 

000972: Oct 10 08:27:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.11(0), 2 packets 

000973: Oct 10 08:27:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 195.96.0.3(0), 3 packets 

000974: Oct 10 08:27:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 130.149.17.21(0), 1 packet 

000975: Oct 10 08:27:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.12(0), 1 packet 

000976: Oct 10 08:33:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.11(0), 1 packet 

000977: Oct 10 08:33:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 195.96.0.3(0), 29 packets 

000978: Oct 10 08:33:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 130.149.17.21(0), 2 packets 

000979: Oct 10 08:33:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.12(0), 2 packets 

000980: Oct 10 08:38:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.11(0), 1 packet 

000981: Oct 10 08:39:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 130.149.17.21(0), 1 packet 

000982: Oct 10 08:39:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.12(0), 1 packet 

000983: Oct 10 08:43:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.11(0), 2 packets 

000984: Oct 10 08:43:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 195.96.0.3(0), 1 packet 

000985: Oct 10 08:44:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 130.149.17.21(0), 1 packet 

000986: Oct 10 08:44:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.12(0), 1 packet 

000987: Oct 10 08:49:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 195.96.0.3(0), 2 packets 

000988: Oct 10 08:50:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 130.149.17.21(0), 1 packet 

000989: Oct 10 08:50:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.12(0), 1 packet 

000990: Oct 10 08:52:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.11(0), 1 packet 

000991: Oct 10 08:54:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 195.96.0.3(0), 5 packets 

000992: Oct 10 08:59:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 195.96.0.3(0), 6 packets 

000993: Oct 10 08:59:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 130.149.17.21(0), 1 packet 

000994: Oct 10 08:59:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.12(0), 1 packet 

000995: Oct 10 09:00:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.11(0), 1 packet 

000996: Oct 10 09:05:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 195.96.0.3(0), 17 packets 

000997: Oct 10 09:07:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 130.149.17.21(0), 1 packet 

000998: Oct 10 09:07:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.12(0), 1 packet 

000999: Oct 10 09:09:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.11(0), 1 packet 

001002: Oct 10 09:10:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 195.96.0.3(0), 7 packets 

001003: Oct 10 09:15:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 195.96.0.3(0), 14 packets 

001004: Oct 10 09:16:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 130.149.17.21(0), 1 packet 

001005: Oct 10 09:16:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.12(0), 1 packet 

001006: Oct 10 09:17:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.11(0), 1 packet 

001007: Oct 10 09:21:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 195.96.0.3(0), 6 packets 

001008: Oct 10 09:24:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 130.149.17.21(0), 1 packet 

001009: Oct 10 09:24:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.12(0), 1 packet 

001010: Oct 10 09:26:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.11(0), 1 packet 

001012: Oct 10 09:27:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 195.96.0.3(0), 4 packets 

001013: Oct 10 09:32:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 195.96.0.3(0), 26 packets 

001014: Oct 10 09:33:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 130.149.17.21(0), 1 packet 

001015: Oct 10 09:33:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.12(0), 1 packet 

001016: Oct 10 09:35:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.11(0), 1 packet 

001017: Oct 10 09:37:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 195.96.0.3(0), 1 packet 

001018: Oct 10 09:41:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 130.149.17.21(0), 1 packet 

001019: Oct 10 09:41:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.12(0), 1 packet 

001020: Oct 10 09:43:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.11(0), 1 packet 

001021: Oct 10 09:43:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 195.96.0.3(0), 1 packet 

001022: Oct 10 09:48:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 195.96.0.3(0), 74 packets 

001023: Oct 10 09:50:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 130.149.17.21(0), 1 packet 

001024: Oct 10 09:50:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.12(0), 1 packet 

001027: Oct 10 09:52:49: %SEC-6-IPACCESSLOGP: list FORNAT denied udp 212.152.155.204(0) -> 131.130.1.11(0), 1 packet 

brom Mon, 10/17/2011 - 05:24

Wow.. this is an old discussion.

Anyhow... this is quite normal. All packets leaving your router should go through the NAT process.

If the packet comes from the router then there is no reason to NAT it.

If you see my previous post I have

deny   ip host any

This ACL line basically says. Dont NAT anything coming from the router and dont worry about logging it.

I would guess your address is 212.152.155.204

I assume you have a few services running on the router such as DNS or NTP.

ps The whole port 0 thing is actually not an issue. All it means is the router hasnt done any processing to evaluate the port. (Its just a performance thing)

Regards

Ben

FlorianCokl Mon, 10/17/2011 - 12:42

Hello Ben,

yes it is - I stumbled over it because I saw the same thins at somenones else site.

However, I tried it with my router and - booom

I still believe that denying the fact that there are packets hitting the NAT-ACL with the routers WAN-IP isn't going to help in any way. As you said: packets goint through the router need NAT, and packets originated by the router ....

Yes these services you mentioned are active - I still want to know where these packets come from?! Where do they originate? Or could it be that somehow packets achieve it to get through the ACL because they use one of the open ports. I thought about IP in IP but dead end. These packets must have something to do with the destination address. Somehow the sender must have pushed them into the network and according to the routing-table the router tried to send them out again. Then there's NAT which denies these packets from getting nated. However - the packet is still leaving the router.

If there were 1 or 2 a day I wouldn't bother - but hundrets?

Kind Regards

FlorianCokl Mon, 10/10/2011 - 06:00

Hello,

do you have the answers already? If so please let me know!

Kind Regards

Florian

johnnylingo Tue, 10/18/2011 - 00:25

Wow, this thread is 4 years old and still no answer or solution!  Do I win a prize?

I still have this problem.  Here's a configuration sample:

interface Ethernet0 description Connection to the Internet ip address dhcp ip nat outside!ip nat inside source list NATLIST interface Ethernet0 overload!ntp server 209.114.111.1 source Ethernet0ntp server 140.142.16.34 source Ethernet0

And here's the syslog entries:

Oct 17 18:10:57 PDT: %SEC-6-IPACCESSLOGP: list NATLIST denied udp 99.X.Y.Z(123) -> 209.114.111.1(123), 2 packets
Oct 17 18:12:57 PDT: %SEC-6-IPACCESSLOGP: list NATLIST denied udp 99.X.Y.Z(123) -> 140.142.16.34(123), 12 packets

The good news is it appears to be a cosmetic bug, since NTP is working:

#sh ntp st Clock is synchronized, stratum 3, reference is 209.114.111.1
brom Tue, 10/18/2011 - 01:24

This isnt a bug. Its normal expected behaviour.

Here is a quick detail on what a packet does on your router.

1) A packet is created by a process on your router (such as DNS or NTP)

2) The packet is routed out the WAN service

3) The packet has a source address of the outside address of the router eg 212.152.155.204

4) The packet is checked to see.. do I need to NAT it. The router then checkes its NAT ACL. The NAT ACL probably says something like "NAT if the soruce address is from a private address". In this case the packet is NOT from the private address range so it is denied from going through the NAT process.

5) The packet which is not NATed (because it does not need to be) is then send out the WAN link.

WHen you get a denied NAT message. It does not mean the packet has been dropped. It just means it has not been NATed

If the NAT access list has a log statement at the end you will see lots of entrys with "denied" from your local IP.

This is expected... This is the router saying I was told not to NAT this packet.. so I didnt.

If you want you can remove the log statement or just ignore the events.

Your router may be sending 100's or even 10000's of packets a day. (If you run a DNS server on the router you will get 1-3 packets every time you perform a DNS request)

This is all very normal and by design.

On the other hand if you get lots of NAT denies from IP addresses which are not in your network... then you may have another issue.

Ben

johnnylingo Tue, 10/18/2011 - 08:14

If every single packet goes through the process, then what's the point of the "ip nat inside" and "ip nat outside" statements?

FlorianCokl Tue, 10/18/2011 - 13:07

cite: ".. then what's the point of the "ip nat inside" and "ip nat outside" statements? .."

exactly

FlorianCokl Tue, 10/18/2011 - 13:46

Hello Ben

I totally get what you're saying.

I have NTP enabled and the router is also "alowed" to make DNS-lookups. Believe it or not - the entries up there are truly the adresses of NTP-Servers and DNS - so far - I only flew over the entries and haven't observed each and every in every detail - you will forgive me. Good detail at your point number 1! Fantastic!

Yet - I always thought that you have to differ between traffic through the router and traffic to the router or from the router. A good example for traffic from the router are route-maps that reference on traffic originated by the router itself. For instance MGCP. There's definitley are difference on how to aply the route-map. If you aply it on traffic through the router then this won't have any effect on MGCP traffic originated by the router itself and vice versa - this I had to experience in voice-project last year where there was MGCP traffic going through the router and other routers where originating traffic itself. The config for "through the router" didn't work on an "from the router" and vice versa.

What does this have to do with NAT? Well - isn't the nat inside or nat outside an interface-specific command?! In this context that also means that it's not all the same in regards of which direction of the traffic-flow and the origination point of the traffic itself. Traffic originated by the router itself (if you look at the order how traffic is processed - there's a document from Cisco where the detailes can be observed) is at a point somewhere after any interface containing a nat inside command. All of this in the previous discussions would mean that all packets are checked at the outgoing interface for NAT? What? I thought they are checked against NAT-ACLs etc at the incoming interface!

So - this is all still awkward - sorry. This is totally counterintuitive. The point of the ACL-entry with the log attribute added to it, in our context of NAT, is to make you see if any IP-host inside is trying something it's not supposed to do, right? Why is the router asking for translation on any nat inside interface for it's own traffic? By design? Really? I do not want to see a bunch of log-entries which revolve on traffic originated by the router itself - I'd like to see only packets that really wheren't supposed to show up.

no offense intended truly

have a greate day and thank U for your attention, dilligence and effort

brom Tue, 10/18/2011 - 18:23

Ok... So NAT is bydirectional.

That means when a packet leaves the WAN interface it needs to have its souce address modified.

In your case the source address does not need to be modified because its coming from the local router and so we are seeing the log events.

When the packet comes back from the remote host (on the internet) the router will look at the NAT table and then modify the packets destination (as it places it on the local LAN with a private address)

In this case the router would look in its NAT table and wouldnt find an entry for the packets you are seeing so they are delivered to the local router process (DNS etc)

Ben

Actions

This Discussion