Freenet6 on FreeBSD

Last year I wrote IPv6 Only FreeBSD Scenario. I described using the net/tspc2 port and registering with Hexago/Freenet6. On Friday the net/tspc2 port will be deprecated. I spoke with the port maintainer and he said that he deprecated the port because the source code was no longer available at hexago.com. I looked around and found that I could download gw6c4_2_2src.tar.gz from go6.net, an IPv6 portal sponsored by Hexago. Furthermore, I found the FreeBSD port net/freenet6 -- which appears to be the same thing as the net/tspc2 port. In fact, the net/freenet6 maintainer just updated the port to point to the go6.net download location for gw6c4_2_2src.tar.gz.

I decided to remove the net/tspc2 port from my gateway and replace it with net/freenet6. 

mwmicro:/usr/local/tbz# pkg_add -v freenet6-2.1.1_6.tbz 
Requested space: 154796 bytes, free space: 881494016 bytes in
 /var/tmp/instmp.qCS7Fo
extract: Package name is freenet6-2.1.1_6
extract: CWD to /usr/local
extract: /usr/local/man/man5/tspc.conf.5.gz
extract: /usr/local/man/man8/tspc.8.gz
extract: /usr/local/bin/tspc
extract: /usr/local/share/examples/freenet6/tspc.conf.sample
extract: /usr/local/bin/tspc-freebsd.sh
extract: /usr/local/bin/checktunnel.sh
extract: /usr/local/etc/rc.d/freenet6.sh
extract: CWD to .
Running mtree for freenet6-2.1.1_6..
mtree -U -f +MTREE_DIRS -d -e -p /usr/local >/dev/null
Attempting to record package into /var/db/pkg/freenet6-2.1.1_6..
Package freenet6-2.1.1_6 registered in /var/db/pkg/freenet6-2.1.1_6

Now that the package is installed, please finish it with the following steps:

- Copy /usr/local/share/examples/freenet6/tspc.conf.sample to /usr/local/etc/tspc.conf
- Check the values of /usr/local/etc/tspc.conf. If you have registered at
  the website, fill in your userid and password there.
- Run /usr/local/etc/rc.d/freenet6.sh to start the tunnel.
- Try to ping a IPv6 host, for example: ping6 www.jp.freebsd.org

Please note that tsps[12].freenet6.net are not in service anymore,
please use broker.freenet6.net instead.

Net/freenet6 now supports rc.subr.
Please add 'freenet6_enable="YES"' to your /etc/rc.conf to make it
start autoamtically at startup.

I made the changes as noted below to the tspc.conf file:

mwmicro:/usr/local/etc# diff -u /usr/local/share/examples/freenet6/
 tspc.conf.sample /usr/local/etc/tspc.conf

--- /usr/local/share/examples/freenet6/tspc.conf.sample Sat Sep  2 16:11:17 2006
+++ /usr/local/etc/tspc.conf    Tue May  8 13:38:39 2007
@@ -54,7 +54,8 @@
 #  your_userid means the userid you registered to the broker. The userid
 #   must be using only legal dns label names (eg: [a-zA-Z0-9-] ) since
 #   the userid is used inside your user hostname.
-userid=anonymous
+#userid=anonymous
+userid=taosecurity
 
 #
 # password:
@@ -62,7 +63,8 @@
 #  leave empty if userid=anonymous
 #  your_password means the password you have been assigned with your
 #   userid
-passwd=
+#passwd=
+passwd=OBSCURED
 
 #
 # Name of the script:
@@ -106,7 +108,8 @@
 #
 # The default value is the Freenet6 tunnel broker for 
 # anonymous accounts (anon.freenet6.net)
-server=anon.freenet6.net
+#server=anon.freenet6.net
+server=broker.freenet6.net
 
 #
 #
@@ -175,20 +178,20 @@
 #
 # host_type=host|router
 #  default = host.
-#host_type=router
+host_type=router
 
 #
 # prefixlen specifies the required prefix length for the TSP client 
 #  network. Valid values are 64 or 48. 64 is for one link. 48 is for
 #  a whole enterprise network (65K links).
-#prefixlen=48
+prefixlen=48
 
 #
 # if_prefix is the name of the OS interface that will be configured
 #  with the first /64 of the received prefix from the broker and the
 #  router advertisement daemon is started to advertise that prefix
 #  on the if_prefix interface.
-#if_prefix=
+if_prefix=sf3
 
 #
 # For reverse DNS delegation of the prefix, define the following:

Next I added this

freenet6_enable="YES"

to /etc/rc.conf.

Finally I started the client.

mwmicro:/root# /usr/local/etc/rc.d/freenet6.sh start
Starting freenet6.
tspc - Tunnel Setup Protocol Client v2.1.1
Initializing (use -h for help)

Connecting to server with reliable udp
Got tunnel parameters from server, setting up local tunnel
Going daemon, check tspc.log for tunnel creation status

The client creates gif0 for use in tunneling. 

mwmicro:/root# ifconfig gif0
gif0: flags=8051 mtu 1280
        tunnel inet 69.143.202.28 --> 64.86.88.116
        inet6 2001:5c0:8fff:fffe::5889 --> 2001:5c0:8fff:fffe::5888
         prefixlen 128 
        inet6 fe80::204:e2ff:fe29:4c3c%gif0 prefixlen 64 scopeid 0x9 

mwmicro:/root# netstat -nr -f inet6 | grep gif
default                           2001:5c0:8fff:fffe::5888      UGS      gif0
2001:5c0:8fff:fffe::5888          link#9                        UHL      gif0
fe80::%gif0/64                    link#9                        UC       gif0
fe80::204:e2ff:fe29:4c3c%gif0     link#9                        UHL       lo0
ff01:9::/32                       link#9                        UC       gif0
ff02::%gif0/32                    link#9                        UC       gif0

With gif0 set up to tunnel IPv6 in IPv4, I was able to ping6 www.kame.net.

mwmicro:/root# ping6 -c 1 www.kame.net
PING6(56=40+8+8 bytes) 2001:5c0:8fff:fffe::5889 --> 2001:200:0:8002:203:47ff:fea5:3085
16 bytes from 2001:200:0:8002:203:47ff:fea5:3085, icmp_seq=0 hlim=49
 time=228.016 ms

--- www.kame.net ping6 statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 228.016/228.016/228.016/0.000 ms

I was also able to ping6 www.kame.net from an IPv6-only host behind the gateway.

How about this for coolness -- this version of Freenet6 also supports working on an IPv4 client behind NAT. To test this I installed net/freenet6 on VMware, copied /usr/local/share/examples/freenet6/tspc.conf.sample to /usr/local/etc/tspc.conf, added the "enable" statement to /etc/rc.conf, and started freenet6.sh. The VM now had a tun1 interface:

tun1: flags=8051 mtu 1280
        inet6 2001:5c0:8fff:ffff::133 --> 2001:5c0:8fff:ffff::132
         prefixlen 128 
        Opened by PID 580

And this routing table:

neely-bsd# netstat -nr -f inet6 | grep tun1
default                           2001:5c0:8fff:ffff::132       UGS      tun1
2001:5c0:8fff:ffff::132           link#5                        UHL      tun1
ff01:5::/32                       link#5                        UC       tun1
ff02::%tun1/32                    link#5                        UC       tun1

I was able to ping6 www.kame.net.

neely-bsd# ping6 -c 2 www.kame.net
PING6(56=40+8+8 bytes) 2001:5c0:8fff:ffff::133 -->
 2001:200:0:8002:203:47ff:fea5:3085
16 bytes from 2001:200:0:8002:203:47ff:fea5:3085, icmp_seq=0 hlim=50
 time=295.101 ms
16 bytes from 2001:200:0:8002:203:47ff:fea5:3085, icmp_seq=1 hlim=50
 time=292.508 ms

In fact, from the VM I could ping6 the gateway's public address:

neely-bsd# ping6 -c 2 2001:5c0:8fff:fffe::5889
PING6(56=40+8+8 bytes) 2001:5c0:8fff:ffff::133 -->
 2001:5c0:8fff:fffe::5889
16 bytes from 2001:5c0:8fff:fffe::5889, icmp_seq=0 hlim=63
 time=127.114 ms
16 bytes from 2001:5c0:8fff:fffe::5889, icmp_seq=1 hlim=63
 time=132.455 m

The difference between these implementations is the encapsulation. For the gateway, Freenet6 uses IP protocol 41, like this:

richard@neely:~$ tcpdump -n -r ipv6.lpc ip proto 41

reading from file ipv6.lpc, link-type EN10MB (Ethernet)
14:14:01.775391 IP 69.143.202.28 > 64.86.88.116: IP6 2001:5c0:8fff:fffe::5889
 > 2001:5c0:8fff:fffe::5888: ICMP6, neighbor solicitation, who has 
 2001:5c0:8fff:fffe::5888, length 24

14:14:01.838210 IP 64.86.88.116 > 69.143.202.28: IP6 2001:5c0:8fff:fffe::5888
 >  2001:5c0:8fff:fffe::5889: ICMP6, neighbor advertisement, tgt is 
 2001:5c0:8fff:fffe::5888, length 24

14:14:17.083741 IP 69.143.202.28 > 64.86.88.116: IP6 2001:5c0:8fff:fffe::5889
 > 2001:200:0:8002:203:47ff:fea5:3085: ICMP6, echo request, seq 0, length 16

14:14:17.317006 IP 64.86.88.116 > 69.143.202.28: IP6 
 2001:200:0:8002:203:47ff:fea5:3085 > 2001:5c0:8fff:fffe::5889:
 ICMP6, echo reply, seq 0, length 16


For the client behind NAT, Freenet6 uses IPv6 in UDP port 3653. In this example I send two ICMPv6 echo packets to www.kame.net. Tshark decodes it like this:

richard@neely:~$ tshark -n -r udp.lpc udp.port==3653

  1   0.000000  192.168.2.9 -> 64.86.88.117 UDP Source port: 49454
  Destination port: 3653
  2   0.000017  192.168.2.9 -> 64.86.88.117 UDP Source port: 49454
  Destination port: 3653
  3   0.051616 64.86.88.117 -> 192.168.2.9  UDP Source port: 3653 
 Destination port: 49454
  7   0.080622  192.168.2.9 -> 64.86.88.117 UDP Source port: 49454 
 Destination port: 3653
  8   0.080641  192.168.2.9 -> 64.86.88.117 UDP Source port: 49454 
 Destination port: 3653
  9   0.314504 64.86.88.117 -> 192.168.2.9  UDP Source port: 3653 
 Destination port: 49454
 10   0.947704  192.168.2.9 -> 64.86.88.117 UDP Source port: 49454 
 Destination port: 3653
 11   0.947737  192.168.2.9 -> 64.86.88.117 UDP Source port: 49454 
 Destination port: 3653
 12   1.175285 64.86.88.117 -> 192.168.2.9  UDP Source port: 3653 
 Destination port: 49454

If I tell Tshark to decode the protocol as Teredo (which implies IPv6 in UDP) I see this.

richard@neely:~$ tshark -n -r udp.lpc udp.port==3653 -d
 udp.port==3653,teredo

  1   0.000000 2001:5c0:8fff:ffff::133 -> 2001:5c0:8fff:ffff::132
 ICMPv6 Echo request
  2   0.000017 2001:5c0:8fff:ffff::133 -> 2001:5c0:8fff:ffff::132
 ICMPv6 Echo request
  3   0.051616 2001:5c0:8fff:ffff::132 -> 2001:5c0:8fff:ffff::133
 ICMPv6 Echo reply
  7   0.080622 2001:5c0:8fff:ffff::133 ->
 2001:200:0:8002:203:47ff:fea5:3085 ICMPv6 Echo request
  8   0.080641 2001:5c0:8fff:ffff::133 ->
 2001:200:0:8002:203:47ff:fea5:3085 ICMPv6 Echo request
  9   0.314504 2001:200:0:8002:203:47ff:fea5:3085 ->
 2001:5c0:8fff:ffff::133 ICMPv6 Echo reply
 10   0.947704 2001:5c0:8fff:ffff::133 ->
 2001:200:0:8002:203:47ff:fea5:3085 ICMPv6 Echo request
 11   0.947737 2001:5c0:8fff:ffff::133 ->
 2001:200:0:8002:203:47ff:fea5:3085 ICMPv6 Echo request
 12   1.175285 2001:200:0:8002:203:47ff:fea5:3085 ->
 2001:5c0:8fff:ffff::133 ICMPv6 Echo reply

What's interesting about that is the ICMPv6 used earlier in the trace to 2001:5c0:8fff:ffff::132, the other side of the tun1 tunnel, to prepare to carry the ICMPv6 traffic to 2001:200:0:8002:203:47ff:fea5:3085 (www.kame.net), e.g.:

$ host 2001:200:0:8002:203:47ff:fea5:3085
5.8.0.3.5.a.e.f.f.f.7.4.3.0.2.0.2.0.0.8.0.0.0.0.0.0.2.0.1.0.0.2.ip6.arpa
 domain name pointer orange.kame.net.

Look at that result. IPv6 is a pain.

Comments

Anonymous said…
Yes, ipv6 is a pain, it hurts. But according to A recent revision to our best guess of when v4 runs out, we don't have long to solve the policy and technology problems...
3:50 PM
Post a Comment

Popular posts from this blog

Zeek in Action Videos

Image
This is a quick note to point blog readers to my Zeek in Action YouTube video series for the Zeek network security monitoring project .  Each video addresses a topic that I think might be of interest to people trying to understand their network using Zeek and adjacent tools and approaches, like Suricata, Wireshark, and so on.  I am especially pleased with Video 6 on monitoring wireless networks . It took me several weeks to research material for this video. I had to buy new hardware and experiment with a Linux distro that I had not used before -- Parrot .  Please like and subscribe, and let me know if there is a topic you think might make a good video.
Read more

MITRE ATT&CK Tactics Are Not Tactics

Image
Just what are "tactics"? Introduction MITRE ATT&CK  is a great resource, but something about it has bothered me since I first heard about it several years ago. It's a minor point, but I wanted to document it in case it confuses anyone else. The MITRE ATT&CK Design and Philosophy document from March 2020 says the following: At a high-level, ATT&CK is a behavioral model that consists of the following core components: • Tactics, denoting short-term, tactical adversary goals during an attack; • Techniques, describing the means by which adversaries achieve tactical goals; • Sub-techniques, describing more specific means by which adversaries achieve tactical goals at a lower level than techniques; and • Documented adversary usage of techniques, their procedures, and other metadata. My concern is with MITRE's definition of "tactics" as "short-term, tactical adversary goals during an attack," which is oddly recursive. The key word in the tacti
Read more

New Book! The Best of TaoSecurity Blog, Volume 4

Image
  I've completed the TaoSecurity Blog book series . The new book is  The Best of TaoSecurity Blog, Volume 4: Beyond the Blog with Articles, Testimony, and Scholarship .  It's available now for Kindle , and I'm working on the print edition.  I'm running a 50% off promo on Volumes 1-3 on Kindle through midnight 20 April. Take advantage before the prices go back up. I described the new title thus: Go beyond TaoSecurity Blog with this new volume from author Richard Bejtlich. In the first three volumes of the series, Mr. Bejtlich selected and republished the very best entries from 18 years of writing and over 18 million blog views, along with commentaries and additional material.  In this title, Mr. Bejtlich collects material that has not been published elsewhere, including articles that are no longer available or are stored in assorted digital or physical archives. Volume 4 offers early white papers that Mr. Bejtlich wrote as a network defender, either for technical or pol
Read more