# wireguard over hotspot - ssh from remote works, pings from local but no ssh [solved]



## neogeo (Oct 16, 2022)

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 `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:

```
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 amd64
```

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

```
FreeBSD dist00.dist.cloud.thinkum.space 13.1-RELEASE FreeBSD 13.1-RELEASE ci/patch/releng/13.1/bootstrap-mk-e5184abbb RIPARIAN amd64
```

My wireguard config on the remote machine, via shell commands - the public interface on this remote machine has an address 147.182.245.210

```
# 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 sent
```

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:

```
# 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 sent
```

Ping from local:

```
# 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 ms
```

Ping from remote:

```
# 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 ms
```

From 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.

```
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
^C
```

Albeit, a file transfer _from the remote to the local_ actually works now, after a short pause ...

```
$ 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:08
```

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:


```
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


----------

