The simplest way to create a static 6in4 tunnel in Ubuntu, or any other Debian based distro, is to edit
Here is a template with the information you will need to add:
auto tun1 iface tun1 inet6 v4tunnel address <your IPv6 address> netmask 64 ttl 64 endpoint <remote IPv4 tunnel address> up ip link set mtu 1280 dev tun1 up ip route add 2000::/3 dev tun1
Lets take a brief look at what each line does.
auto tun1 is used by the
/etc/init.d/networking script. The auto parameter will instruct the script to automatically start or stop the interface. The script will get called during startup and will bring up this interface automatically. This line is entirely optional and depends on your personal preference.
iface tun1 inet6 v4tunnel starts the configuration block for a 6in4 tunnel. That is, IPv6 traffic encapsulated in IPv4 packets. This is extremely similar to how GRE works with purely IPv4 traffic.
address <your IPv6 address> is where you need to specify the IPv6 address assigned to your machine. This is typically ends in ::2.
netmask 64 specifies the subnet mask for the IPv6 address you entered above. 64 is the smallest recommended subnet (see RFC3627 for why they no longer use numbers such as 127). 64 is what you should normally expect to use.
ttl 64 specifies the Time to Live value set for packets sent by your tunnel endpoint. This only affects the IPv4 packet that is used to encapsulate your v6 traffic. It does not change the original IPv6 packet. Time to Live is a number of iterations a packet can live through before it should be discarded. This number is reduced by one on every router it passes enroute to its destination. 64 is used here because it restricts the packet to roughly the same region.
Here is a quick break down of default TTL values:
endpoint <remote IPv4 tunnel address> is the IPv4 address to send encapsulated IPv6 traffic to. Your IPv6 provider will provide you with their IPv4 tunnel endpoint address.
up ip link set mtu 1280 dev tun1. This statement reconfigures the interface from the default MTU to 1280 bytes. This is desirable to prevent fragmentation because of the IPv6 packet being encapsulated in an IPv4 packet.
NOTE: SixXS seems to use 1280 as their default for tunnels, other providers likely use 1480 (which is default). If you leave this line out of your configuration, it should default to 1480.
up ip route add 2000::/3 dev tun1. This last statement adds a default route for all IPv6 traffic to be sent through device
tun1 which in turn would be encapsulated in an IPv4 packet and sent to the endpoint address of your IPv6 provider which would send it on its way through the IPv6 network.
After you have saved the file, the next step is to up the interface using ifup tun1 or if you decided to put in the
auto tun1 line you can restart your networking services using the init script:/etc/init.d/networking restart.
One final note. You can name this tunnel interface anything you want. For example, every time
tun1 was used above it could have been replaced with something more meaningful. For example, inSIXXS documentation, they usually call the interface
To create a self-signed certificate for use with a web server such as Apache follow the following steps:
Generate a server key:
openssl genrsa -aes128 -out server.key 4096
Next, create a certificate signing request with it. This will prompt for several things such as country, state, etc. Make certain that “Common Name (eg, YOUR name)” matches the fully qualified domain name of your server (or IP address if you do not have one). You may create a challenge password at this point, however it will mean more typing for you.
Create the certificate signing requests:
openssl req -new -key server.key -out server.csr
Next, sign the certificate signing request. The following example expires the key in 365 days:
openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt
Now, make a version of the server.key which does not require a password:
openssl rsa -in server.key -out server.key.insecure
mv server.key server.key.secure
mv server.key.insecure server.key
Be careful with these files as they are quite sensitive and permissions should set very carefully. Change ownership of them to root (if you are not already root). Some of the sites I have found say that you can 'chmod 000' however it does seem to work in my experiments. Root always retains an effective 600 (read/write) rights on everything.
You now have the following files which are suitable for use on your self-signed certificate site:
server.crt: The self-signed server certificate server.csr: Server certificate signing request server.key: The private server key (does not require a password when starting Apache server.key.secure: The private server key (it will require a password when starting Apache)