• Welcome to Hurricane Electric's IPv6 Tunnel Broker Forums.

News:

Welcome to Hurricane Electric's Tunnelbroker.net forums!

Main Menu

Recent posts

#1
Questions & Answers / Re: Dealing CGNAT to using Tun...
Last post by sixdev - March 26, 2023, 02:12:26 AM
Quote from: tjeske on January 23, 2023, 01:11:30 AMYou could use Route48 instead of HE. They do offer IPv6 tunnels over Wireguard.

I found myself in the same situation and I followed your advice up until recently (thanks by the way!)

Unfortunately Route48 shut down due to abuse, any alternatives out there?
#2
Questions & Answers / Re: IPv6 tunnel and GeoIP
Last post by kamil445 - March 24, 2023, 01:36:25 AM
Here you can check geolocation in most popular geolocation providers:

https://dnschecker.org/ip-location.php
https://www.iplocation.net/ip-lookup

also you can check if hurricane electric set correct geolocation to your routed /64 here

https://dnschecker.org/ipv6-whois-lookup.php

If you want correct geolocation in some geolocation providers like db-ip, ipapi, iplocation etc you can send them email and ask them to correct geolocation, here you have most popular geolocation providers with contact information (i found them on the web):

Google => https://support.google.com/websearch/workflow/9308722?hl=en
DB-IP.com => https://db-ip.com/__YOUR_IP__
MaxMind => https://support.maxmind.com/geoip-data-correction-request/
ipapi.co => https://ipapi.co/contact/
ip2location.com => support@ip2location.com
ipinfo.io => https://ipinfo.io/contact
ipgeolocation.io => https://ipgeolocation.io/contact.html
ipregistry.co => support@ipregistry.co
ipdata.co => https://ipdata.co/corrections.html
iphub.info => https://iphub.info/contact?ip=__YOUR_IP__&block=2
ipip.net => support@ipip.net
neustar => https://www.home.neustar/resources/tools/submit-to-global-ip-database
whoisxmlapi => service.desk@whoisxmlapi.com

For example, Facebook use geolocation based on ASN, ASN location for tunnelbroker from hurricanes is US, Freemont, so Facebook always will think, you are from US. BUT if you have Facebook app installed and enabled geolocation in you phone, facebook sometimes update IP location based on phone location.
For exmaple sometimes Facebook think i'm from US, but sometimes think i'm from Poland, sometimes this  change everyday :)

This method also works with Google.

Looks like hurricane 29.12.2022 changed rwhois information, and removed whois per tunnel network, for example before 29.12.2022 rwhois output show per network "network:ID;I:NET-2001:470:71:447::/64" with location inserted in tunnelbroker settings, but after 29.12.2022 rwhois output is only network:ID;I:NET-2001:470:71::/48" with location set to capitol city of Poland (Warsaw).
#3
General Questions & Suggestions / Re: DNAME RR Support.
Last post by snarked - March 23, 2023, 11:23:59 AM
Or at least fixed for the DNS hosting service.  The open resolver at "ordns.he.net" isn't handling DNAME RRs correctly (yet).
#4
General Questions & Suggestions / Re: DNAME RR Support.
Last post by snarked - March 20, 2023, 10:32:13 PM
After a service ticket, it looks as if this issue has been fixed.
#5
General Questions & Suggestions / Re: DNAME RR Support.
Last post by snarked - March 19, 2023, 10:50:15 AM
DNAME DNS queries still not working.

Quote1.0-63.63.63.44.in-addr.arpa ptr @ns1.he.net

Results:
->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 55895
flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1
WARNING: recursion requested but not available

AUTHORITY SECTION
63.63.44.in-addr.arpa.  3h IN SOA k6bde.ampr.org. hostmaster.k6bde.ampr.org. (
                                2023031700 ; serial
                                43200      ; refresh (12 hours)
                                7200      ; retry (2 hours)
                                3024000    ; expire (5 weeks)
                                10800      ; minimum (3 hours)
                                )


However, correct results should be:
Quote->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55769
flags: qr aa rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1

ANSWER SECTION
0-63.63.63.44.in-addr.arpa. 1w IN DNAME 63.63.44.in-addr.arpa.
1.0-63.63.63.44.in-addr.arpa. 1w IN CNAME 1.63.63.44.in-addr.arpa.
1.63.63.44.in-addr.arpa. 1w IN PTR k6bde.ampr.org.

Not working is one thing.  Giving an incorrect result is quite another.  It's been 3 years and this hasn't been fixed (as above).



#6
Questions & Answers / Re: Packet loss e0-30.core2.lo...
Last post by tho - March 11, 2023, 05:24:28 AM
I'm seeing that too on ams1 tunnel.

5. par-th2-sbb1-nc5.fr.eu            0.0%   120    4.3   4.4   4.2   4.7   0.1
6. 10.200.2.71                       0.0%   120    4.5  97.5   4.2 606.6 133.4
7. he.par.franceix.net              97.5%   120    4.5  32.5   4.5  87.8  47.9
8. amsix-200gbps.core1.ams1.he.net  82.4%   120   76.8  40.0   9.6 175.0  48.4
9. tserv1.ams1.he.net               24.2%   120    9.8  11.2   9.4  88.2   8.6

The tunnel is pretty much unusable. It started maybe one month ago and I never saw that for 5 years. This is strange that several tunnels are affected since about the same time?

I opened a ticket one week ago but not getting much replies or insight.
#7
Questions & Answers / Re: Packet loss e0-30.core2.lo...
Last post by snewbury - March 10, 2023, 06:41:26 AM
tserv1.lon1.he.net has started dropping about 5-15% ipv6 packets for the last few weeks.  I thought it might be Virgin Media too, but I set up a VM at Linode and pinged the other side of the tunnel with ipv6, which also resulted in packet loss.

PING 2001:470:0:67::2(2001:470:0:67::2) 56 data bytes
64 bytes from 2001:470:0:67::2: icmp_seq=1 ttl=58 time=0.781 ms
64 bytes from 2001:470:0:67::2: icmp_seq=2 ttl=58 time=35.4 ms
64 bytes from 2001:470:0:67::2: icmp_seq=3 ttl=58 time=0.879 ms
64 bytes from 2001:470:0:67::2: icmp_seq=4 ttl=58 time=0.835 ms
64 bytes from 2001:470:0:67::2: icmp_seq=5 ttl=58 time=84.7 ms
64 bytes from 2001:470:0:67::2: icmp_seq=6 ttl=58 time=0.833 ms
64 bytes from 2001:470:0:67::2: icmp_seq=7 ttl=58 time=0.857 ms
64 bytes from 2001:470:0:67::2: icmp_seq=8 ttl=58 time=0.859 ms
64 bytes from 2001:470:0:67::2: icmp_seq=9 ttl=58 time=0.935 ms
64 bytes from 2001:470:0:67::2: icmp_seq=10 ttl=58 time=0.890 ms
64 bytes from 2001:470:0:67::2: icmp_seq=11 ttl=58 time=0.846 ms
64 bytes from 2001:470:0:67::2: icmp_seq=12 ttl=58 time=0.886 ms
64 bytes from 2001:470:0:67::2: icmp_seq=13 ttl=58 time=0.889 ms
64 bytes from 2001:470:0:67::2: icmp_seq=14 ttl=58 time=0.878 ms
64 bytes from 2001:470:0:67::2: icmp_seq=15 ttl=58 time=0.856 ms
64 bytes from 2001:470:0:67::2: icmp_seq=17 ttl=58 time=0.882 ms
64 bytes from 2001:470:0:67::2: icmp_seq=18 ttl=58 time=0.844 ms
64 bytes from 2001:470:0:67::2: icmp_seq=19 ttl=58 time=0.893 ms
64 bytes from 2001:470:0:67::2: icmp_seq=20 ttl=58 time=0.935 ms
^C
--- 2001:470:0:67::2 ping statistics ---
20 packets transmitted, 19 received, 5% packet loss, time 19054ms
rtt min/avg/max/mdev = 0.781/7.094/84.660/19.834 ms

Also some big spikes there.  Some sort of load issue on tserv1.lon1.he.net?
#8
Questions & Answers / Re: Very high response times f...
Last post by gregecslo - March 04, 2023, 01:15:38 AM
And graph for last 2 days that shows specific times of day when it`s the worst or the best...
You cannot view this attachment.
#9
Questions & Answers / Very high response times from ...
Last post by gregecslo - March 04, 2023, 01:14:48 AM
Hi!

Since last few weeks, HU tunnel has very high latency.

Last 30 days:
You cannot view this attachment.

It seems that all started in the middle of February 2023...

Can you please check it out?
Thanks!
 
#10
The standard iperf3 client has a -R option to measure download from the server instead of the regular upload.

Can an option be added to activate that?

Also, how does one get more than one sample, again like the standard CLI client does?