Questions about Configuring a tunnel under Linux

[freese60]

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.

[miggy]

On Debian Lenny just now here's what I needed in /etc/network/interfaces:

Code:

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.

[jrowens]

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).

Code:

# 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.

[jg]

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):

Code:

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

[xdaxdb]

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:

Code:

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

[adsllc]

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

Code:

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

Code:

# 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

Code:

NETWORKING=yes
HOSTNAME=host.domain.com

NETWORKING_IPV6=yes
IPV6_ROUTER=yes
IPV6FORWARDING=yes

/etc/radvd.conf

Code:

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.

[jimb]

 

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.

[emilvals]

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.

[snarked]

Neither.  You add it to your OTHER interfaces - like eth0.

[jimb]

Also, don't try to use the whole /48.  Split it into /64s.

[aprsca]

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

[jimb]

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>.

[ourkopu]

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.

[jimb]

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. 

[ago]

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