A Network analysis » History » Version 5
Version 4 (VEILLARD GAROZ, Loïc, 03/20/2015 05:58 PM) → Version 5/14 (VEILLARD GAROZ, Loïc, 03/20/2015 05:59 PM)
h1. A Network analysis
Summary of Noteworthy Events:
h2. Major Abnormalities:
Your ISP's DNS server is slow to lookup names
h2. Minor Aberrations:
Certain TCP protocols are blocked in outbound traffic
Certain UDP protocols are blocked in outbound traffic
We detected at least one proxy
The network latency was somewhat high
The time to set up a TCP connection was somewhat high
Network bandwidth may be low
Network packet buffering may be excessive
The NAT's DNS proxy doesn't fully implement the DNS standard
h2. Address-based Tests:
NAT detection: NAT Detected
Local Network Interfaces: OK
DNS-based host information: OK
NAT support for Universal Plug and Play (UPnP): Not found
h2. Reachability Tests
h3. TCP connectivity:
Direct TCP connections to remote FTP servers (port 21) succeed, but do not receive the expected content.
This is most likely due to the way a NAT or firewall handles FTP traffic, as FTP causes unique problems when developing NATs and firewalls. This is most likely benign.
The client received an empty response instead of our normal banner. This suggests that a firewall, proxy, or filter initially allowed the connection and then terminated it, either because it did not understand our server's reply or decided to block the service.
Direct TCP access to remote SSH servers (port 22) is allowed.
Direct TCP access to remote SMTP servers (port 25) is allowed.
Direct TCP access to remote DNS servers (port 53) is allowed.
Direct TCP access to remote HTTP servers (port 80) is allowed.
Direct TCP access to remote POP3 servers (port 110) is allowed.
Direct TCP access to remote RPC servers (port 135) is allowed.
Direct TCP access to remote NetBIOS servers (port 139) is allowed.
Direct TCP access to remote IMAP servers (port 143) is allowed.
Direct TCP access to remote SNMP servers (port 161) is allowed.
Direct TCP access to remote HTTPS servers (port 443) is allowed.
Direct TCP access to remote SMB servers (port 445) is allowed.
Direct TCP access to remote SMTP/SSL servers (port 465) is allowed.
Direct TCP access to remote secure IMAP servers (port 585) is allowed.
Direct TCP access to remote authenticated SMTP servers (port 587) is allowed.
Direct TCP access to remote IMAP/SSL servers (port 993) is allowed.
Direct TCP access to remote POP/SSL servers (port 995) is allowed.
Direct TCP access to remote OpenVPN servers (port 1194) is allowed.
Direct TCP connections to remote PPTP Control servers (port 1723) succeed, but do not receive the expected content.
The client received an empty response instead of our normal banner. This suggests that a firewall, proxy, or filter initially allowed the connection and then terminated it, either because it did not understand our server's reply or decided to block the service.
Direct TCP access to remote SIP servers (port 5060) is allowed.
Direct TCP access to remote BitTorrent servers (port 6881) is allowed.
Direct TCP access to remote TOR servers (port 9001) is allowed.
h3. UDP connectivity (?):
Basic UDP access is available.
The client was able to send fragmented UDP traffic.
The client was able to receive fragmented UDP traffic.
UDP access to remote DNS servers (port 53) appears to pass through a firewall or proxy. The client was unable to transmit a non-DNS traffic on this UDP port, but was able to transmit a legitimate DNS request, suggesting that a proxy, NAT, or firewall intercepted and blocked the deliberately invalid request.
A DNS proxy or firewall caused the client's direct DNS request to arrive from another IP address. Instead of your IP address, the request came from 88.202.120.241.
A DNS proxy or firewall generated a new request rather than passing the client's request unmodified.
Direct UDP access to remote NTP servers (port 123) is allowed.
Direct UDP access to remote NetBIOS NS servers (port 137) is allowed.
Direct UDP access to remote NetBIOS DGM servers (port 138) is allowed.
Direct UDP access to remote IKE key exchange servers (port 500) is allowed.
Direct UDP access to remote OpenVPN servers (port 1194) is allowed.
Direct UDP access to remote Slammer servers (port 1434) is allowed.
Direct UDP access to remote L2 tunneling servers (port 1701) is allowed.
Direct UDP access to remote IPSec NAT servers (port 4500) is allowed.
Direct UDP access to remote RTP servers (port 5004) is allowed.
Direct UDP access to remote RTCP servers (port 5005) is allowed.
Direct UDP access to remote SIP servers (port 5060) is allowed.
Direct UDP access to remote VoIP servers (port 7078) is allowed.
Direct UDP access to remote VoIP servers (port 7082) is allowed.
Direct UDP access to remote SCTP servers (port 9899) is allowed.
Direct UDP access to remote Steam gaming servers (port 27005) is allowed.
Direct UDP access to remote Steam gaming servers (port 27015) is allowed.
h3. Traceroute (?): OK +
h3. Path MTU (?): OK +
h3. Hidden Proxy Detection (?): Warning –
Netalyzr detected the following proxies:
Port: 80 (HTTP), Response Time: 2 ms
Port: 443 (HTTPS), Response Time: 3 ms
h2. Network Access Link Properties
Network performance (?): Latency: 720 ms, Loss: 0.0%
The round-trip time (RTT) between your computer and our server is 720 ms, which is quite high. This may be due to a variety of factors, including a significant distance between your computer and our server, a particularly slow or poor network link, or problems in your network.
We recorded no packet loss between your system and our server.
During this test, the client observed 2 reordered packets.
TCP connection setup latency (?): 580ms
The time it takes your computer to set up a TCP connection with our server is 580 ms, which is somewhat high. This may be due to a variety of factors, including distance between your computer and our server, a slow network link, or other network traffic.
Background measurement of network health (?): no transient outages
Network bandwidth (?): Upload 4.5 Mbit/s, Download 160 Kbit/s
Your Uplink: We measured your uplink's sending bandwidth at 4.5 Mbit/s. This level of bandwidth works well for many users.
Your Downlink: We measured your downlink's receiving bandwidth at 160 Kbit/s. This rate could be considered quite slow, and will affect your user experience if you perform large transfers.
During this test, the client observed 5 reordered packets.
Network buffer measurements (?): Uplink 880 ms, Downlink is good
We estimate your uplink as having 880 ms of buffering. This level can in some situations prove somewhat high, and you may experience degraded performance when performing interactive tasks such as web-surfing while simultaneously conducting large uploads. Real-time applications, such as games or audio chat, may also work poorly when conducting large uploads at the same time.
We were not able to produce enough traffic to load the downlink buffer, or the downlink buffer is particularly small. You probably have excellent behavior when downloading files and attempting to do other tasks.
h2.HTTP Tests
Address-based HTTP proxy detection (?): OK
Content-based HTTP proxy detection (?): OK
HTTP proxy detection via malformed requests (?): OK
Filetype-based filtering (?): OK
HTTP caching behavior (?): OK
JavaScript-based tests (?): OK
Sensitive proxy-introduced HTTP headers (?): OK
h2.DNS Tests
Restricted domain DNS lookup (?): OK
Unrestricted domain DNS lookup (?): OK
DNS resolver address (?): OK
DNS resolver properties (?): Lookup latency 860 ms
Your ISP's DNS resolver requires 860 ms to conduct an external lookup. It takes 100 ms for your ISP's DNS resolver to lookup a name on our server.
This is particularly slow, and you may see significant performance degradation as a result.
Your resolver correctly uses TCP requests when necessary.
Your resolver is using QTYPE=A for default queries.
Your resolver is not automatically performing IPv6 queries.
Your DNS resolver requests DNSSEC records.
Your DNS resolver advertises the ability to accept DNS packets of up to 4096 bytes.
Your DNS resolver can successfully receive a smaller (~1400 byte) DNS response.
Your DNS resolver is unable to receive a large (>1500 byte) DNS response successfully, even though it advertises itself as EDNS-enabled.
Your DNS resolver accepts DNS responses of up to 1472 bytes.
Your resolver does not use 0x20 randomization.
Your ISP's DNS server cannot use IPv6.
Your DNS resolver may have significant transport-problems with the upcoming DNSSEC deployments. The resolver is incapable of handling UDP fragmentation.
DNS glue policy (?): OK
DNS resolver port randomization (?): OK
DNS lookups of popular domains (?): OK
DNS external proxy (?): OK
DNS results wildcarding (?): OK
DNS-level redirection of specific sites (?): OK
Direct probing of DNS roots (?): OK
h2.IPv6 Tests
DNS support for IPv6 (?): OK
IPv4, IPv6, and your web browser (?): No IPv6 support
IPv6 connectivity (?): No IPv6 support
h2. Network Security Protocols
Internal Server Error on Test Report
h2. Host Properties
System clock accuracy (?): OK
Browser properties (?): OK
Uploaded data (?): OK
Summary of Noteworthy Events:
h2. Major Abnormalities:
Your ISP's DNS server is slow to lookup names
h2. Minor Aberrations:
Certain TCP protocols are blocked in outbound traffic
Certain UDP protocols are blocked in outbound traffic
We detected at least one proxy
The network latency was somewhat high
The time to set up a TCP connection was somewhat high
Network bandwidth may be low
Network packet buffering may be excessive
The NAT's DNS proxy doesn't fully implement the DNS standard
h2. Address-based Tests:
NAT detection: NAT Detected
Local Network Interfaces: OK
DNS-based host information: OK
NAT support for Universal Plug and Play (UPnP): Not found
h2. Reachability Tests
h3. TCP connectivity:
Direct TCP connections to remote FTP servers (port 21) succeed, but do not receive the expected content.
This is most likely due to the way a NAT or firewall handles FTP traffic, as FTP causes unique problems when developing NATs and firewalls. This is most likely benign.
The client received an empty response instead of our normal banner. This suggests that a firewall, proxy, or filter initially allowed the connection and then terminated it, either because it did not understand our server's reply or decided to block the service.
Direct TCP access to remote SSH servers (port 22) is allowed.
Direct TCP access to remote SMTP servers (port 25) is allowed.
Direct TCP access to remote DNS servers (port 53) is allowed.
Direct TCP access to remote HTTP servers (port 80) is allowed.
Direct TCP access to remote POP3 servers (port 110) is allowed.
Direct TCP access to remote RPC servers (port 135) is allowed.
Direct TCP access to remote NetBIOS servers (port 139) is allowed.
Direct TCP access to remote IMAP servers (port 143) is allowed.
Direct TCP access to remote SNMP servers (port 161) is allowed.
Direct TCP access to remote HTTPS servers (port 443) is allowed.
Direct TCP access to remote SMB servers (port 445) is allowed.
Direct TCP access to remote SMTP/SSL servers (port 465) is allowed.
Direct TCP access to remote secure IMAP servers (port 585) is allowed.
Direct TCP access to remote authenticated SMTP servers (port 587) is allowed.
Direct TCP access to remote IMAP/SSL servers (port 993) is allowed.
Direct TCP access to remote POP/SSL servers (port 995) is allowed.
Direct TCP access to remote OpenVPN servers (port 1194) is allowed.
Direct TCP connections to remote PPTP Control servers (port 1723) succeed, but do not receive the expected content.
The client received an empty response instead of our normal banner. This suggests that a firewall, proxy, or filter initially allowed the connection and then terminated it, either because it did not understand our server's reply or decided to block the service.
Direct TCP access to remote SIP servers (port 5060) is allowed.
Direct TCP access to remote BitTorrent servers (port 6881) is allowed.
Direct TCP access to remote TOR servers (port 9001) is allowed.
h3. UDP connectivity (?):
Basic UDP access is available.
The client was able to send fragmented UDP traffic.
The client was able to receive fragmented UDP traffic.
UDP access to remote DNS servers (port 53) appears to pass through a firewall or proxy. The client was unable to transmit a non-DNS traffic on this UDP port, but was able to transmit a legitimate DNS request, suggesting that a proxy, NAT, or firewall intercepted and blocked the deliberately invalid request.
A DNS proxy or firewall caused the client's direct DNS request to arrive from another IP address. Instead of your IP address, the request came from 88.202.120.241.
A DNS proxy or firewall generated a new request rather than passing the client's request unmodified.
Direct UDP access to remote NTP servers (port 123) is allowed.
Direct UDP access to remote NetBIOS NS servers (port 137) is allowed.
Direct UDP access to remote NetBIOS DGM servers (port 138) is allowed.
Direct UDP access to remote IKE key exchange servers (port 500) is allowed.
Direct UDP access to remote OpenVPN servers (port 1194) is allowed.
Direct UDP access to remote Slammer servers (port 1434) is allowed.
Direct UDP access to remote L2 tunneling servers (port 1701) is allowed.
Direct UDP access to remote IPSec NAT servers (port 4500) is allowed.
Direct UDP access to remote RTP servers (port 5004) is allowed.
Direct UDP access to remote RTCP servers (port 5005) is allowed.
Direct UDP access to remote SIP servers (port 5060) is allowed.
Direct UDP access to remote VoIP servers (port 7078) is allowed.
Direct UDP access to remote VoIP servers (port 7082) is allowed.
Direct UDP access to remote SCTP servers (port 9899) is allowed.
Direct UDP access to remote Steam gaming servers (port 27005) is allowed.
Direct UDP access to remote Steam gaming servers (port 27015) is allowed.
h3. Traceroute (?): OK +
h3. Path MTU (?): OK +
h3. Hidden Proxy Detection (?): Warning –
Netalyzr detected the following proxies:
Port: 80 (HTTP), Response Time: 2 ms
Port: 443 (HTTPS), Response Time: 3 ms
h2. Network Access Link Properties
Network performance (?): Latency: 720 ms, Loss: 0.0%
The round-trip time (RTT) between your computer and our server is 720 ms, which is quite high. This may be due to a variety of factors, including a significant distance between your computer and our server, a particularly slow or poor network link, or problems in your network.
We recorded no packet loss between your system and our server.
During this test, the client observed 2 reordered packets.
TCP connection setup latency (?): 580ms
The time it takes your computer to set up a TCP connection with our server is 580 ms, which is somewhat high. This may be due to a variety of factors, including distance between your computer and our server, a slow network link, or other network traffic.
Background measurement of network health (?): no transient outages
Network bandwidth (?): Upload 4.5 Mbit/s, Download 160 Kbit/s
Your Uplink: We measured your uplink's sending bandwidth at 4.5 Mbit/s. This level of bandwidth works well for many users.
Your Downlink: We measured your downlink's receiving bandwidth at 160 Kbit/s. This rate could be considered quite slow, and will affect your user experience if you perform large transfers.
During this test, the client observed 5 reordered packets.
Network buffer measurements (?): Uplink 880 ms, Downlink is good
We estimate your uplink as having 880 ms of buffering. This level can in some situations prove somewhat high, and you may experience degraded performance when performing interactive tasks such as web-surfing while simultaneously conducting large uploads. Real-time applications, such as games or audio chat, may also work poorly when conducting large uploads at the same time.
We were not able to produce enough traffic to load the downlink buffer, or the downlink buffer is particularly small. You probably have excellent behavior when downloading files and attempting to do other tasks.
h2.HTTP Tests
Address-based HTTP proxy detection (?): OK
Content-based HTTP proxy detection (?): OK
HTTP proxy detection via malformed requests (?): OK
Filetype-based filtering (?): OK
HTTP caching behavior (?): OK
JavaScript-based tests (?): OK
Sensitive proxy-introduced HTTP headers (?): OK
h2.DNS Tests
Restricted domain DNS lookup (?): OK
Unrestricted domain DNS lookup (?): OK
DNS resolver address (?): OK
DNS resolver properties (?): Lookup latency 860 ms
Your ISP's DNS resolver requires 860 ms to conduct an external lookup. It takes 100 ms for your ISP's DNS resolver to lookup a name on our server.
This is particularly slow, and you may see significant performance degradation as a result.
Your resolver correctly uses TCP requests when necessary.
Your resolver is using QTYPE=A for default queries.
Your resolver is not automatically performing IPv6 queries.
Your DNS resolver requests DNSSEC records.
Your DNS resolver advertises the ability to accept DNS packets of up to 4096 bytes.
Your DNS resolver can successfully receive a smaller (~1400 byte) DNS response.
Your DNS resolver is unable to receive a large (>1500 byte) DNS response successfully, even though it advertises itself as EDNS-enabled.
Your DNS resolver accepts DNS responses of up to 1472 bytes.
Your resolver does not use 0x20 randomization.
Your ISP's DNS server cannot use IPv6.
Your DNS resolver may have significant transport-problems with the upcoming DNSSEC deployments. The resolver is incapable of handling UDP fragmentation.
DNS glue policy (?): OK
DNS resolver port randomization (?): OK
DNS lookups of popular domains (?): OK
DNS external proxy (?): OK
DNS results wildcarding (?): OK
DNS-level redirection of specific sites (?): OK
Direct probing of DNS roots (?): OK
h2.IPv6 Tests
DNS support for IPv6 (?): OK
IPv4, IPv6, and your web browser (?): No IPv6 support
IPv6 connectivity (?): No IPv6 support
h2. Network Security Protocols
Internal Server Error on Test Report
h2. Host Properties
System clock accuracy (?): OK
Browser properties (?): OK
Uploaded data (?): OK