I'm using a build of FreeBSD 13.1 (stable/13) on a local machine and a build of 13.1 release on a VPS machine on a cloud service. The remote wireguard port was installed from FreeBSD ports, while the local wireguard port was installed from a local build.
After assigning an IPv4 address to each wireguard inteface on the remote and on the local machine, I'm able to ping each of the two machines from the other.
I can ssh from the remote machine, for 'uname' at least. Albeit with a high latency and intermittent link drop due to the network, I can eventually send a file over the wireguard channel from remote to local. For the wireguard channel from the local to the remote, I'm unable to ssh or to send any files or zfs snapshots.
From the remote machine, I can run
Now that the file transfers from remote are working out - kind of high latency, but it picks up eventually - still not sure if there's any way to work out file transfers or ssh from the local to the remote, over Wireguard
I'd also tried openvpn but I wasn't able to get the easy-rsa certificates to work out between the local and the remote.
uname for the local machine:
uname for the VPS instance - this build was using a local build hack from a few months ago, while I was bootstrapping an upgrade to FreeBSD 13.1 for the local machine. It's basically a build of 13.1-RELEASE
My wireguard config on the remote machine, via shell commands - the public interface on this remote machine has an address 147.182.245.210
The IPv4 address shown for the local endpoint, there, is not actually the local machine's IP address. It seems to be the address of the hotspot. The wireguard interface on the remote picks this up after I ping from the local to the remote. I've not hard-coded it into the wireguard config there.
There is, in fact, no wireguard running on that IP address, 172.58.38.243. I can still ssh to the local machine over that wireguard link.
On the local machine:
Ping from local:
Ping from remote:
From the remote,
On the remote host, scp from "my local" fails. The credentials negotiation works, but the inbound file transfer blocks indefinitely.
Albeit, a file transfer from the remote to the local actually works now, after a short pause ...
The wireguard interface on the local machine always shows up as disabled. Maybe this could be due to the odd placement of the endpoint in the perspective of the remote machine. The local machine can receive file data from the remote even so:
From the local, I can only ping to the remote's wireguard address. ssh does not work. traceroute does not work from either endpoint.
With file transfers eventually working out from the remote, at least there's that though
After assigning an IPv4 address to each wireguard inteface on the remote and on the local machine, I'm able to ping each of the two machines from the other.
I can ssh from the remote machine, for 'uname' at least. Albeit with a high latency and intermittent link drop due to the network, I can eventually send a file over the wireguard channel from remote to local. For the wireguard channel from the local to the remote, I'm unable to ssh or to send any files or zfs snapshots.
From the remote machine, I can run
ssh <local> uname -a and it works out. I can also scp somefile.tgz <local>: from the remote. Trying to transfer a file from my endpoint to the remote blocks indefinitely, after the credentials negotiation in scp. It only reaches the credentials negotiation when I try to pull the file from my end to the remote end, starting at the remote, otherwise it blocks entirely.Now that the file transfers from remote are working out - kind of high latency, but it picks up eventually - still not sure if there's any way to work out file transfers or ssh from the local to the remote, over Wireguard
I'd also tried openvpn but I wasn't able to get the easy-rsa certificates to work out between the local and the remote.
uname for the local machine:
Code:
FreeBSD xmin.cloud.thinkum.space 13.1-STABLE FreeBSD 13.1-STABLE #0 build/stable/13-n252436-b63021e001d: Sun Oct 9 05:52:29 PDT 2022 gimbal@xmin.cloud.thinkum.space:/usr/obj/xmin_FreeBSD-13.1-STABLE_amd64/usr/src/amd64.amd64/sys/XMIN amd64uname for the VPS instance - this build was using a local build hack from a few months ago, while I was bootstrapping an upgrade to FreeBSD 13.1 for the local machine. It's basically a build of 13.1-RELEASE
Code:
FreeBSD dist00.dist.cloud.thinkum.space 13.1-RELEASE FreeBSD 13.1-RELEASE ci/patch/releng/13.1/bootstrap-mk-e5184abbb RIPARIAN amd64My wireguard config on the remote machine, via shell commands - the public interface on this remote machine has an address 147.182.245.210
Code:
# wg quick up /usr/local/etc/wireguard/wireguard.conf
# ifconfig wireguard inet 10.10.0.1/24 up
# wg showconf wireguard
[Interface]
ListenPort = 444
PrivateKey = <xyzzy>=
[Peer]
PublicKey = cN4yEW9YJMIgeC0XUpF3Gfb7/tzOoJ+xuLTCkZ+bvjM==
AllowedIPs = 10.10.0.0/24
Endpoint = 172.58.38.240:38016
# wg
interface: wireguard
public key: efBnWXVb9zXWe6rJwhUmuEW3VzjsW+yiknaORWqQnFc=
private key: (hidden)
listening port: 444
peer: cN4yEW9YJMIgeC0XUpF3Gfb7/tzOoJ+xuLTCkZ+bvjM=
endpoint: 172.58.38.243:38016
allowed ips: 10.10.0.0/24
latest handshake: 23 minutes, 59 seconds ago
transfer: 412 B received, 380 B sentThe IPv4 address shown for the local endpoint, there, is not actually the local machine's IP address. It seems to be the address of the hotspot. The wireguard interface on the remote picks this up after I ping from the local to the remote. I've not hard-coded it into the wireguard config there.
There is, in fact, no wireguard running on that IP address, 172.58.38.243. I can still ssh to the local machine over that wireguard link.
On the local machine:
Code:
# wg quick up /usr/local/etc/wireguard/wireguard.conf
# ifconfig wireguard inet 10.10.0.2/24 up
# wg showconf wireguard
[Interface]
ListenPort = 63616
PrivateKey = <zyxxy>=
[Peer]
PublicKey = efBnWXVb9zXWe6rJwhUmuEW3VzjsW+yiknaORWqQnFc=
AllowedIPs = 10.10.0.0/24
Endpoint = 147.182.245.210:444
# wg
interface: wireguard
public key: cN4yEW9YJMIgeC0XUpF3Gfb7/tzOoJ+xuLTCkZ+bvjM=
private key: (hidden)
listening port: 63616
peer: efBnWXVb9zXWe6rJwhUmuEW3VzjsW+yiknaORWqQnFc=
endpoint: 147.182.245.210:444
allowed ips: 10.10.0.0/24
latest handshake: 22 minutes, 25 seconds ago
transfer: 356 B received, 436 B sentPing from local:
Code:
# ping 10.10.0.1
PING 10.10.0.1 (10.10.0.1): 56 data bytes
64 bytes from 10.10.0.1: icmp_seq=0 ttl=64 time=187.462 ms
64 bytes from 10.10.0.1: icmp_seq=1 ttl=64 time=60.792 ms
64 bytes from 10.10.0.1: icmp_seq=2 ttl=64 time=112.874 ms
64 bytes from 10.10.0.1: icmp_seq=3 ttl=64 time=87.454 ms
64 bytes from 10.10.0.1: icmp_seq=4 ttl=64 time=55.342 ms
64 bytes from 10.10.0.1: icmp_seq=5 ttl=64 time=120.310 ms
^C
--- 10.10.0.1 ping statistics ---
6 packets transmitted, 6 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 55.342/104.039/187.462/44.383 msPing from remote:
Code:
# ping 10.10.0.2
PING 10.10.0.2 (10.10.0.2): 56 data bytes
64 bytes from 10.10.0.2: icmp_seq=0 ttl=64 time=3117.415 ms
64 bytes from 10.10.0.2: icmp_seq=1 ttl=64 time=2116.938 ms
64 bytes from 10.10.0.2: icmp_seq=2 ttl=64 time=1115.956 ms
64 bytes from 10.10.0.2: icmp_seq=3 ttl=64 time=114.001 ms
64 bytes from 10.10.0.2: icmp_seq=4 ttl=64 time=57.152 ms
64 bytes from 10.10.0.2: icmp_seq=5 ttl=64 time=55.923 ms
64 bytes from 10.10.0.2: icmp_seq=6 ttl=64 time=69.279 ms
^C
--- 10.10.0.2 ping statistics ---
7 packets transmitted, 7 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 55.923/949.523/3117.415/1143.809 msFrom the remote,
ssh <user>@10.10.0.2 uname -a works as expected, and so does scp <pkg>.tgz <user>@10.10.0.2: eventually - maybe it is possible to run `zfs send` over the link, from that end. scp <user>@10.10.0.2:<pkg>.txz $PWD/ blocks.On the remote host, scp from "my local" fails. The credentials negotiation works, but the inbound file transfer blocks indefinitely.
Code:
remote $ scp -p user@10.10.0.2:/var/cache/pkglocal/All/<pkg>.pkg /tmp
(user@10.10.0.2) Password for user@xmin.cloud.thinkum.space
<pkg>.pkg 0% 0 0.0KB/s --:-- ETA
^CAlbeit, a file transfer from the remote to the local actually works now, after a short pause ...
Code:
$ scp -p /var/cache/pkg/bash-5.1.16.pkg user@10.10.0.2:/tmp
(user@10.10.0.2) Password for user@xmin.cloud.thinkum.space:
bash-5.1.16.pkg 100% 1490KB 177.5KB/s 00:08The wireguard interface on the local machine always shows up as disabled. Maybe this could be due to the odd placement of the endpoint in the perspective of the remote machine. The local machine can receive file data from the remote even so:
Code:
local # ifconfig wireguard
wireguard: flags=80c1<UP,RUNNING,NOARP,MULTICAST> metric 0 mtu 1420
options=80000<LINKSTATE>
inet 10.10.0.2 netmask 0xffffff00
groups: wg
nd6 options=149<PERFORMNUD,IFDISABLED,NO_RADR,NO_DAD>From the local, I can only ping to the remote's wireguard address. ssh does not work. traceroute does not work from either endpoint.
With file transfers eventually working out from the remote, at least there's that though