Hurricane Electric's IPv6 Tunnel Broker Forums

Advanced search  

News:

Welcome to Hurricane Electric's Tunnelbroker.net forums!

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - divad27182

Pages: [1] 2 3
1
IPv6 Basics & Questions & General Chatter / Re: ipv6 via gray ip
« on: September 03, 2017, 05:48:38 PM »
hi. how to make ipv6 if my provider give me inet with 10.152.xxx.xxx ip address (aka grey ip address)? so only dedicated ip4 address can help avoid this trouble? thanks
  • It is called a "Private Use" address, not "grey".
  • If they use a one-to-one NAT, you might be able to do it with a he.net tunnel.  Try http://checkip.dns.he.net/ repeatedly (including with hours delay).  Try other address reporting services.  If it never changes, you might have one-to-one NAT.  Or maybe the provider only has one public address.
  • Your best bet may be to see if your provider provides IPV6.  Try the autoconfiguration methods, and DHCPv6.  And ask them.  And if they don't provide IPv6, ask them to.

2
wget -O -  https://get.acme.sh | sh

Of course, if you have ANY security concerns, you will not do this at all!

3
Questions & Answers / Re: Tunnel wont start. General Trouble Shooting?
« on: August 18, 2017, 06:10:30 PM »
Can you paste the output of ifconfig and the commands you used to start the tunnel?

Is your ISP blocking proto41? Is your router?
# ifconfig
eno1      Link encap:Ethernet  HWaddr f8:b1:56:cd:d5:1a 
          inet addr:10.0.102.107  Bcast:10.0.103.255  Mask:255.255.252.0
          inet6 addr: 2001:470:d:bb3::1/64 Scope:Global
          inet6 addr: fe80::194e:35aa:8817:f95a/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:39178902 errors:0 dropped:1 overruns:0 frame:0
          TX packets:31747934 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:7471397493 (7.4 GB)  TX bytes:12864750080 (12.8 GB)
          Interrupt:20 Memory:f5100000-f5120000

I suspect you have two problems.

1) You are behind a NAT firewall, so data might not reach you.  If you haven't already, try configuring your gateway as the DMZ.  Also, try starting with traffic from inside (see problem 2), and hoping that the firewall opens a session for you.

2) You are behind a NAT firewall, so the provided configuration is not quite right.  Packets might not even be being sent.  Try removing the "local" definition in "/etc/network/interfaces".  (I think "local" is about bypassing the routing tables for the IPV4 traffic.)  Also, run dmesg to check for errors from the kernel.


Isn't "ifup he-ipv6" suppose to start the tunnel?
Is your ISP blocking proto41? is there a way to test for this and how do I turn this off on a cisco asa?

"ifup he-ipv6" does start the tunnel, but doesn't tell any non-debian user anything.  Try running "ifup -v he-ipv6", which shows the actual commands used, along with other activities if-up performs.

I would also recommend trying packet capture (wireshark) on the external interface of your host.  See if packets are sent or received.  See if there are error packets or rejects.   etc...

I can't help you with the protocol blocking question.

--David

4
Questions & Answers / Re: Why IPv6 AXFR transfer is not supported?
« on: August 01, 2017, 05:26:30 PM »
I wrote in, talked a bit, and they found out the problem I was having.  It turns out that
  • You should send the NOTIFYs to ns1.he.net.  The other I don't think matter, or work at all.  slave.dns.he.net does not work at all.
  • You MUST send the NOTIFYs with a source address equal to one of the registered master addresses.  This I had to be told by he.net staff, and is apparently what causes a "Refused" error.

Yes, IPv6 notifications do work, at least if you get your source address correct.  IPv6 transfers do work.

--David

5
Questions & Answers / Re: Why IPv6 AXFR transfer is not supported?
« on: August 01, 2017, 11:19:52 AM »
At this point, I would suggest packet sniffing the network connection to determine if the request is being lost or ignored, or if it has an error.  If the former, I would suspect you have network problems.  If the later, I would suspect DNS configuration problems.  Since the error talks of retries, I suspect the network problems.

OK, I decided to test before posting, and now I am really confused.  I can't seem to get an update to go through, though I have seen the transfer to slave happen.
I can report that ns1.he.net returns error "refused" (5), ns2 through ns5 return error "not implemented" (4), and slave.dns.he.net seems to not respond at all.

At this point, I suspect a problem inside he.net's DNS, and plan to write in.

6
One possible solution to the deadlock:
  • setup your own temporary DNS server for the domain in question.  Make sure it lists the he.net DNS servers. (It will only need to be there for a few minutes.)
  • create a slave zone pointing to your DNS server.
  • convert the slave zone to a master.
  • get rid if the temporary DNS server.
At this point, the DNS zone exists, even without being delegated to.   :-)

I think there was a note about writing to one of the support addresses (dnsadmin@he.net or ipv6@he.net) as an alternative.

--David

7
I did some debugging with wireshark:
What is wrong here?

Well, several packets from the remote server were lost.  The remote webserver tried to end the connection normally after 5 seconds of inactivity.  A TCP retransmission was initiated, and some (but not all) data was successfully resent.  Then (assuming TCP's rules haven't changed since IPv4) either the remote machine was rebooted, or it's TCP stack is broken or at least poorly configured, as those are the only way you get a RST in 120 seconds.  [I wouldn't bother with this issue.] 

Both ends seem to be sending a payload length (inside all the headers) of 1208, with an overall packet length of 1280, and you did receive such a packet.

Well, TCP did always require only a non-zero probability of successful delivery from it's lower level, but it never really behaves well unless it gets a very high probability of successful delivery.  Maybe you have a noisy connection (which seems unlikely with current technology).  Most of the dropped packets appear to be incoming.  If so, you might be able to tune your TCP stack to be more aggressive at sending and requesting retransmissions.  Unfortunately, that is just a workaround.

As for the underling problem?  Your guess is as good as mine, but I would suspect it isn't MTU, as the payload 1208 overall 1280 packets went both ways successfully (#4, #10).

8
General Questions & Suggestions / Re: dyn.dns.he.net certificate
« on: June 23, 2017, 08:44:17 PM »
-1 on this.  If you want to check the certificate, install CACert's root certificate.

(Personally, I don't understand how "Let's Encrypt" got into the lists... but then that could apply to most of the listed CAs.)

By the way... it looks like Let's Encrypt does not use a Let's Encrypt certificate.  Should anyone?

9
Questions & Answers / Re: MTU Issue?
« on: June 22, 2017, 07:25:32 PM »
1424 is the maximum size of a packet that can go through.
MTU of the link is 1472.

Close, but not quite.  1424 is the maximum payload length that, with the addition of 48 bytes of header, can fit in an MTU of 1472.  1424+48=1472  Specifying 1424 actually gets you a packet length of 1472.

What's wrong with the 1472 MTU uplink. How can I debug it?

Myself, I would probably start by "tcpdump"ing to a file on both end, and then analyzing the files with wireshark.  Look for what differs.  Look of ICMP messages.

Code: [Select]
# tcpdump -i eth0 -s 9999 -w first_end.tcpdump tcp port 22 and host otherhostname
--David



10
Questions & Answers / Re: MTU Issue?
« on: June 22, 2017, 08:04:15 AM »
Truncation?  Well, I think it is because google's box is truncating the reply to 64 bytes of data.
Try pinging ipv6.he.net instead.

Truncating the reply is a reasonable sanity measure.  It allows you do send a 64 byte reply to a 64000 byte request, thus no clogging up your own outgoing packets.  It also makes it more likely for the reply to get through an asymetric MTU problem.  On the other hand, one gets problems like what you are seeing.

My issue with all this is that wireshark doesn't manage to pair up the truncated reply with the request.  Somebody never saw a truncated reply.

edit: That 48 byte discrepancy is the IPv6 header (40 bytes) and the ICMPv6 header (8 bytes).  The byte count specified is the payload length.

11
so i should just simply push the update button and not alter the ns1 through ns5.he.net in any way there?
unafunk.com in the name area and just ns1.he.net in the nameserver area?

OK. First off, "unafunk.com" is not a registered domain.  If you are actually trying to use that, you should register and pay the fees first.  I currently use godaddy.com, but there are hundreds of registrars available.

If you were using unafunk as an example, you should write "example.com".

Second, I'm afraid you've lost me.  Sorry.

--David

12
newbie at this, but how do i delegate my domain name with nameserver?

Delegation is part of domain name registration.  Having registered "unafunk.com" at some registrar, you go back to the regiistrars website and tell them that you want to specify the name servers.  (Many registrars expect to host your DNS too, so this can be tough, or out of the way.)  Then you specify ns1.he.net through ns5.he.net as your nameservers.  Then you may have to wait up to two days for things to propagate (or maybe not).  Then you should be able to get HE.NET's dns support working for you.

--David


13
General Questions & Suggestions / Re: DNS types
« on: June 20, 2017, 07:43:49 AM »
But with numeric input, at least you get an output.....

The output could only be "Unknown record of type n with undecodable content".  The content bytes could be output, but domain names would often be undecipherable due to trailing domain compression.  OK, there might be some value to showing the unknown records. 

Note that you really are better off with an ANY query to fetch this.  (Frankly, if you are trying to browse DNS, I would always recommend "ANY", except if you are trying to deal with a partially expired cache.)

14
Questions & Answers / Re: Why IPv6 AXFR transfer is not supported?
« on: June 18, 2017, 10:54:35 AM »
You might try seeing if sending your notification to slave.dns.he.net works any better.  That machine does all the slave transfers anyway.

Failing that, you might write to dnsadmin@he.net.

--David

15
Questions & Answers / Re: Why IPv6 AXFR transfer is not supported?
« on: June 18, 2017, 10:42:44 AM »
I think it is supported.  My DNS slave zones on dns.he.net have an IPv6 address listed as the master, and have successfully downloaded.

The bit that you are showing, that might still not be supported, is notification to the slave that the master has changed. 

--David

Pages: [1] 2 3