Comodo download via IPV6 fails

salapis · March 22, 2013, 6:36pm

If IPv6 is enabled in your computer and supported by the ISP, you can not download any of the COMODO products!(Virus database fails too.)

For example, the link to download Comodo Internet Security is not working.
http://downloads.comodo.com/cis/download/installs/2000/standalone/cispremium_installer.exe

With ipv6 enabled
downloads.comodo.com resolves to 2a02:1788:4fd::b2ff:5201
which does not respond to the download request.

If you disable ipv6 (forcing your computer to use ipv4 only)
downloads.comodo.com resolves to 178.255.82.1
which is working OK.

Windows prefer ipv6 by default and many ISP’s start supporting IPv6 .As a result, many clients are/will be unable to download or update Comodo products.

salvatoreg · March 22, 2013, 7:03pm

There may be a problem with your ISP in routing IPv6 traffic OR you may have a network configuration error.

Looking up IP address for downloads.comodo.com...

Tracing route to downloads.comodo.com [2a02:1788:4fd::b2ff:5201]...

hop	rtt	rtt	rtt	 	ip address	fully qualified domain name
1	6	5	6	 	2001:470:1f0e:513::1	hexillion-2.tunnel.tserv8.dal1.ipv6.he.net
2	3	1	1	 	2001:470:0:78::1	gige-g2-14.core1.dal1.he.net
3	24	24	25	 	2001:470:0:1b6::2	10gigabitethernet5-4.core1.atl1.he.net
4	33	36	34	 	2001:470:0:1b5::1	10gigabitethernet6-4.core1.ash1.he.net
5	35	35	34	 	2001:504:0:2::3549:1	gc-equinix-v6.gblx.net
6	40	40	40	 	2001:450:2002:44e::2	
7	42	41	40	 	2a02:1788:4fd::b2ff:5201	downloads.comodo.com
Trace complete

-- end --

URL: Central Ops IPv6: downloads.comodo.com

SanyaIV · March 22, 2013, 7:26pm

Edit: Never mind, I misunderstood what I read on the Comodo Dragon board, sorry.

salvatoreg · March 22, 2013, 7:37pm

Just because you can resolve ‘downloads.comodo.com’ via ‘nslookup’ (or similar means), doesn’t mean you can connect to it over port 80. (HTTP)

Which threads on the Dragon board do you speak of? Can you please link us?

We are unaware of any IPv6 connectivity to any of our sites. If there is an issue, we’ll of course need to see proof of such a fault. ;D

rhgtyink · March 22, 2013, 8:22pm

It must be specific to some configs;

Works fine here.

Checked port 80 on Host/IP 2a02:1788:4fd::b2ff:5201…
The checked port (80, service http) is online/reachable!
Completed portscan in 3.0772 seconds

SanyaIV · March 22, 2013, 8:33pm

Seems like I misunderstood the Comodo Dragon thread, sorry.

salapis · March 22, 2013, 8:54pm

Well I can ping/tracert downloads.comodo.com and get a response.
I can also see the blank screen of http://downloads.comodo.com
I can see the 403 screen of http://downloads.comodo.com/cis/
As a result, I suppose I can connect to 80 port of 2a02:1788:4fd::b2ff:5201

However, I cannot download anything hosted there.
The browsers (tried both Chrome and IE) are always “waiting for downloads.comodo.com” and the download never starts.

rhgtyink · March 22, 2013, 8:58pm

Any chance you can create a capture of such an attempt with Wireshark so we can see what’s going on?

here is a guide on how to use it.

Radaghast · March 22, 2013, 9:41pm

I have problems with IPv6 and the comodo sites - the only sites I have problems with - so much so that I force IPv4, for comodo.com, in firefox. However, I have found that adjusting your IPv6 MTU can help. You can use somethig like mtupath to ascertain the correct size.

salapis · March 22, 2013, 11:02pm

I can only provide Microsoft Network Monitor capture.
You can find it here. (I’ll delete the link in 2-3 days for obvious reasons)

I used Comodo update, instead of using a browser to download from downloads.comodo.com
The problem is similar. (Comodo finds that there is an update but it downloads 0 bytes)

In short I am getting a “Moved temporarily” response from downloads.comodo.com (using ipv6)

Anyway, forcing Comodo to use http://178.255.82.1 for updates would solve the update problem for me I suppose.

*Oh by the way, if you choose to enable “Filter ipv6” on Comodo firewall you get fake tracert results for every ipv6 address.I suppose this is a known bug.

Radaghast · March 23, 2013, 12:57am

This is also seen using IPv4 but the correct URI is offered in the 302 message.

Anyway, forcing Comodo to use http://178.255.82.1 for updates would solve the update problem for me I suppose.
*Oh by the way, if you choose to enable “Filter ipv6” on Comodo firewall you get fake tracert results for every ipv6 address.I suppose this is a known bug.

Would yo mind expanding on that please, I’m not seeing any issues with tracert -6

salapis · March 23, 2013, 2:26am

Well I found out that the tracert problems appear only when Comodo Firewall is disabled and “Filter ipv6 traffic option” in comodo firewall is enabled.

Case 1. Comodo Firewall Enabled, Filter ipv6 disabled

Case 2. Comodo firewall Enabled, Filter ipv6 enabled.

Case 3. Comodo Firewall Disabled, Filter ipv6 enabled.

This is not related to downloads.comodo.com.It happens on every ipv6 tracert.
Ipv6 sites work ok in all cases.It’s just a minor tracert bug or sth.

[attachment deleted by admin]

Radaghast · March 23, 2013, 3:00am

Unfortunately, I’m not seeing any differences with or without the firewall/IPv6 filtering. Strictly speaking, if the firewall is disabled, the filtering option shouldn’t make any difference. What happens if you disable the Comodo firewall driver in device manager?

rhgtyink · March 23, 2013, 7:09pm

IPv6 PMTU is now the responsibility of the source/destination hosts, this trace is missing ICMPv6 traffic so I can’t see if there where Packet To Big packets send by routers in between.
It seems like there is to much packet loss on the communication, to many retransmits/segments lost on critical packets.

Can you please run a full capture with no filters (please close as many applications that can cause ‘noise’ on the capture)?
Did you verify your Routers firewall settings regarding IPv6, does it filter to much, e.g. ICMP error traffic etc?

salapis · March 23, 2013, 10:12pm

Thanks for your answer.
Here is a full capture
I took the capture with Router’s firewall and Comodo firewall disabled.

I tried using another Pc. Same problem.Cannot download from downloads.comodo.com.I also discovered that I cannot browse to help.comodo.com, which is ipv6 enabled, too.
I can browse to any other ipv6 enabled site.I tried many of them from http://look4ipv6.appspot.com/tools/random
and they worked.

MTUpath discovers best MTU as 1442.

rhgtyink · March 23, 2013, 10:52pm

Can you check to see if MTUpath get’s other value’s on other sites that do work?

salapis · March 23, 2013, 11:05pm

Well 1442 is the max from my side.(Actually it’s my router’s default configuration.)
Most sites report 1442 as a result.
http://www.ipv6tf.org/ has MAX MTU of 1280(I suppose that’s their MTU configuration or a configuration of a hop between me and the site) and work ok.

Radaghast · March 24, 2013, 12:19am

I also can’t access help.comodo over IPv6 (attached capture) looks like it’s stuck in a TLS loop…

By the way, from what I can see, there’s no PTR records for:

help.comodo - 2a02:1788:4fd:cd::c742:cde6

; <<>> DiG 9.9.2-P1 <<>> -x 2a02:1788:4fd:cd::c742:cde6
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 50870
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;6.e.d.c.2.4.7.c.0.0.0.0.0.0.0.0.d.c.0.0.d.f.4.0.8.8.7.1.2.0.a.2.ip6.arpa. IN PTR

;; AUTHORITY SECTION:
8.8.7.1.2.0.a.2.ip6.arpa. 1200  IN      SOA     ns0.comododns.com. hostmaster.comodogroup.com. 2013021201 1800 1200 1814400 1200

;; Query time: 209 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Sun Mar 24 11:29:19 2013
;; MSG SIZE  rcvd: 177

E:\Software\AppSW\Network\Network Diags>mtupath downloads.comodo.com

MTU path scan to downloads.comodo.com (2a02:1788:4fd::b2ff:5201), ttl=64, limit=48
# 16 processing - best MSS 1332 (estimated MTU 1380) [uUUUUuUuUUuuUUuu]
# 08 nearest minimum MTU on 2001:470:1f14:1a37::1 (2 hops away)

        #1 MSS IN RANGE     1 <==  1331 ==>  1332
        #2 MSS EXCEEDED  1333 <== 15051 ==> 16384

E:\Software\AppSW\Network\Network Diags>mtupath ipv6.google.com

MTU path scan to ipv6.google.com (2a00:1450:4010:c03::67), ttl=64, limit=48
# 16 processing - best MSS 1332 (estimated MTU 1380) [uUUUUuUuUUuuUUuu]
# 08 nearest minimum MTU on 2001:470:1f14:1a37::1 (2 hops away)

        #1 MSS IN RANGE     1 <==  1331 ==>  1332
        #2 MSS EXCEEDED  1333 <== 15051 ==> 16384

E:\Software\AppSW\Network\Network Diags>mtupath ipv6tf.org
[ERROR] Multiprotocol name lookup for ipv6tf.org failed to find peer

E:\Software\AppSW\Network\Network Diags>mtupath www.ipv6tf.org

MTU path scan to www.ipv6tf.org (2a01:48:1:0:2e0:81ff:fe05:4658), ttl=64, limit=48
# 16 processing - best MSS 1232 (estimated MTU 1280) [uUUUUuUUuuUUuuuu]


        #1 MSS IN RANGE     1 <==  1231 ==>  1232
        #2 MSS EXCEEDED  1233 <== 15151 ==> 16384

Linux tracepath6 differs somewhat, so there’s a slight discrepancy somewhere

gcb[at]Brutus ~ $ tracepath6 downloads.comodo.com
 1?: [LOCALHOST]                        0.037ms pmtu 1480
 1:  JellyTot                                              1.286ms 
 1:  JellyTot                                              1.304ms 
 2:  JellyTot                                              1.333ms pmtu 1380
 2:  2001:470:1f14:1a37::1                               178.701ms 
 3:  gige-g2-13.core1.ams1.he.net                        177.163ms 
 4:  10gigabitethernet5-3.core1.fra1.he.net              191.116ms 
 5:  te-3-4.ar2.fra4.gblx.net                            185.450ms 
 6:  2001:450:2002:445::2                                218.488ms 
 7:  downloads.comodo.com                                193.037ms reached

gcb[at]Brutus ~ $ tracepath6 www.ipv6tf.org
 1?: [LOCALHOST]                        0.007ms pmtu 1480
 1:  JellyTot                                              1.167ms 
 1:  JellyTot                                              6.769ms 
 2:  JellyTot                                              1.316ms pmtu 1380
 2:  2001:470:1f14:1a37::1                               186.328ms 
 3:  gige-g2-13.core1.ams1.he.net                        183.120ms 
 4:  10gigabitethernet1-4.core1.lon1.he.net              196.566ms 
 5:  gige-g0-1.tserv17.lon1.ipv6.he.net                  189.184ms 
 6:  consulintelhe-1-pt.tunnel.tserv17.lon1.ipv6.he.net  220.811ms asymm  7 
 7:  2a01:48:100:2::174                                  219.598ms asymm  8 
 8:  2a01:48:100:2::174                                  218.749ms pmtu 1280

The endpoint for ipv6tf is 2a01:48:1:0:2e0:81ff:fe05:4658 but it’s blocked by their ISP.

[attachment deleted by admin]

rhgtyink · March 27, 2013, 10:31pm

I have the same issue with http://help.comodo.com. (IPv6 tunnel via tunnelbroker).
It pings fine, but it won’t load in the browser, I see the 3-way handshake perfectly fine, but after the GET / request I receive an ACK to the request and then it goes dark.

Did you try http also Radaghast, and have you noticed the ‘packet-to-big’ messages in your capture?
Unless that’s your tunnel endpoint probably that would behave in this way?

rhgtyink · March 27, 2013, 11:14pm

Results seem to vary with this tool…


>mtupath -6 help.comodo.com

MTU path scan to help.comodo.com (2a02:1788:4fd:cd::c742:cde6), ttl=64, limit=48
# 16 processing - best MSS 1432 (estimated MTU 1480) [uUUUUuUuuUUuUuuu]
# 08 nearest minimum MTU on 2001:470:1f14:d83::1 (2 hops away)

        #1 MSS IN RANGE     1 <==  1431 ==>  1432
        #2 MSS EXCEEDED  1433 <== 14951 ==> 16384


MTU path scan to help.comodo.com (2a02:1788:4fd:cd::c742:cde6), ttl=64, limit=48
# 16 processing - best MSS 1441 (estimated MTU 1489) [uUUUUuUuuUuUUUUU]


        #1 MSS IN RANGE     1 <==  1440 ==>  1441
        #2 MSS EXCEEDED  1442 <== 14942 ==> 16384