pivpn: [Support] Connection established but can't access local network or internet (followed FAQ)
In raising this issue, I confirm the following:
{please fill the checkboxes, e.g: [X]}
- I have read and understood the contributors guide.
- The issue I am reporting can be replicated.
- The issue I am reporting can be is directly related to the pivpn installer script.
- The issue I am reporting isn’t a duplicate (see FAQs, closed issues, and open issues).
Issue
I’ve been able to install pivpn to an fresh install of Raspberry Pi OS without any problems on the install. I have copied the config files to my Macbook and am able to connect, but do not seem to have any access to the server’s network or the internet once connected. If I switch to a cellular network through my phone’s hotspot I’m able to connect and access the network no problem. I’ve followed the FAQ and surprisingly am able to see packets from my macbook come into the raspberry pi but despite this am unable to access local resources or the internet through the connection.
Have you searched for similar issues and solutions?
yes, after several hours and several reinstalls I’m not able to remedy the problem.
Console output of pivpn debug
pi@raspberrypi:~ $ pivpn -d
::: Generating Debug Output
:::: PiVPN debug ::::
=============================================
:::: Latest commit ::::
commit b2b93de8dc30e5a6b3611c8f803a89eca0eb80db
Author: 4s3ti <4s3ti@protonmail.com>
Date: Fri Feb 5 00:23:04 2021 +0100
Update Dead and wrong links
README.md: Changed dead link to old issue template
CONTRIBUTING.md: Changed link poiting to blank issue leading users to
not see the issue template when opening issues
=============================================
:::: Installation settings ::::
PLAT=Raspbian
OSCN=buster
USING_UFW=0
IPv4dev=eth0
dhcpReserv=1
IPv4addr=192.168.77.109/24
IPv4gw=192.168.77.1
install_user=pi
install_home=/home/pi
VPN=wireguard
pivpnPORT=1194
pivpnDNS1=9.9.9.9
pivpnDNS2=149.112.112.112
pivpnHOST=REDACTED
INPUT_CHAIN_EDITED=0
FORWARD_CHAIN_EDITED=0
pivpnPROTO=udp
pivpnDEV=wg0
pivpnNET=10.6.0.0
subnetClass=24
ALLOWED_IPS="0.0.0.0/0, ::0/0"
UNATTUPG=1
INSTALLED_PACKAGES=()
=============================================
:::: Server configuration shown below ::::
[Interface]
PrivateKey = server_priv
Address = 10.6.0.1/24
ListenPort = 1194
### begin BPMBP ###
[Peer]
PublicKey = BPMBP_pub
PresharedKey = BPMBP_psk
AllowedIPs = 10.6.0.2/32
### end BPMBP ###
=============================================
:::: Client configuration shown below ::::
[Interface]
PrivateKey = BPMBP_priv
Address = 10.6.0.2/24
DNS = 9.9.9.9, 149.112.112.112
[Peer]
PublicKey = server_pub
PresharedKey = BPMBP_psk
Endpoint = REDACTED:1194
AllowedIPs = 0.0.0.0/0, ::0/0
=============================================
:::: Recursive list of files in ::::
:::: /etc/wireguard shown below ::::
/etc/wireguard:
configs
keys
wg0.conf
/etc/wireguard/configs:
BPMBP.conf
clients.txt
/etc/wireguard/keys:
BPMBP_priv
BPMBP_psk
BPMBP_pub
server_priv
server_pub
=============================================
:::: Self check ::::
:: [OK] IP forwarding is enabled
:: [OK] Iptables MASQUERADE rule set
:: [OK] WireGuard is running
:: [OK] WireGuard is enabled (it will automatically start on reboot)
:: [OK] WireGuard is listening on port 1194/udp
=============================================
:::: Having trouble connecting? Take a look at the FAQ:
:::: https://github.com/pivpn/pivpn/wiki/FAQ
=============================================
:::: WARNING: This script should have automatically masked sensitive ::::
:::: information, however, still make sure that PrivateKey, PublicKey ::::
:::: and PresharedKey are masked before reporting an issue. An example key ::::
:::: that you should NOT see in this log looks like this: ::::
:::: YIAoJVsdIeyvXfGGDDadHh6AxsMRymZTnnzZoAb9cxRe ::::
=============================================
:::: Debug complete ::::
:::
::: Debug output completed above.
::: Copy saved to /tmp/debug.log
:::
Have you taken any steps towards solving your issue?
yes, I've followed the FAQ and a few other issues that seemed to have some relevance. I've reinstalled several times.
I’ve run sudo systemctl restart wg-quick@wg0 and then lsmod | grep wireguard
pi@raspberrypi:~ $ lsmod | grep wireguard
wireguard 73728 0
curve25519_neon 28672 1 wireguard
libcurve25519_generic 24576 2 curve25519_neon,wireguard
libchacha20poly1305 16384 1 wireguard
ip6_udp_tunnel 16384 1 wireguard
udp_tunnel 24576 1 wireguard
libblake2s 16384 1 wireguard
ipv6 495616 29 wireguard
Ran cat /etc/pivpn/wireguard/setupVars.conf and compared my network interface, the ipv4addr, apv4gw, pivpnpronto, pivpnport and pivpnhost, which all seem to be in order
pi@raspberrypi:~ $ cat /etc/pivpn/wireguard/setupVars.conf
PLAT=Raspbian
OSCN=buster
USING_UFW=0
IPv4dev=eth0
dhcpReserv=1
IPv4addr=192.168.77.109/24
IPv4gw=192.168.77.1
install_user=pi
install_home=/home/pi
VPN=wireguard
pivpnPORT=1194
pivpnDNS1=9.9.9.9
pivpnDNS2=149.112.112.112
pivpnHOST=REDACTED
INPUT_CHAIN_EDITED=0
FORWARD_CHAIN_EDITED=0
pivpnPROTO=udp
pivpnDEV=wg0
pivpnNET=10.6.0.0
subnetClass=24
ALLOWED_IPS="0.0.0.0/0, ::0/0"
UNATTUPG=1
INSTALLED_PACKAGES=()
Checked the packet capture using the command tcpdump -n -i eth0 port 1194 -v as superuser which shows:
pi@raspberrypi:~ $ sudo -s
root@raspberrypi:/home/pi# tcpdump -n -i eth0 port 1194 -v
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
01:50:14.089029 IP (tos 0x68, ttl 57, id 44453, offset 0, flags [none], proto UDP (17), length 176)
REDACTED.62834 > 192.168.77.109.1194: UDP, length 148
01:50:14.093091 IP (tos 0x88, ttl 64, id 19400, offset 0, flags [none], proto UDP (17), length 120)
192.168.77.109.1194 > REDACTED.62834: UDP, length 92
01:50:29.371252 IP (tos 0x0, ttl 57, id 34501, offset 0, flags [none], proto UDP (17), length 176)
REDACTED.62834 > 192.168.77.109.1194: UDP, length 148
01:50:29.375036 IP (tos 0x88, ttl 64, id 20529, offset 0, flags [none], proto UDP (17), length 120)
192.168.77.109.1194 > REDACTED.62834: UDP, length 92
01:50:44.846438 IP (tos 0x0, ttl 57, id 13962, offset 0, flags [none], proto UDP (17), length 176)
REDACTED.62834 > 192.168.77.109.1194: UDP, length 148
01:50:44.850171 IP (tos 0x88, ttl 64, id 20767, offset 0, flags [none], proto UDP (17), length 120)
192.168.77.109.1194 > REDACTED.62834: UDP, length 92
At that point the WireGuard GUI client indicates that the interface is “active”, with a green circle
I’ve taken a look at IP Tables, but to be honest am not sure what to make of it except it looks the same as the one in the issue I was referencing and that didn’t end up being their issue. Output of sudo iptales -t nat -S
pi@raspberrypi:~ $ sudo iptables -t nat -S
-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P POSTROUTING ACCEPT
-P OUTPUT ACCEPT
-A POSTROUTING -s 10.6.0.0/24 -o eth0 -m comment --comment wireguard-nat-rule -j MASQUERADE
I also tried looking at the firewall using sudo ufw status verbose but get “ufw: command not found” which I suppose is a result of me using the Raspberry Pi Operating system and not Ubuntu.
That’s about as far as I’ve gotten. I tried pinging my pi’s network from my macbook but didn’t get a response.
Any help appreciated.
Thanks!
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 33 (7 by maintainers)
No, not a PiHole
Totally fair, and no offense taken (moreover I’m super grateful for your help!). The only thing I can think of that I haven’t shared is that I work at a province wide hospital network as clinical staff. The organization has a dedicated IT department with a network that spans across the province connecting all the sites together. I typically connect via WiFi using an authentication mechanism that I don’t understand (no passphrase, I use my corporate credentials). There is a VPN solution to connect from home using forticlient which allows for RDP and citrix access to the corporate network. My occasional interactions with IT have only ever been with product support staff and they naturally are able to support the products but have very little familiarity with the underlying infrastructure. I assumed the network used IPv4 but I neither know whether use of IPv6 on the network is important nor what tests would be important.
As far as the routing tables go, the only thing I can figure out is that once connected to the wifi it gets shoved full of references to every other machine on the subnet, and someone decided to make the subnets huge. I’ve spent hours trying to understand how routing tables work, I have flushed the routing table dozens of times, tried adding routes and removing routes and it makes no difference, the table is always huge when connected to the work network and I’m not able to get my packets moving. After I finish my experiments I disconnect and reconnect and the table is back to however it was before.
In terms of setup I don’t think my Mac has anything that would make a difference. I use a vanilla install of OSX Big Sur with the wireguard client for Mac version App version: 1.0.12 (22) Go backend version: 0.0.20201119. I use an adblocker in chrome but my understanding was that those work at the application level. Citrix is open occasionally, and Viscoscity is still installed from when i was using OpenVPN.
I did try this, and it didn’t change things. Still unable to connect to internet and can’t ping 10.6.0.1. Was worth a shot.
Sure thing, I’m back at work tomorrow.
It has dawned on me that if this is a routing table problem I’m not going to be able to fix that on my phone in order to connect. I’ve reinstalled PiVPN tonight with OpenVPN and will give that a shot tomorrow. OpenVPN was previously working when I had it setup on my openWRT router so that hopefully will get things going again. I’ll post back with how it goes.
TL;DR but don’t see a reason why not … just avoids weird conflicts.
@jimprince The issue is clearly routing and yours is a mess. I am not debugging that.
Addressin the[Interface]section means a single IP address with its netmask, whileAllowedIPsin the[Peer]section specifies a group of ip addresses that the peer is allowed to be inside the tunnel, /32 is a single IP address.