12-02-2009 06:53 AM - edited 03-11-2019 09:44 AM
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
12-02-2009 07:26 AM
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).
12-02-2009 07:59 AM
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
12-03-2009 11:36 PM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide