cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2176
Views
0
Helpful
3
Replies

%FWSM-2-106007: err msg

UHansen1976
Level 1
Level 1

Hi,

I'm seing an abundant number of the following error-msg in my fwsm-syslog:

%FWSM-2-106007: Deny inbound UDP from 192.168.12.39/53 to 192.168.12.52/51660 due to DNS Response

I know this issue has been discussed on many occasions before, but what I can't understand is why the firewall evens logs the above listed incident. The two nodes reside on the same subnet, with .52 being an appl.server and .39 being a DNS slave. We have several other hosts on the same subnet, that occasionally experience this problem, but the error is not consistent. It's happens every now and again. I had a similar expericence, where ICMP between two nodes on the same subnet failed and this was apparently caused by the fact, that the firewall replied to an ARP sent by the icmp-src host. I disabled proxyarp on that interface and the problem disappeared.

I'm now wondering, if what I see here, is the same situation. We have two set of firewall-modules, one set running 4.0.4 and the other running 3.2.8. The affected one is running 4.0.4, I'm not seing this problem on the modules running 3.2.8.

I haven't come around to do a trace yet, but hope do to so next time this problems appears. But is it possible, that a 'no sysopt proxyarp' will resolve it?

/ulrich

3 Replies 3

Herbert Baerten
Cisco Employee
Cisco Employee

When I started reading and you mentioned that the 2 hosts are on the same network, I immediately thought "proxy arp". So yes I think this is the same issue. Instead of disabling proxy-arp you could also check your "static" commands and see which one is causing the problem, and remove it or replace it (or feel free to post your (partial) config here for review).

Hi Herbert,

Thanks for your reply.

Indeed, we have defined a few statics for the DNS-slave as listed below:

static (Was-DMZ,Websrv-DMZ) 192.168.12.39 192.168.12.39 netmask 255.255.255.255
static (Was-DMZ,SydDK-DMZ) 192.168.12.39 192.168.12.39 netmask 255.255.255.255

This is because, the two other DMZ's (Websrv and SydDK) need to resolve hostnames using this DNS. The funny thing is, that I've implemented the exact same statics in our production enviroment, running 3.2.8, only the ip's different:

static (Was-DMZ,Websrv-DMZ) 10.10.240.116 10.10.240.116 netmask 255.255.255.255
static (Was-DMZ,SydDK-DMZ) 10.10.240.116 10.10.240.116 netmask 255.255.255.255

I've listed the arp-table on the fwsm and the failing aix-server, and got the following output:

AIX-server

--------------

aix056.bdunet.dk (192.168.12.39) at 0:14:5e:c7:d9:76 [ethernet] stored in bucket 107 (aix056 being the DNS)

FWSM

----------

Was-DMZ 192.168.12.39 0014.5ec7.d976

The MAC's are the same in both arp-tables (the missing 0 in the aix must be an AIX-thing).

And when I search for the MAC on the switch, where the AIX is attached, the mac is cached on the interface connected the aix and not the uplink to the CAT6509/FWSM. So it seems like there's no confusion as to where the MAC is physically located. So for now I tend to lean towards the proxyarp-setting, but I'm open to suggestions.

/ulrich

Sorry if my answer was a bit confusing. What I meant was: the problem is almost certainly caused by proxy arp. But the reason why the FWSM does proxy arp is (almost certainly) because it has a static of the form "static (...,Was-DMZ)  ..." that matches the destination host 192.168.12.3.

In other words, if you have "static(A,B) X" then fwsm will proxy-arp for address/network X on interface B.

hth

Herbert

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: