Hello from Hamburg, Germany,
i just tried to set up a tunnel concerning several of the here suggested solutions, but it didn´ t work. I use Debian Etch here and the solution I found and that works is as follows (for permanent setup via -interfaces-):
# Hurricane Electric Tunnel aufbauen
auto he-ipv6
iface he-ipv6 inet6 v4tunnel
endpoint $ipv4a
address 2001:0470:xxxx:xxxx::2
netmask 64
mtu 1480
up ip -6 route add 2000::/3 dev he-ipv6
(xxxx means your nummers)
You can test the tunnel via http://www.kame.net, the easiest way to see if a ipv6 tunnel works. If the turtle on the screen moves, then you got ipv6 working.
On Debian Lenny just now here's what I needed in /etc/network/interfaces:
auto he-ipv6
iface he-ipv6 inet6 v4tunnel
endpoint <Server IPv4 address>
local <Client IPv4 address>
ttl 255
address <Client IPv6 address>
netmask 64
mtu 1480
The bits in <> use the same labels as the current he.net 'Tunnel Details' pages.
Here's what I have in a Fedora system, in /etc/sysconfig/network-scripts/ifcfg-sit1 (there are three files with this name, hardlinked to each other).
# Hurricane Electric V6V4 tunnel
NAME="Hurricane Electric SIT"
DEVICE=sit1
ONBOOT=yes
USERCTL=yes
BOOTPROTO=none
PEERDNS=no
IPV6INIT=yes
IPV6_AUTOTUNNEL=yes
IPV6ADDR="$ipv6b/64"
# IPV6ADDR_SECONDARIES=""
IPV6_MTU=1280
IPV6_ROUTER=yes
IPV6_AUTOCONF=no
IPV6_CONTROL_RADVD=yes
IPV6TUNNELIPV4=$ipv4a
IPV6TUNNELIPV4LOCAL=$ipv4b
PHYSDEV=eth0
TYPE=sit
DEVICETYPE=sit
NM_CONTROLLED=no
You might want to turn off USERCTL, and tinker with the MTU; mine's at the minimum. IPV6_AUTOTUNNEL and IPV6_AUTOCONF are mysteries to me, but it works with those values. I'm not sure if PHYSDEV is necessary, but if it is, it's the interface with $ipv4b on it. TYPE and DEVICETYPE are probably redundant, but I'm not sure which one is really needed. You could try letting NetworkManager control it with NM_CONTROLLED, but if you do, you're on your own.
IPV6ADDR_SECONDARIES could be filled with extra addresses from your routed /64 and /48, if you want your routing Linux box to be able to use those addresses. Maybe.
And of course, in your /etc/sysconfig/network file, you should have "IPV6_DEFAULTDEV=sit1". If you like, you can also include "IPV6_DEFAULTGW=$ipv6a".
Edit: Minor typo in env variable name.
The bits in <> use the same labels as the current he.net 'Tunnel Details' pages; and note that cutting and pasting addresses from the page which include the /64 at the end isn't helpful ;)
I added lines for up and down (Ubuntu Koala alpha):
auto he-ipv6
iface he-ipv6 inet6 v4tunnel
endpoint <Server IPv4 address>
local <Client IPv4 address>
ttl 255
address <Client IPv6 address>
netmask 64
mtu 1480
up ip -6 route add default dev he-ipv6
down ip -6 route del default dev he-ipv6
I am trying to make my tunnel configuration persistent, as in it will still be there when my system reboots. I used the code generated by the example configuration tool:
modprobe ipv6
ip tunnel add he-ipv6 mode sit remote 66.220.18.42 local x.x.x.x ttl 255
ip link set he-ipv6 up
ip addr add x:x:x:x::2/64 dev he-ipv6
ip route add ::/0 dev he-ipv6
ip -f inet6 addr
What would be the proper way to make this configuration persistent/permanent?
I am using Linux, CentOS 5.4
Thanks
When I followed all the instructions I could find on a Fedora 12 host, it would work just fine - until I tried to use that host as a router to get the rest of my network connected.
Having the sit1 address with a /64 prefix caused packets to bounce back and forth between he.net and my router instead of getting passed to my workstation. Using a /126 prefix instead fixed that problem. Here's what I'm using:
/etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
ONBOOT=yes
BOOTPROTO=none
HWADDR=xx:xx:xx:xx:xx:xx
NETMASK=255.255.255.0
IPADDR=$ipv4b
GATEWAY=xxx.xxx.xxx.xxx
TYPE=Ethernet
USERCTL=no
PEERDNS=yes
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6ADDR=[a static ipv6 address]/64
/etc/sysconfig/network-scripts/ifcfg-sit1
# Hurricane Electric V6V4 tunnel
NAME="Hurricane Electric SIT"
DEVICE=sit1
ONBOOT=yes
USERCTL=no
BOOTPROTO=none
PEERDNS=no
IPV6INIT=yes
IPV6_AUTOTUNNEL=yes
IPV6ADDR="$ipv6b/126"
IPV6_ROUTER=yes
IPV6_AUTOCONF=no
IPV6_CONTROL_RADVD=yes
IPV6TUNNELIPV4=$ipv4a
IPV6TUNNELIPV4LOCAL=$ipv4b
PHYSDEV=eth0
TYPE=sit
DEVICETYPE=sit
NM_CONTROLLED=no
IPV6_DEFAULTGW=$ipv6a
IPV6_DEFAUTLDEV=sit1
/etc/sysconfig/network
NETWORKING=yes
HOSTNAME=host.domain.com
NETWORKING_IPV6=yes
IPV6_ROUTER=yes
IPV6FORWARDING=yes
/etc/radvd.conf
interface eth0
{
AdvSendAdvert on;
MinRtrAdvInterval 30;
MaxRtrAdvInterval 100;
prefix 2001:x:x:x::/64
{
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr off;
};
};
On a related note, adding "Family=inet6" to DAEMON_OPTIONS in /etc/mail/sendmail.mc was all I needed to get sendmail listening on IPv6.
???
What were you using on your LAN? I hope it was the routed /64, and not the HE tunnel address...
I don't see why Linux would ever behave the way you described. I've never had it happen on Gentoo or Ubuntu boxes I run.
The only way I see this happening is if you tried to use your "Client IPv6 Address" on both the tunnel interface and your LAN interface.
Hello, I used the following to get IPv6 working on my CentOS 5.4 and it worked great.
ifconfig sit0 up
ifconfig sit0 inet6 tunnel ::216.66.80.26
ifconfig sit1 up
ifconfig sit1 inet6 add 2001:470:1f08:9b9::2/64
route -A inet6 add ::/0 dev sit1
Now I want to add few IP's from my /48 subnet, do I add it to the sit0 or sit1?
ifconfig sit0 inet6 IP:NUMBER
or
ifconfig sit1 inet6 IP:NUMBER
?
Thank you.
Neither. You add it to your OTHER interfaces - like eth0.
Also, don't try to use the whole /48. Split it into /64s.
Centos 5.4
OK now that I have the firewall issue figured out, I need to make my Centos configuration persistent. I have been successful at using both the ip and the ifconfig suggestions for setting up the tunnels (the ip route seems a lot cleaner, tho), and then adding a static IPv6 address to eth0. I can get everything to work that way. Unfortunately, neither survive a reboot or a 'service network restart'. I have spent the last three weeks (no joke) reading every post I could possibly find on this subject, and have tried just about every suggestion for creating device scripts. Every script has something a little different, and nothing seems to be working. I understand IPv6, but admittedly am something of a Linux newbie (I found it very easy to get IPv6 working 100% on my Windows network). I must be missing something, or maybe I just want it to be simpler than is possible. Does anyone truly have a script that works for getting a persistent tunnel on Centos 5.4? Thanks!
Phil
You'll need to set up ifup-sit and ifup-ipv6 files w/ proper config variables in them. Should be documented in /usr/share/doc/initscripts-<version>.
I have taken the long way of ensuring that "my tunnel" is maintained after a "reboot" or "service network restart". This is by putting the tunnel configuration into a script in /bin (to use after a manual restart of the network service) and hardlinking it to /etc/init.d (for system reboots).
Basically, the script configures the tunnel using sit0 and sit1 as devices and then adds routed /64 addresses to eth0 and eth1. RADVD is then used to announce the routed /64 addresses to the LAN clients for distribution.
Quote from: ourkopu on April 06, 2010, 03:19:07 PM
I have taken the long way of ensuring that "my tunnel" is maintained after a "reboot" or "service network restart". This is by putting the tunnel configuration into a script in /bin (to use after a manual restart of the network service) and hardlinking it to /etc/init.d (for system reboots).
Basically, the script configures the tunnel using sit0 and sit1 as devices and then adds routed /64 addresses to eth0 and eth1. RADVD is then used to announce the routed /64 addresses to the LAN clients for distribution.
Yep. No harm in writing your own init.d scripts. Or as most people do, copying one and replacing the start) stop) clauses with your own code. :P
Hi, I created an utility to setup the tunnel and update the endpoint (in case of a dynamic ip). You can download the script here:
http://deve.loping.net/projects/he-update/
I hope it is useful to someone :)
- Axel
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?
Quote from: smiffy on May 30, 2010, 08:07:14 PM
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 * * * * ...." :D
@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.)
Quote from: smiffy on May 31, 2010, 03:27:03 AM
@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.
QuoteThis 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 ACCEPTThat 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).
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.
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
Quote from: ago on May 20, 2010, 07:04:34 AM
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
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
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!
If you are advertising out of eth0, then you need to configure 2001:470:f1yy:a::1/64 on eth0
Quote from: broquea on August 11, 2010, 10:42:06 AM
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...