Ask Your Question
0

DNS Query answer with ICMP Code 3 - Type

asked 2019-10-10 12:58:34 +0000

J.-Christophe gravatar image

updated 2019-10-10 13:41:04 +0000

grahamb gravatar image

Hi Gurus,

I have a very strange issue with our DNS server (Windows AD). Most of the DNS request works well, but from time to time I have the following (in Wireshark) "ICMP Destination unreachable - Port unreachable).

The request goes from a user workstation to a server through both a router and a firewall (which might be responsible for those issues).

Below is the trace I can see from my own workstation:

[1262] @30.722130: DNS query (type A) for ssl-google-analytics.l.google.com from 172.16.23.28 (Workstation Windows 10) to 172.16.37.30 (M$ AD 2016)

[1264] @30.723597: DNS response for ssl-google-analytics.l.google.com from 172.16.37.30 to 172.16.23.28

[1265] @30.723610: ICMP Destination unreachbable (Port unreachable) from 172.16.23.28 to 172.16.37.30

The ICMP packet contains the following information:

Frame 1265: 149 bytes on wire (1192 bits), 149 bytes captured (1192 bits) on interface 0

    Interface id: 0 (\Device\NPF_{8D19E716-28D7-489E-9AFF-F96C2D1FD70F})
        Interface name: \Device\NPF_{8D19E716-28D7-489E-9AFF-F96C2D1FD70F}
    Encapsulation type: Ethernet (1)
    Arrival Time: Oct 10, 2019 14:58:33.236365000 W. Europe Daylight Time
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1570712313.236365000 seconds
    [Time delta from previous captured frame: 0.000013000 seconds]
    [Time delta from previous displayed frame: 0.000013000 seconds]
    [Time since reference or first frame: 30.723610000 seconds]
    Frame Number: 1265
    Frame Length: 149 bytes (1192 bits)
    Capture Length: 149 bytes (1192 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: eth:ethertype:ip:icmp:ip:udp:dns]
    [Coloring Rule Name: ICMP errors]
    [Coloring Rule String: icmp.type eq 3 || icmp.type eq 4 || icmp.type eq 5 || icmp.type eq 11 || icmpv6.type eq 1 || icmpv6.type eq 2 || icmpv6.type eq 3 || icmpv6.type eq 4]
Ethernet II, Src: Dell_44:df:33 (d8:9e:f3:44:df:33), Dst: All-HSRP-routers_7b (00:00:0c:07:ac:7b)

    Destination: All-HSRP-routers_7b (00:00:0c:07:ac:7b)
        Address: All-HSRP-routers_7b (00:00:0c:07:ac:7b)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Source: Dell_44:df:33 (d8:9e:f3:44:df:33)
        Address: Dell_44:df:33 (d8:9e:f3:44:df:33)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 172.16.23.28, Dst: 172.16.37.31

    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
        0000 00.. = Differentiated Services Codepoint: Default (0)
        .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
    Total Length: 135
    Identification: 0x0916 (2326)
    Flags: 0x0000
        0... .... .... .... = Reserved bit: Not set
        .0.. .... .... .... = Don't fragment: Not set
        ..0. .... .... .... = More fragments: Not set
        ...0 0000 0000 0000 = Fragment offset: 0
    Time to live: 128
    Protocol: ICMP (1)
    Header checksum: 0x0000 [validation disabled]
    [Header checksum status: Unverified]
    Source: 172.16.23.28
    Destination: 172.16.37.31
Internet Control Message Protocol

    Type: 3 (Destination unreachable ...
(more)
edit retag flag offensive close merge delete

Comments

172.16.23.28 - workstation 172.16.37.30 - DNS server Destination: 172.16.37.31

What is 172.16.37.31?

All-HSRP-routers_7b (00:00:0c:07:ac:7b)

What is the HSRP config?

Chuckc gravatar imageChuckc ( 2019-10-10 15:03:51 +0000 )edit

Hi bubbasnmp,

172.16.37.31 is the secondary AD/DNS Server. HSRP configuration is:

interface Vlan123 description USER

 ip address 172.16.23.2 255.255.255.0
 ip helper-address 172.16.37.30  ip
 helper-address 172.16.37.31  standby
 123 ip 172.16.23.1  standby 123 timers
 msec 250 msec 750  standby 123
 priority 140  standby 123 preempt
 standby 123 authentication <secret>

Thanks,

JC

J.-Christophe gravatar imageJ.-Christophe ( 2019-10-10 15:18:16 +0000 )edit

@ all

Answers are for actual answers. Comments are for questions or observations.

grahamb gravatar imagegrahamb ( 2019-10-10 15:19:49 +0000 )edit

Thanks Graham. Still learning.

Chuckc gravatar imageChuckc ( 2019-10-10 15:22:16 +0000 )edit

The ICMP unreachable is sent from the client in response to the DNS response. Is it possible that the response came from a different router than the request was sent to? A capture containing the 3 packets in question would be really useful. You can post it to a public file share, e.g. Google Drive, DropBox etc. and post a link to it back here.

grahamb gravatar imagegrahamb ( 2019-10-10 15:45:19 +0000 )edit

1 Answer

Sort by ยป oldest newest most voted
0

answered 2019-10-10 16:43:40 +0000

SYN-bit gravatar image

The ICMP destination port unreachable message means the UDP port from which the request was sent has already been closed. So the response hits a closed door. I have seen this in different situations, but the most common one being the DNS request was sent to multiple servers and after one responded, the client stops listening on the port of the request that was not answered yet (ie was slower).

Looking at the traffic surrounding these 3 packets should give some more insight in why this might be happening in your case.

edit flag offensive delete link more

Comments

Hi Graham,

Thanks for your answer. You're right. I didn't looked at other packets but, I can see that the workstation is doing the same DNS request to both DNS servers. The first that answer makes the workstation stop listening on the port.

J.-Christophe gravatar imageJ.-Christophe ( 2019-10-11 07:23:55 +0000 )edit

If an answer has solve your issue, for the benefit of others with the same question, please accept the answer by clicking the checkmark to the left of the answer.

(BTW I'm not Graham ;-))

SYN-bit gravatar imageSYN-bit ( 2019-10-14 10:14:32 +0000 )edit

Hi Sake,

Sorry for the mixup. I just clicked the checkbox ;-)

J.-Christophe gravatar imageJ.-Christophe ( 2019-10-14 10:44:15 +0000 )edit

Great, thanks! And no worries about the mixup, I kinda barged in after you were already on a roll with Graham :-)

SYN-bit gravatar imageSYN-bit ( 2019-10-14 12:18:41 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2019-10-10 12:58:34 +0000

Seen: 10,996 times

Last updated: Oct 11 '19