Print

[smiffy]

I'm using the regular Debian Lenny /etc/network/interfaces configuration to set up my tunnel.  Works fine.  Only problem is that the tunnel appear to 'go away' after about 5-10 minutes, won't answer pings (or anything else.)

The tunnel may be woken up again by pinging OUT.  In fact, as a work-around, I've set up this little cron job to do a keep-alive:

0,5,10,15,20,25,30,35,40,45,50,55 * * * * ping6 -c2 ipv6.he.net > /dev/null 2>&1

...which works, but falls under the heading of a 'dirty hack' as far as I'm concerned.

Can anyone throw any light on what might be the problem here and how I might resolve it?

[jimb]

I'm using the regular Debian Lenny /etc/network/interfaces configuration to set up my tunnel.  Works fine.  Only problem is that the tunnel appear to 'go away' after about 5-10 minutes, won't answer pings (or anything else.)

The tunnel may be woken up again by pinging OUT.  In fact, as a work-around, I've set up this little cron job to do a keep-alive:

0,5,10,15,20,25,30,35,40,45,50,55 * * * * ping6 -c2 ipv6.he.net > /dev/null 2>&1

...which works, but falls under the heading of a 'dirty hack' as far as I'm concerned.

Can anyone throw any light on what might be the problem here and how I might resolve it?

If you're behind a NAT or firewall, it's probably the connection table entry timing out.  Put a static NAT and/or security policy in place which allows incoming 6in4 protocol.

BTW, you can shorten that crontab line to "*/5 * * * * ...."  

[smiffy]

@jimb - many thanks for your reply!

Hey, I never knew that crontab shortcut. How long have I been writing it longhand? About 20 years... *facepalm*

This is an Internet-facing box with an iptables firewall (no NAT.)  I Googled for iptables and 6in4 and - surprise surprise - was directed to another of your posts: http://www.tunnelbroker.net/forums/index.php?topic=816.0

Just trying to figure out how that fits into my (non-NAT) scheme of things.  Given $ipv4_tunnel_end_point, $my_ipv4_address, what would the rule look like to keep the channel open?

For the record, I ran an IPv6 portscan on my box, when operational, and the services that normally show for IPv4 also show up for IPv6 (which is what I want - I just want all current services running dual-stack.)

[jimb]

@jimb - many thanks for your reply!

Hey, I never knew that crontab shortcut. How long have I been writing it longhand? About 20 years... *facepalm*

Well it's relatively new ... I'm not really sure when those "shortcuts" came into play, but "back in the day" you had to do it the way you did it.  Might have been with the advent of Vixie cron, whenever that was.

This is an Internet-facing box with an iptables firewall (no NAT.)  I Googled for iptables and 6in4 and - surprise surprise - was directed to another of your posts: http://www.tunnelbroker.net/forums/index.php?topic=816.0

Just trying to figure out how that fits into my (non-NAT) scheme of things.  Given $ipv4_tunnel_end_point, $my_ipv4_address, what would the rule look like to keep the channel open?

For the record, I ran an IPv6 portscan on my box, when operational, and the services that normally show for IPv4 also show up for IPv6 (which is what I want - I just want all current services running dual-stack.)

No NAT makes it simple.  You just need to put a rule in which allows 6in4 traffic, like:
iptables -A INPUT --proto 41 --source <HE tunnel server> --jump ACCEPT

That would allow IPv4 proto 41 (6in4) from the HE tunnel server to be accepted permanently by the tunnel router.

If you're running some firewall script or bundled firewall system which controls netfilter/iptables, you may want to make sure that the outbound rules (OUTPUT chain) allow protocol 41 too (typically they're set to allow anything inside -> outside though).

Firewall stuff from IPv6 itself is done with ip6tables of course.  So, you just need to make the ip6tables security policy mirror the iptables policy to implement what you want (like security policy for IPv4/IPv6).

[smiffy]

Thanks for that, much appreciated.  I'll give that a go tomorrow (it being late evening here) and see if it fixes the problem.  I try to avoid doing firewall config when a) tired and/or b) have wine inside me - not a good risk ;-)

UPDATE: tested, works a charm. I owe @jimb a very large beer.

[b1naryg0dws]

hey im on ClearOS(a router fork of CentOS 5.4) and i was wondering if anyone had the sysconfig files for CentOS5.4 or RHEL5.4 or a backup of

http://deve.loping.net/projects/he-update/

since its down or possibly another fix...with all the different mods to the config files im bit confuesed as to which works
Thanks from Codie

[thaithanhthuy]

I just want all current services running dual-stack.  In fact, as a work-around, I've set up this little cron job to do a keep-alive

[phipac]

OK, so everything has been working fine for too long.  That means, it's time to break it and fix it better, right?  I have been searching the forums all morning for this, but...

What do I need to do differently to make use of my routed /48s from HE?  Here is what I have (addresses altered, of course):

Server IPv6 = 2001:470:x:999::1/64
Client IPv6 = 2001:470:x:999::2/64
Routed /64 = 2001:470:y:999::/64
Routed /48 = 2001:470:f1yy::/48

# vi ifcfg-sit1
DEVICE=sit1
BOOTPROTO=none
ONBOOT=yes
IPV6INIT=yes
IPV6_TUNNELNAME="he"
IPV6TUNNELIPV4="111.222.333.444"
IPV6TUNNELIPV4LOCAL="555.666.777.888"
IPV6ADDR="2001:470:x:999::2/64"
TYPE=sit

# vi ifcfg-WAN
DEVICE=eth0
BOOTPROTO=none
ONBOOT=yes
TYPE=Ethernet
USERCTL=no
IPV6INIT=yes
IPV6_AUTOCONF=no
IPV6ADDR=2001:0470:f1yy:0001:0000:0000:0000:0001
PEERDNS=yes
NETMASK=255.0.0.0
IPADDR=555.666.777.888
GATEWAY=555.666.777.1

#vi radvd.conf
interface eth0
{
        AdvSendAdvert on;
        MinRtrAdvInterval 30;
        MaxRtrAdvInterval 100;
        prefix 2001:470:f1yy:a::/64
        {
                AdvOnLink on;
                AdvAutonomous on;
                AdvRouterAddr on;
        };

};

There seems to be something missing because I cannot connect out on a box that receives an address from radvd.  Do I also have to assign an address to my WAN interface from the routed /48 in addition to the routed /64?  Thanks for your help!

[broquea]

If you are advertising out of eth0, then you need to configure 2001:470:f1yy:a::1/64 on eth0

[phipac]

If you are advertising out of eth0, then you need to configure 2001:470:f1yy:a::1/64 on eth0

Thanks - that did the trick.  I figured it was something simple.  I guess the moral of that story is that you need to have a ::1/64 on the "gateway" interface for any subnets that are being used internally?  Makes sense...