TunSafe Forum

Welcome to the TunSafe Community Forum. This is open for discussions related to TunSafe and the WireGuard protocol.

You are not logged in.

#1 2018-08-08 21:36:19

cacus
Member
Registered: 2018-08-08
Posts: 7

FreeBSD wg-go vs ts-c++ comparison

Started this thread to compare the installation process and performance of the wireguard-go version vs the tunsafe-c++ version on a fresh FreeBSD installation but I got stuck.

First run:
$ pkg install git

TunSafe:
$ pkg install gcc7
$ git clone https://github.com/TunSafe/TunSafe.git
$ cd TunSafe
$ sh ./build_freebsd.sh

This went smooth. But I'm missing like "make install" so that tunsafe is being installed on the system.

Browsed to tunsafe.com/vpn to create a config file but I had no clue how to generate the private and public
key in FreeBSD with TunSafe so I generated the keys in the Windows version.

Maybe a "make install" command can echo some guidelines how to generate the public/priv keys?
Or maybe there can be a tunsafe --help command?

I put the generated config file in ts.conf and ran
$ nano ts.conf
$ ./tunsafe ts.conf

This output the following:
----------------------------------------------
Loading file: ts.conf
Run: /sbin/ifconfig tun0 10.34.165.136 mtu 1420 10.34.165.136 netmask 255.0.0.0 up
Unable to determine default interface.
----------------------------------------------

Ran ifconfig it did not seem to set the IP address to the interface?

$ ifconfig
tun0: flags=8010<POINTOPOINT,MULTICAST> metric 0 mtu 1420
        options=80000<LINKSTATE>
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
        groups: tun

I manually ran following (that was output by tunsafe above):
$ /sbin/ifconfig tun0 10.34.165.136 mtu 1420 10.34.165.136 netmask 255.0.0.0 up

The tun0 interface now has the correct IP when running ifconfig:
$ ifconfig
tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1420
        options=80000<LINKSTATE>
        inet 10.34.165.136 --> 10.34.165.136 netmask 0xff000000
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
        groups: tun

Trying to "ping 10.0.0.1" does not give a reply. It does not seem like the tunnel is up and I don't know how to debug if the tunnel is up?

Doing a "ps aux" does not show that tunsafe is started.

I would like to run "tunsafe" to see the active interfaces/peers but it just output "Syntax: tunsafe file.conf"

Now I'm stuck neutral

Last edited by cacus (2018-08-08 21:46:13)

Offline

#2 2018-08-08 21:57:29

ludde
Administrator
Registered: 2018-03-09
Posts: 127

Re: FreeBSD wg-go vs ts-c++ comparison

Please do git pull and retry, I fixed a problem with the FreeBSD code.

Note that TunSafe will not keep running in the background, if it exits immediately it didn't start properly.

I will add key generation in the next version.

Offline

#3 2018-08-08 22:27:37

cacus
Member
Registered: 2018-08-08
Posts: 7

Re: FreeBSD wg-go vs ts-c++ comparison

I edited ts.conf and added "Table = off" in the "Interface" section.

Now it output:
$ ./tunsafe ts.conf
Loading file: ts.conf
Run: /sbin/ifconfig tun0 10.34.165.136 mtu 1420 10.34.165.136 netmask 255.0.0.0 up
Sending handshake...

It's kinda getting stuck here instead of returning/exiting like it did before.

I tried this:

1. I imported the FreeBSD config in the Windows client but it got also stuck on "Sending handshake.." (RO server)
2. I switched to the NY endpoint in the Windows client and it connected just fine "Connection established.".
3. I disconnected the Windows client and switched to the NY endpoint in the FreeBSD config (same priv/pub key as in Win)
4. FreeBSD is still stuck on "Sending handshake..."
5. I did ctrl-c to exit in FreeBSD
6. Tried to connect to NY server in the Windows client and now it's also stuck on "Sending handshake..."
7. Switched to SE endpoint in Windows client and it connected. Disconnected and reconnected in Windows to verify and it reconnected.
8. Disconnected in Windows and changed to SE endpoint in the FreeBSD config.
9. FreeBSD is stuck on "Sending handshake..." to the SE endpoint
10. Tried to connect in Windows to the SE endpoint again but now the Windows client is stuck on "Sending handshake.."

It seems like when I try to connect with the FreeBSD client it kills the public key so that the Windows client can no longer connect with it?

Edit:
I have not made a new pull yet

Last edited by cacus (2018-08-08 22:32:20)

Offline

#4 2018-08-08 22:36:39

cacus
Member
Registered: 2018-08-08
Posts: 7

Re: FreeBSD wg-go vs ts-c++ comparison

I can verify that the public key is being "killed"

Created a new config on the vpn page and imported in Windows client. Connected just fine

Ran the same config in FreeBSD but with the line "Table = off" added
It's stuck on "Sending handshake..."

When I do ctrl-c and try to connect in Windows again the Windows client can no longer connect (unless I change the endpoint)

Last edited by cacus (2018-08-08 22:39:26)

Offline

#5 2018-08-08 22:51:15

ludde
Administrator
Registered: 2018-03-09
Posts: 127

Re: FreeBSD wg-go vs ts-c++ comparison

It's just not printing that message on FreeBSD. The connection will still be established. Try pinging in another shell. You can git pull and it will now print Connection established. It was not printed in the non-multithreaded implementation FreeBSD uses.

Offline

#6 2018-08-08 22:52:47

ludde
Administrator
Registered: 2018-03-09
Posts: 127

Re: FreeBSD wg-go vs ts-c++ comparison

The reason why the public key is "killed" is because the server remembers the last timestamp the client used, and it needs to be ever-increasing. If the timestamp on your Windows machine vs FreeBSD machine are slightly off you'll get such behavior. It's not actually killed it's just waiting for the FreeBSD client to return a higher timestamp than what Windows did.

Offline

#7 2018-08-08 23:08:38

cacus
Member
Registered: 2018-08-08
Posts: 7

Re: FreeBSD wg-go vs ts-c++ comparison

ludde wrote:

It's just not printing that message on FreeBSD. The connection will still be established. Try pinging in another shell. You can git pull and it will now print Connection established. It was not printed in the non-multithreaded implementation FreeBSD uses.

$ ./tunsafe ts2.conf
Loading file: ts2.conf
Run: /sbin/ifconfig tun0 10.115.96.243 mtu 1420 10.115.96.243 netmask 255.0.0.0 up
Run: /sbin/route -q add 10.0.0.0/8 10.115.96.243
Sending handshake...
Connection established. IP 10.115.96.243

Offline

#8 2018-08-08 23:09:50

cacus
Member
Registered: 2018-08-08
Posts: 7

Re: FreeBSD wg-go vs ts-c++ comparison

$ ping 10.0.0.1
PING 10.0.0.1 (10.0.0.1): 56 data bytes
64 bytes from 10.0.0.1: icmp_seq=0 ttl=64 time=133.967 ms
64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=134.929 ms

Now it works! smile

The git pull fixed it!

Offline

#9 2018-08-08 23:10:49

ludde
Administrator
Registered: 2018-03-09
Posts: 127

Re: FreeBSD wg-go vs ts-c++ comparison

Great!

Offline

#10 2018-08-08 23:25:09

cacus
Member
Registered: 2018-08-08
Posts: 7

Re: FreeBSD wg-go vs ts-c++ comparison

ludde wrote:

The reason why the public key is "killed" is because the server remembers the last timestamp the client used, and it needs to be ever-increasing. If the timestamp on your Windows machine vs FreeBSD machine are slightly off you'll get such behavior. It's not actually killed it's just waiting for the FreeBSD client to return a higher timestamp than what Windows did.

Which timestamp is being used?

The clock/date is different by one hour on Windows vs the FreeBSD computer. Is that the reason and does it then need to wait one hour before it can reconnect?

Last edited by cacus (2018-08-08 23:49:01)

Offline

#11 2018-08-09 00:13:35

ludde
Administrator
Registered: 2018-03-09
Posts: 127

Re: FreeBSD wg-go vs ts-c++ comparison

It uses the timestamp of the system clock. Yes then it needs to wait one hour.

Offline

Board footer

Powered by FluxBB