Testing CLAT for IPv6-only mobile networks

[jlaakkonen]

@pa4wdh

I’ll just share the script i made to make the VPN work. The loop at the start is just to wait for me to start the VPN via the GUI, i’m not aware of a way to do that from CLI.

#!/bin/sh

BASEDIR="/home/defaultuser/vpn"
HOME_IP=x.x.x.x
HOME_DNS=y.y.y.y

if [ "$1" = "start" ]
then
 # Wait for VPN
 echo "Now start VPN from settings "
 ip address show vpn0
 while [ "$?" = "1" ]
 do
  sleep 1
  ip address show vpn0
 done
 sleep 5

 # Fix IPv4 settings
 ip route add $HOME_IP dev clat
 cp /etc/resolv.conf $BASEDIR/resolv.conf.old
 echo "nameserver $HOME_DNS" > /etc/resolv.conf

 # Fix IPv6 settings
 ip -6 route | grep "^default " | cut -d " " -f 1-5 > $BASEDIR/def-gw6.old
 ip -6 route add `cat $BASEDIR/def-gw6.old | sed -e "s/default/64:ff9b::\/16/"`
 ip -6 route del `cat $BASEDIR/def-gw6.old`
fi

if [ "$1" = "stop" ]
then
 # Undo IPv4 settings
 cp $BASEDIR/resolv.conf.old /etc/resolv.conf

 # Undo IPv6 settings
 ip -6 route del `cat $BASEDIR/def-gw6.old | sed -e "s/default/64::\/16/"`
 ip -6 route add `cat $BASEDIR/def-gw6.old`                               
fi

It’s intended to be run as root, variable HOME_IP is my home IPv4 address which is the other endpoint of the VPN. HOME_DNS is the DNS for when the VPN is running, somehow the setting pushed via the VPN is ignored.
Intended use is to save as vpn.sh and use ./vpn.sh start and ./vpn.sh stop to start/stop the VPN. I’m sure it’s quite hacky, but it works for me™

After a closer look, yes, I agree that the script is hacky. Following things arose while testing and checking that:

1. Why do you have /16 as the CLAT prefix length? By default and according to the RFC it is defined int he global prefix is declared with /96 prefix length.

2. Removing the default route is kind of a tricky case with the default traffic going over IPv6. There are many reasons: in many cases the address is delivered with router advertisements or DHCPv6, so it would be set back at some point. And in my tests apparently kernel can enforce it back as well. So might it be enough just to add the extra route? It might be that the gateway setting within ConnMan causes this to be re-added, which might not be the case with real CLAT (I can only fake so much…)

3. Adding the IPv4 DNS as sole DNS service in the resolv.conf, which normally points to ConnMan’s own dnsproxy is usually really bad. But then again, that version you had of CLAT support the VPN side, as said, was not intended to work. Might be better to add a nameserver with connmanctl, like:
   connmanctl config $(connmanctl services|grep <visibleVPNnamehere>|grep -o "vpn_.*$") --nameservers <DNSServerHere>.

But after looking at that I got some ideas and those should be in 1.32+git194.13 when it is built. However, the gateway setting needs apparently improvements. Just noticed that. It is lacking support for the injected CLAT IPv4 in the sense that two separate indexes for a service should be supported. That is something for the next week. The route to the VPN IP (in OpenVPN terms, “trusted_ip” that is called via the openvpn-script back to ConnMan) should be then set correctly when VPN connects over CLAT.