Stuck on 'Administrator' (inbound email) test [SOLVED]

[rog2054]

Hello everyone!

I'm a network guy from the UK. Over here ipv6 is very slow to take off (certainly in companies i've worked at, and 3rd parties i deal with day-to-day), so i've decided to be proactive  ;D and learn a bit more about ipv6 than just 'its that funny looking ip address that's hard to remember!' (which is about all i needed to know when i did my CCNP, several years ago mind...)

Anyway, i'm on the part of the HE Certification program where we need to get some inbound email working.

Here's my setup so far:
Debian server setup as the tunnel endpoint, also hosting apache. I can ping both ends of the tunnel, and a AAAA record pointing at my end successfully loads the test web page (or else i'd still be on that part of the test!)

Since then i've installed radvd, configured it for eth0, and my Windows7 laptop gets two nice 2001:.... IPs in my routed /64 block, as per the tunnelbroker.net summary page. I can ping6 the non-temporary IP from the internet (haven't tried the temporary one), and can ping internet ip6 addresses from the PC (eg 'ping -6 ipv6.google.com' returns a nice ipv6 address and replies).
(the Windows7 PC also has a IPv4 address, from my dsl router)

On the Windows7 PC i have setup hmail.
On my domain name (external DNS hosted by the hosting company) i have created a DNS AAAA record to point at the Windows7 machines 2001 IP (the real one, not the 'temporary ipv6' one).
I have then created a MX record to use this AAAA fqdn, with a MX priority of 10.

Now, when i request HE to send the test email, nothing seems to happen.
On the HE website, the swirling progress thing just spins and spins forever.
I've watched my 'he-ipv6' interface on the Debian box with tcpdump, and there is no SMTP traffic coming in.
Needless to say, nothing is reaching the Windows7 PC either.

Any suggestions as to what i should check/change?  ???
I'm a bit concerned by the HE 'step3' icon just spinning forever - presumably this should change to done at some point (of even FAILED or TIMEOUT etc would be a useful hint).


Kind Regards

[yurko]

The problem looks very similar to what I had during last 2 days, I had exactly the same "the swirling progress thing just spins and spins forever".
You can read about it in this forum topic http://www.tunnelbroker.net/forums/index.php?topic=2902.0

I emailed to ipv6@he.net and after couple of emails back and forward we figured out that the problem was from HE side, they blocked my tunnel side port 25 by mistake or due to a bug.

[kasperd]

I have then created a MX record to use this AAAA fqdn, with a MX priority of 10.

We can't say much about the reason without knowing the domain name.

we figured out that the problem was from HE side

That was on a different tunnel server though, but maybe they made the same mistake on more than one tunnel server.

[rog2054]

Thanks for the replies.

The domain is thinkroger.co.uk
The mail server (Windows7 machine with hmail) has the ip6 address as per AAAA mail1.thinkroger.co.uk

[kasperd]

traceroute to your IP reveals that sometimes connectivity to the server is working, sometimes it is not. Here are two traceroute outputs from the same source

Code Select Expand

traceroute to mail1.thinkroger.co.uk (2001:470:1f09:b67:6942:527c:352b:88d), 30 hops max, 80 byte packets
1  2001:470:28:940:5d75:c1f4:e0a0:f8ec  0.529 ms  1.996 ms  2.608 ms
2  2001:470:27:940::1  40.814 ms  45.662 ms  46.826 ms
3  2001:470:0:11e::1  48.299 ms  29.577 ms  34.629 ms
4  2001:470:0:22f::1  61.859 ms  67.110 ms  67.126 ms
5  2001:470:0:3f::1  76.743 ms  76.813 ms  77.338 ms
6  2001:470:0:67::2  85.529 ms  86.187 ms  81.884 ms
7  2001:470:1f08:b67::2  107.349 ms  85.546 ms  96.583 ms
8  *  *  2001:470:1f09:b67:6942:527c:352b:88d  114.019 ms

Code Select Expand

traceroute to mail1.thinkroger.co.uk (2001:470:1f09:b67:6942:527c:352b:88d), 30 hops max, 80 byte packets
1  2001:470:28:940:5d75:c1f4:e0a0:f8ec  0.418 ms  0.934 ms  2.487 ms
2  2001:470:27:940::1  79.196 ms  147.027 ms  155.081 ms
3  2001:470:0:11e::1  160.049 ms  94.694 ms  95.288 ms
4  2001:470:0:22f::1  65.932 ms  66.576 ms  57.586 ms
5  2001:470:0:3f::1  68.438 ms  64.225 ms  77.187 ms
6  2001:470:0:67::2  60.056 ms  84.286 ms  89.019 ms
7  *  *  *
8  *  *  *
9  *  *  *
10  *  *  *When it stops working I get replies from the tunnel server, but not from your tunnel endpoint. This sort of behaviour is typical, if there is a NAT between your tunnel endpoint and the tunnel server. IPv6 packets from the inside going out will work, but IPv6 packets from the outside will only come through, if there has recently been an outgoing packet.

I have started a script, which will try to estimate the timeout of the NAT, next time it can get a connection through.

If the issue turns out to be caused by a NAT timeout, it can be worked around by periodically pinging the tunnel server (using IPv6). I recommend putting the interval just below half the timeout, such that it takes more than a single lost packet to lose connectivity. For example, if the NAT timeout turns out to be 60 seconds, I would suggest a ping every 29 seconds.

[kasperd]

I have started a script, which will try to estimate the timeout of the NAT, next time it can get a connection through.

Tested twice. Found your timeout to be 60 seconds (±10).

[rog2054]

Hi Kasperd

Thank you for the time you have spent looking into this so far.
I had come to the same conclusion having recently spotted the intermittent inbound connectivity myself also, that my DSL router was timing out the NAT entry for the protocol-41 tunnel connection.

As a temporary workaround i have setup a cronjob to ping6 an internet address every minute (i did try 5 minutes initially, but that was too infrequent for the router timeout it seems).

Since my earlier post, and partly why was back on the forum, i have made a few changes:
I suspected the fact my Windows7 PC is wireless may be causing further complexity (my wireless AP is also my DSL router, which is 5+ years old), so to remove this from the equation i have setup a new wired machine running debian with exim. I have updated the AAAA for the MX entry accordingly.
This DNS update was done just over an hour ago, so should have propagated sufficiently by now (everywhere online i've done a nslookup for mail1.thinkroger.co.uk is now showing the new IP6 address)

The new ip6 address for this mail server is 2001:470:1f09:b67::3
This address is responding to pings now (using the centralops online ping utility)

I have tested from the debian endpoint machine that i can send email "telnet 2001:470:1f09:b67::3 25", etc, and can confirm this reaches the mailbox.

HE have also confirmed their firewall is allowing port-25 inbound to my tunnel.

So, progress made, but not quite there yet. I'm going to take a breather but will return in an hour and see if time away helps me think of anything else to check.


thanks again.

[rog2054]

Success!

One last change i made on the mailserver is to update the hostname to match the DNS, so that exim announces itself as mail1.thinkroger.co.uk in its welcome string when you connect to it on port 25.

Following this i checked the mailbox, and there was the email from HE  :D


Thanks for the help, and whilst i'm not sure this last change is the one that fixed it or if it just needed more time for my DNS update to leave a cache somewhere, either way hopefully this thread will be of use to others in future who have similar difficulty.


Onwards!!

[kasperd]

As a temporary workaround i have setup a cronjob to ping6 an internet address every minute

For your case I think an interval of once every 29 seconds would be more appropriate (assuming the timeout is 60 seconds). You don't get that granularity from cron, but the ping command can specify an interval. You could use something like ping6 -ni29 2001:470:1f08:b67::1

If you prefer to run it from cron, you could have cron start a ping command once per hour, which then pings a number of times at a reasonable interval. For example have cron run this command once per hour ping6 -n -i 25 -c 144 2001:470:1f08:b67::1

(i did try 5 minutes initially, but that was too infrequent for the router timeout it seems).

That explains why I didn't have to wait a long time before my script got the first ping through. Your ping established the connection once every 5 minutes, and it then stayed up for 1 minute (longer if anything else happened on the connection). So it was up 20% of the time and down 80% of the time.

My script would have to wait at most 4 minutes before it could start testing the timeout, and then the script would keep the connection alive with pings until it increased the interval past 60 seconds.

I suspected the fact my Windows7 PC is wireless may be causing further complexity (my wireless AP is also my DSL router, which is 5+ years old), so to remove this from the equation i have setup a new wired machine running debian with exim.

That is what debugging is all about. Rule out all each of the things that could possibly go wrong, until you are left with only one possibility.