Port Unreachable

asked 2017-12-21 17:12:45 +0000

Alex_0
1 ●1 ●3 ●2

updated 2017-12-21 18:01:16 +0000

sindy
6209 ●5 ●66 ●55

Hello, I have an issue with resolving webpages on my network. I have couple of network on my infrastructure. 192.168.150.0/24 for my servers 192.168.160.0/24 for my workstation and more

I checked with Microsoft, MS engineer checked my DNS servers and confirmed they are working fine. I checked with Cisco, Cisco Eng. created TCP Bypass on my ASA and added my computer on the access-list, so it seems the ASA and IPS do not inspect all the traffic generated by my computer. I installed Wire Shark on my computer and tried to open https://My.t-mobile.com I noticed some "Destination unreachable (Port unreachable)" from my computer to my internal DNS server. I can ping my internal DNS server

Unfortunately I cannot upload the result as a text file, I need to have 60 points (???)

Any idea? Thank you in Advance for your time Alex

1071    2017-12-21 11:15:14.373439  192.168.160.99  192.168.150.1   ICMP    123 Destination unreachable (Port unreachable)
Frame 1071: 123 bytes on wire (984 bits), 123 bytes captured (984 bits) on interface 0
    Interface id: 0 (\Device\NPF_{EB87B223-29FF-4EE6-AE98-E08E7F0B8A39})
        Interface name: \Device\NPF_{EB87B223-29FF-4EE6-AE98-E08E7F0B8A39}
    Encapsulation type: Ethernet (1)
    Arrival Time: Dec 21, 2017 11:15:14.373439000 Eastern Standard Time
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1513872914.373439000 seconds
    [Time delta from previous captured frame: 0.000032000 seconds]
    [Time delta from previous displayed frame: 0.000032000 seconds]
    [Time since reference or first frame: 8.893324000 seconds]
    Frame Number: 1071
    Frame Length: 123 bytes (984 bits)
    Capture Length: 123 bytes (984 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_33:31:4b (18:03:73:33:31:4b), Dst: Cisco_aa:17:47 (e4:d3:f1:aa:17:47)
    Destination: Cisco_aa:17:47 (e4:d3:f1:aa:17:47)
        Address: Cisco_aa:17:47 (e4:d3:f1:aa:17:47)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Source: Dell_33:31:4b (18:03:73:33:31:4b)
        Address: Dell_33:31:4b (18:03:73:33:31:4b)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 192.168.160.99, Dst: 192.168.150.1
    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: 109
    Identification: 0x041f (1055)
    Flags: 0x00
        0... .... = Reserved bit: Not set
        .0.. .... = Don't fragment: Not set
        ..0. .... = More fragments: Not set
    Fragment offset: 0
    Time to live: 128
    Protocol: ICMP ...

(more)

Comments

Dear Alex i have the same issue. How could you solve the problem can you share pls

IDontKnow ( 2023-12-27 11:55:22 +0000 )edit

add a comment

answered 2017-12-21 18:31:25 +0000

sindy
6209 ●5 ●66 ●55

The icmp you've posted has been sent by the client in response to a received DNS answer. This usually happens when the DNS answer arrives so late that the client does not expect it any more. So I would try to find the DNS query and the answer itself in the capture and assess the time distance between the two. Apply display filter dns.id == 0xe74a on that capture to find out. I don't remember exactly but more than a few seconds is too much. If, however, the answer comes within a second from the query, either the client or the firewall between the client and the DNS is too impatient.

edit flag offensive delete link

Comments

Hi, Thank you very much for your reply. it seems this is the exact issue I have in my network. when we try to open a page most of the time it takes a while and we see page cannot display message then we have to refresh the page two times or more OR the page resolve by itself.

But it does not happen always.

I did a test a few minutes ago and connected a test laptop to the same port on the switch which my computer is connected to and there was not any issue at all and I was able to open pages (with a little delay).

I made the filter on Wire Shark. do you have any idea why it does happen?

1070    2017-12-21 11:15:14.373407  192.168.150.1   192.168.160.99  DNS 95  Standard query response 0xe74a Server failure A geover-prod ...

(more)

Alex_0 ( 2017-12-21 18:52:23 +0000 )edit

Housekeeping note: Folks, could someone please convert the above "answer" into a comment to my own Answer? My 6000+ karma is insufficient to do that now at this new Q&A site :-)

[cmaynard: Done. I don't think the problem was a karma limit so much as a limit on comments. I temporarily raised the comment limit so I could convert it then lowered it back to its original value again, which is 2500 now, same as the old site.]

sindy ( 2017-12-21 19:29:43 +0000 )edit

@Alex_0, Wireshark tells you what has happened but only in some cases it can tell you why. If you say that two different computers experience different treatment while connected to the very same port, I would look what is different between the two.

However, with DNS the task of finding the difference is quite complex due to all the caches between the primary DNS server of the domain and the requesting machine. So to find out whether the two machines are really treated differently when querying the same fqdn, you would have to wait until the lifetime of the answer which came late to one machine expires before asking for it from the other machine, and make sure that no other machine asks the same query in the meantime.

It would require a more systematic approach to the task - to capture at your internal DNS and see how queries to ...(more)

sindy ( 2017-12-21 19:51:25 +0000 )edit

Thank you very much Sindy, the issue is killing me. Let me see what can I do

Alex_0 ( 2017-12-21 21:05:49 +0000 )edit

If you cannot speed up the DNS system your other option would be to increase the timeout values in the client which, per dns-clients-and-timeouts-part-2 are sitting at 1 second for the first DNS server configured. Regards Matthias

mrEEde ( 2017-12-25 07:35:09 +0000 )edit

see more comments

Your Answer

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

Port Unreachable

Comments

1 Answer

Comments

Your Answer

Question Tools

Stats

Related questions

Port Unreachable edit

Comments

1 Answer

Comments

Your Answer

Question Tools

Stats

Related questions

Port Unreachable