Create a Post
Showing results for 
Search instead for 
Did you mean: 

Issue with DNS lookup from HA standby member


we have an issue on our FW-cluster standby member, causing AV/TE-Updates to fail.


Internet connection is OK, but I assume that there is an issue with DNS. If I try to resolve e.g. from our standby member, it times out and is not resolvable. The error messages vary: 


[Expert@chp-2:0]# nslookup
;; connection timed out; trying next origin
;; connection timed out; no servers could be reached


[Expert@chp-2:0]# nslookup
;; connection timed out; trying next origin

** server can't find NXDOMAIN



If I do the same with the active member, it works:

[Expert@chp-1:0]# nslookup

Non-authoritative answer:


Afterwards, in most cases (80%), the resolution works then from the standby member too for the same host.

But not always - it's a very strange behavior.


If I do a failover, the standby (now main) FW works properly. 

The DNS server are up and running, no issues at all (except this one from the HA standby member).


As far as I can see on another FW (ASA), located between CP and DNS servers, all requests are coming with the cluster IP.

I did a fw monitor and at the same time a capture on the ASA. All packets have corresponding packet captures on ASA, and there I can also see, that the servers answer to every request. But in the FW monitor, I don't see most of the answer-packets. Here's an example:


On the left side you can see the FW monitor output. Packets leave with the cluster VIP on different ports.

On the right side you can see the ASA-capture where all these packets appear, and where you can also see the answers from the DNS server (marked blue/azure)

But on the left side, these answers dont appear for the first 6 requests. Only the last, yellow one has a properly appearing answer. 

The only strange thing that bothers me, is that the packet length of the failing answers seems to be much lower than the last one (26 compared to 96).


Any ideas, what could be causing this problem?




0 Kudos
2 Replies

Have a look at this SK:


We had a similar issue.  Though it wasn't with DNS.  It was with HTTP.  The inactive cluster member was sending traffic out via the cluster IP.  but when it came back, the cluster incorrectly sent that return packet to the active host member.

0 Kudos

Was this problem solved ?

We are facing the same problems after our VSX upgrade to R80.20 (Take 91)

Even a ping from the standby node doesn't work to non SmartCenter/Logserver IPs

setting the fwha_forw_packet_to_not_active parameter doesn't seems to solving the problem





0 Kudos


Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events