Pivpn no internet - raspberry-pi

This question might seem duplicate but I've tried all other solutions which are years old so please help.
I setup Pivpn on my Raspberry Pi but cannot access internet via VPN.
Running ping 1.1.1.1 -I tun0 gives 100% packet loss and no response. From eth0 it works. Even ping 127.0.0.1 -I tun0 doesn't work.
Below is my log of pivpn -d it doesn't show any error.
::: Generating Debug Output
:::: [4mPiVPN debug[0m ::::
=============================================
:::: [4mLatest commit[0m ::::
Branch: master
Commit: 027f257931d1f169e254def5d1552d55810fefda
Author: 4s3ti
Date: Thu Aug 5 15:12:33 2021 +0200
Summary: Latest Changes update.
=============================================
:::: [4mInstallation settings[0m ::::
PLAT=Raspbian
OSCN=stretch
USING_UFW=0
IPv4dev=eth0
dhcpReserv=1
IPv4addr=10.10.70.10/24
IPv4gw=10.10.70.254
install_user=pi
install_home=/home/pi
VPN=openvpn
pivpnPROTO=udp
pivpnPORT=50552
pivpnDNS1=8.8.8.8
pivpnDNS2=8.8.4.4
pivpnSEARCHDOMAIN=
pivpnHOST=REDACTED
TWO_POINT_FOUR=1
pivpnENCRYPT=256
USE_PREDEFINED_DH_PARAM=0
INPUT_CHAIN_EDITED=0
FORWARD_CHAIN_EDITED=0
pivpnDEV=tun0
pivpnNET=10.8.0.0
subnetClass=24
ALLOWED_IPS=""
UNATTUPG=0
INSTALLED_PACKAGES=(grepcidr expect)
=============================================
:::: [4mServer configuration shown below[0m ::::
dev tun
proto udp
port 50552
ca /etc/openvpn/easy-rsa/pki/ca.crt
cert /etc/openvpn/easy-rsa/pki/issued/ANY_1c949ee6-91f4-4cca-b472-e7d82dae1b44.crt
key /etc/openvpn/easy-rsa/pki/private/ANY_1c949ee6-91f4-4cca-b472-e7d82dae1b44.key
dh none
ecdh-curve prime256v1
topology subnet
server 10.3.0.0 255.255.255.0
# Set your primary domain name server address for clients
push "dhcp-option DNS 1.1.1.1"
#push "dhcp-option DNS 8.8.8.8"
# Prevent DNS leaks on Windows
push "block-outside-dns"
# Override the Client default gateway by using 0.0.0.0/1 and
# 128.0.0.0/1 rather than 0.0.0.0/0. This has the benefit of
# overriding but not wiping out the original default gateway.
push "redirect-gateway def1"
push "route 192.168.15.1 255.255.255.0"
client-to-client
client-config-dir /etc/openvpn/ccd
keepalive 15 120
remote-cert-tls client
tls-version-min 1.2
tls-crypt /etc/openvpn/easy-rsa/pki/ta.key
cipher AES-256-CBC
auth SHA256
user openvpn
group openvpn
persist-key
persist-tun
crl-verify /etc/openvpn/crl.pem
status /var/log/openvpn-status.log 20
status-version 3
syslog
verb 3
#DuplicateCNs allow access control on a less-granular, per user basis.
#Remove # if you will manage access by user instead of device.
#duplicate-cn
# Generated for use by PiVPN.io
tun-mtu 1400
mssfix 1360
=============================================
:::: [4mClient template file shown below[0m ::::
client
dev tun
proto udp
remote REDACTED 50552
resolv-retry infinite
nobind
remote-cert-tls server
tls-version-min 1.2
verify-x509-name ANY_1c949ee6-91f4-4cca-b472-e7d82dae1b44 name
cipher AES-256-CBC
auth SHA256
auth-nocache
verb 3
=============================================
:::: [4mRecursive list of files in[0m ::::
::: [4m/etc/openvpn/easy-rsa/pki shows below[0m :::
/etc/openvpn/easy-rsa/pki/:
Default.txt
ca.crt
crl.pem
ecparams
index.txt
index.txt.attr
index.txt.attr.old
index.txt.old
issued
openssl-easyrsa.cnf
private
renewed
revoked
safessl-easyrsa.cnf
serial
serial.old
ta.key
/etc/openvpn/easy-rsa/pki/ecparams:
prime256v1.pem
/etc/openvpn/easy-rsa/pki/issued:
ANY_1c949ee6-91f4-4cca-b472-e7d82dae1b44.crt
/etc/openvpn/easy-rsa/pki/private:
ANY_1c949ee6-91f4-4cca-b472-e7d82dae1b44.key
ca.key
/etc/openvpn/easy-rsa/pki/renewed:
private_by_serial
reqs_by_serial
/etc/openvpn/easy-rsa/pki/renewed/private_by_serial:
/etc/openvpn/easy-rsa/pki/renewed/reqs_by_serial:
/etc/openvpn/easy-rsa/pki/revoked:
private_by_serial
reqs_by_serial
/etc/openvpn/easy-rsa/pki/revoked/private_by_serial:
/etc/openvpn/easy-rsa/pki/revoked/reqs_by_serial:
=============================================
:::: [4mSelf check[0m ::::
:: [OK] IP forwarding is enabled
:: [OK] Iptables MASQUERADE rule set
:: [OK] OpenVPN is running
:: [OK] OpenVPN is enabled (it will automatically start on reboot)
:: [OK] OpenVPN is listening on port 50552/udp
=============================================
:::: Having trouble connecting? Take a look at the FAQ:
:::: [1mhttps://docs.pivpn.io/faq[0m
=============================================
:::: [4mSnippet of the server log[0m ::::
Aug 21 11:16:40 ANY ovpn-server[488]: ECDH curve prime256v1 added
Aug 21 11:16:40 ANY ovpn-server[488]: Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Aug 21 11:16:40 ANY ovpn-server[488]: Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Aug 21 11:16:40 ANY ovpn-server[488]: Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Aug 21 11:16:40 ANY ovpn-server[488]: Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Aug 21 11:16:40 ANY ovpn-server[488]: WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1400)
Aug 21 11:16:40 ANY ovpn-server[488]: TUN/TAP device tun0 opened
Aug 21 11:16:40 ANY ovpn-server[488]: TUN/TAP TX queue length set to 100
Aug 21 11:16:40 ANY ovpn-server[488]: do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Aug 21 11:16:40 ANY ovpn-server[488]: /sbin/ip link set dev tun0 up mtu 1400
Aug 21 11:16:40 ANY ovpn-server[488]: /sbin/ip addr add dev tun0 10.3.0.1/24 broadcast 10.3.0.255
Aug 21 11:16:40 ANY ovpn-server[488]: Could not determine IPv4/IPv6 protocol. Using AF_INET
Aug 21 11:16:40 ANY ovpn-server[488]: Socket Buffers: R=[163840->163840] S=[163840->163840]
Aug 21 11:16:40 ANY ovpn-server[488]: UDPv4 link local (bound): [AF_INET][undef]:50552
Aug 21 11:16:40 ANY ovpn-server[488]: UDPv4 link remote: [AF_UNSPEC]
Aug 21 11:16:40 ANY ovpn-server[488]: GID set to openvpn
Aug 21 11:16:40 ANY ovpn-server[488]: UID set to openvpn
Aug 21 11:16:40 ANY ovpn-server[488]: MULTI: multi_init called, r=256 v=256
Aug 21 11:16:40 ANY ovpn-server[488]: IFCONFIG POOL: base=10.3.0.2 size=252, ipv6=0
Aug 21 11:16:40 ANY ovpn-server[488]: Initialization Sequence Completed
=============================================
:::: [4mDebug complete[0m ::::
:::
::: Debug output completed above.
::: Copy saved to /tmp/debug.log
:::
Running cat /proc/sys/net/ipv4/ip_forward gives 1 so forwarding is enabled.
I've ran the command sudo iptables -t nat -A POSTROUTING -s 10.3.0.0/24 -o eth0 -j MASQUERADE still doesn't work.
Please note that I've changed ip from 10.8.0.0 to 10.3.0.0 still doesn't work with both.
My openvpn version is OpenVPN 2.4.0

Well everything looks good. I suggest you reinstall pivpn from the official website here
Also, while installation select public dns and enter any public dns, you seem to be using your ip.
After reinstall and reboot, run the command sudo iptables -t nat -A POSTROUTING -s 10.3.0.0/24 -o eth0 -j MASQUERADE
Also, most importantly, using ping 1.1.1.1 -I tun0 won't work even if the VPN works so stop using it and use an actual connection.
You might want to create a statup script that runs the command sudo iptables -t nat -A POSTROUTING -s 10.3.0.0/24 -o eth0 -j MASQUERADE

Related

Cannot access apache server from foreign ip address

I have a site running on my computer using Apache 2.4 which I can easily access by using my local ipv4 address and respective port 80. The port 80 is bound to port 22*** using portmap.io and is configured with OpenVpn/tcp on my computer.I have allowed access to Apache HTTP server and Apache Server Monitor through the firewall.I have also increased keepAlive timeout in apche server to 600s, max connections.i have Listen 80 and LISTEN 22*** and ServerName as http://awm-22***.portmap.host:22*** in my httpd.conf file.You can look into for more options here.Apache handler configuration
I am using PHP as backend language.
Since the port 80 is bound to port 22470, whenever I try access my site from another device(which also uses the same wifi network as the computer running the server) using the local ipv4 address of my computer(which is running the server) and port 80 i.e
192.168..:80, it automatically redirects the browser to 192.168..:22*** and I can access my site with no difficuty. Access log in apcache server:
192.168.**.** - - [15/Dec/2022:10:08:02 +0530] "GET /abc%20xyz%20klm/ HTTP/1.1" 200 12049
192.168.**.** - - [15/Dec/2022:10:08:02 +0530] "GET /SPR/b/get_captcha.php?rand=29842778 HTTP/1.1" 200 4057
But when I try access the same site from another device(which also uses the same wifi network as the computer running the server) using the ipv4 address provided by OpenVpn to my computer(which is running the server):10.9..* and port 80 i.e 10.9..*:80, it shows TOOK TOO LONG TO RESPPOND error on the browser.But the browser's header has the following:
http://10.9.**.**4:22470/abc%20xyz%20klm/
Then why is it not loading the page. No log in apache access log file.
When I try access the same site from another device(which also uses the same wifi network as the computer running the server) using the url provided to me by portmap.io i.e: http://awm-22***.portmap.host:22***/,
The server takes too long to respond error is shown in the browser.
Access log in apcache server:
10.9.0.1 - - [15/Dec/2022:10:21:33 +0530] "GET / HTTP/1.0" 302 -
10.9.0.1 - - [15/Dec/2022:10:21:34 +0530] "GET /abc%20xyz%20klm HTTP/1.0" 301 256
OpenVpn Log:
Thu Dec 15 10:32:30 2022 SIGHUP[hard,] received, process restarting
Thu Dec 15 10:32:30 2022 --cipher is not set. Previous OpenVPN version defaulted to BF-CBC as fallback when cipher negotiation failed in this case. If you need this fallback please add '--data-ciphers-fallback BF-CBC' to your configuration and/or add BF-CBC to --data-ciphers.
Thu Dec 15 10:32:30 2022 OpenVPN 2.5.7 [git:release/2.5/3d792ae9557b959e] Windows-MSVC [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Oct 28 2022
Thu Dec 15 10:32:30 2022 Windows version 10.0 (Windows 10 or greater) 64bit
Thu Dec 15 10:32:30 2022 library versions: OpenSSL 1.1.1o 3 May 2022, LZO 2.10
Thu Dec 15 10:32:35 2022 TCP/UDP: Preserving recently used remote address: [AF_INET]193.161.193.99:1194
Thu Dec 15 10:32:35 2022 Attempting to establish TCP connection with [AF_INET]193.161.193.99:1194 [nonblock]
Thu Dec 15 10:32:35 2022 TCP connection established with [AF_INET]193.161.193.99:1194
Thu Dec 15 10:32:35 2022 TCP_CLIENT link local: (not bound)
Thu Dec 15 10:32:35 2022 TCP_CLIENT link remote: [AF_INET]193.161.193.99:1194
Thu Dec 15 10:32:41 2022 [193.161.193.99] Peer Connection Initiated with [AF_INET]193.161.193.99:1194
Thu Dec 15 10:32:42 2022 WARNING: INSECURE cipher (BF-CBC) with block size less than 128 bit (64 bit). This allows attacks like SWEET32. Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC). Support for these insecure ciphers will be removed in OpenVPN 2.7.
Thu Dec 15 10:32:42 2022 WARNING: INSECURE cipher (BF-CBC) with block size less than 128 bit (64 bit). This allows attacks like SWEET32. Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC). Support for these insecure ciphers will be removed in OpenVPN 2.7.
Thu Dec 15 10:32:42 2022 WARNING: cipher with small block size in use, reducing reneg-bytes to 64MB to mitigate SWEET32 attacks.
Thu Dec 15 10:32:42 2022 open_tun
Thu Dec 15 10:32:42 2022 tap-windows6 device [OpenVPN TAP-Windows6] opened
Thu Dec 15 10:32:42 2022 Notified TAP-Windows driver to set a DHCP IP/netmask of 10.9.**.234/255.255.255.252 on interface {798F492A-574C-4BC6-87C5-A62C6D058EC1} [DHCP-serv: 10.9.**.233, lease-time: 31536000]
Thu Dec 15 10:32:42 2022 Successful ARP Flush on interface [12] {798F492A-574C-4BC6-87C5-A62C6D058EC1}
Thu Dec 15 10:32:42 2022 IPv4 MTU set to 1500 on interface 12 using service
These are my firewall rules:
Inbound rules
Inbound rule for Port 80 Outbound rules
Firewall monitoring Domain and Private Profiles
Firewall monitoring Public Profile
What is causing the problem? Any solution will be of great help. Thanks in advance.

PiVpn does not route traffic to LAN

I am using PiVPN on my Raspberry Pi.
It connects correctly but it does not route traffic to my LAN.
My topology is the following:
LAN: 192.168.1.0/24
VPN network: 10.192.125.0/24
Laptop connected to mobile (192.168.43.1) via tethering
Laptop attempting to connect to VPN
server.conf:
dev tun
proto udp
port 1194
ca /etc/openvpn/easy-rsa/pki/ca.crt
cert /etc/openvpn/easy-rsa/pki/issued/raspberrypi_f55e286b-94c2-4b4c-b43b-a5e53bf7e7d5.crt
key /etc/openvpn/easy-rsa/pki/private/raspberrypi_f55e286b-94c2-4b4c-b43b-a5e53bf7e7d5.key
dh /etc/openvpn/easy-rsa/pki/dh2048.pem
topology subnet
server 10.192.125.0 255.255.255.0
# Set your primary domain name server address for clients
push "dhcp-option DNS 1.1.1.1"
push "dhcp-option DNS 1.0.0.1"
# Prevent DNS leaks on Windows
push "block-outside-dns"
# Override the Client default gateway by using 0.0.0.0/1 and
# 128.0.0.0/1 rather than 0.0.0.0/0. This has the benefit of
# overriding but not wiping out the original default gateway.
push "redirect-gateway def1"
# push "route 192.168.1.0 255.255.255.0"
client-to-client
client-config-dir /etc/openvpn/ccd
keepalive 15 120
remote-cert-tls client
tls-version-min 1.2
tls-auth /etc/openvpn/easy-rsa/pki/ta.key 0
cipher AES-256-CBC
auth SHA256
user openvpn
group openvpn
persist-key
persist-tun
crl-verify /etc/openvpn/crl.pem
status /var/log/openvpn-status.log 20
status-version 3
syslog
verb 4
mssfix 1350
This is my OVPN client conf:
client
dev tun
proto udp
remote <my_host> 1194
resolv-retry infinite
nobind
key-direction 1
remote-cert-tls server
tls-version-min 1.2
verify-x509-name raspberrypi_f55e286b-94c2-4b4c-b43b-a5e53bf7e7d5 name
cipher AES-256-CBC
auth SHA256
auth-nocache
verb 3
<ca>
...
</ca>
<cert>
...
</cert>
<key>
...
</key>
<tls-auth>
...
</tls-auth>
After connecting, I have the following routing table on the client:
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.192.125.1 128.0.0.0 UG 0 0 0 tun0
0.0.0.0 192.168.43.1 0.0.0.0 UG 600 0 0 wlp1s0
10.192.125.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
<PUBLIC_IP> 192.168.43.1 255.255.255.255 UGH 0 0 0 wlp1s0
128.0.0.0 10.192.125.1 128.0.0.0 UG 0 0 0 tun0
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 wlp1s0
172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0
172.23.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker_gwbridge
192.168.43.0 0.0.0.0 255.255.255.0 U 600 0 0 wlp1s0
Here I also tried explicitly pushing a route to 192.168.1.0, with no noticeable change.
On the OpenVPN server I have the following IPTABLES configuration:
Chain FORWARD (policy DROP)
target prot opt source destination
DOCKER-USER all -- anywhere anywhere
DOCKER-INGRESS all -- anywhere anywhere
DOCKER-ISOLATION-STAGE-1 all -- anywhere anywhere
ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED
DOCKER all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere 10.192.125.0/24 ctstate RELATED,ESTABLISHED /* openvpn-forward-rule */
ACCEPT all -- 10.192.125.0/24 anywhere /* openvpn-forward-rule */
ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED
DOCKER all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
DROP all -- anywhere anywhere
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
MASQUERADE all -- 172.17.0.0/16 anywhere
MASQUERADE all -- 10.192.125.0/24 anywhere /* openvpn-nat-rule */
MASQUERADE all -- anywhere anywhere ADDRTYPE match src-type LOCAL
MASQUERADE all -- 172.19.0.0/16 anywhere
I enabled forwarding on the kernel by adding net.ipv4.ip_forward=1 on sysctl.conf.
When tracerouting a host from the LAN, I see it uses the OpenVPN server as the gateway.
# traceroute 192.168.1.101
traceroute to 192.168.1.101 (192.168.1.101), 30 hops max, 60 byte packets
1 10.192.125.1 (10.192.125.1) 163.487 ms 163.746 ms 163.754 ms
2 * * *
...
These are the logs on the client when connecting:
Mon Nov 7 08:19:19 2022 OpenVPN 2.4.7 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Mar 22 2022
Mon Nov 7 08:19:19 2022 library versions: OpenSSL 1.1.1f 31 Mar 2020, LZO 2.10
Enter Private Key Password: ***********************
Mon Nov 7 08:19:23 2022 Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
Mon Nov 7 08:19:23 2022 Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
Mon Nov 7 08:19:24 2022 TCP/UDP: Preserving recently used remote address: [AF_INET]<PUBLIC_IP>:1194
Mon Nov 7 08:19:24 2022 Socket Buffers: R=[212992->212992] S=[212992->212992]
Mon Nov 7 08:19:24 2022 UDP link local: (not bound)
Mon Nov 7 08:19:24 2022 UDP link remote: [AF_INET]<PUBLIC_IP>:1194
Mon Nov 7 08:19:24 2022 TLS: Initial packet from [AF_INET]<PUBLIC_IP>:1194, sid=68ddb126 123bae54
Mon Nov 7 08:19:24 2022 VERIFY OK: depth=1, CN=Easy-RSA CA
Mon Nov 7 08:19:24 2022 VERIFY KU OK
Mon Nov 7 08:19:24 2022 Validating certificate extended key usage
Mon Nov 7 08:19:24 2022 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Mon Nov 7 08:19:24 2022 VERIFY EKU OK
Mon Nov 7 08:19:24 2022 VERIFY X509NAME OK: CN=raspberrypi_f55e286b-94c2-4b4c-b43b-a5e53bf7e7d5
Mon Nov 7 08:19:24 2022 VERIFY OK: depth=0, CN=raspberrypi_f55e286b-94c2-4b4c-b43b-a5e53bf7e7d5
Mon Nov 7 08:19:24 2022 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, 2048 bit RSA
Mon Nov 7 08:19:24 2022 [raspberrypi_f55e286b-94c2-4b4c-b43b-a5e53bf7e7d5] Peer Connection Initiated with [AF_INET]<PUBLIC_IP>:1194
Mon Nov 7 08:19:25 2022 SENT CONTROL [raspberrypi_f55e286b-94c2-4b4c-b43b-a5e53bf7e7d5]: 'PUSH_REQUEST' (status=1)
Mon Nov 7 08:19:25 2022 PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 1.1.1.1,dhcp-option DNS 1.0.0.1,block-outside-dns,redirect-gateway def1,route 192.168.1.0 255.255.255.0,route-gateway 10.192.125.1,topology subnet,ping 15,ping-restart 120,ifconfig 10.192.125.3 255.255.255.0,peer-id 0,cipher AES-256-GCM'
Mon Nov 7 08:19:25 2022 Options error: Unrecognized option or missing or extra parameter(s) in [PUSH-OPTIONS]:3: block-outside-dns (2.4.7)
Mon Nov 7 08:19:25 2022 OPTIONS IMPORT: timers and/or timeouts modified
Mon Nov 7 08:19:25 2022 OPTIONS IMPORT: --ifconfig/up options modified
Mon Nov 7 08:19:25 2022 OPTIONS IMPORT: route options modified
Mon Nov 7 08:19:25 2022 OPTIONS IMPORT: route-related options modified
Mon Nov 7 08:19:25 2022 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Mon Nov 7 08:19:25 2022 OPTIONS IMPORT: peer-id set
Mon Nov 7 08:19:25 2022 OPTIONS IMPORT: adjusting link_mtu to 1624
Mon Nov 7 08:19:25 2022 OPTIONS IMPORT: data channel crypto options modified
Mon Nov 7 08:19:25 2022 Data Channel: using negotiated cipher 'AES-256-GCM'
Mon Nov 7 08:19:25 2022 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Mon Nov 7 08:19:25 2022 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Mon Nov 7 08:19:25 2022 ROUTE_GATEWAY 192.168.1.254/255.255.255.0 IFACE=wlp1s0 HWADDR=a4:97:b1:8e:37:af
Mon Nov 7 08:19:25 2022 TUN/TAP device tun0 opened
Mon Nov 7 08:19:25 2022 TUN/TAP TX queue length set to 100
Mon Nov 7 08:19:25 2022 /sbin/ip link set dev tun0 up mtu 1500
Mon Nov 7 08:19:25 2022 /sbin/ip addr add dev tun0 10.192.125.3/24 broadcast 10.192.125.255
Mon Nov 7 08:19:25 2022 /sbin/ip route add <PUBLIC_IP>/32 via 192.168.1.254
Mon Nov 7 08:19:25 2022 /sbin/ip route add 0.0.0.0/1 via 10.192.125.1
Mon Nov 7 08:19:25 2022 /sbin/ip route add 128.0.0.0/1 via 10.192.125.1
Mon Nov 7 08:19:25 2022 /sbin/ip route add 192.168.1.0/24 via 10.192.125.1
Mon Nov 7 08:19:25 2022 Initialization Sequence Completed
Finally, PiVPN seems to be happy about the configuration:
root#raspberrypi:~# cat /tmp/debug.log
:::: PiVPN debug ::::
=============================================
:::: Latest commit ::::
Branch: master
Commit: f8cb945af15a1ca0cf063475c6e1557c6e8da06c
Author: 4s3ti
Date: Fri Jun 10 16:10:57 2022 +0200
Summary: Merge branch 'test'
=============================================
:::: Installation settings ::::
PLAT=Debian
OSCN=bullseye
USING_UFW=0
pivpnforceipv6route=1
IPv4dev=wlan1
dhcpReserv=1
IPv4addr=192.168.1.223/24
IPv4gw=192.168.1.254
install_user=pi
install_home=/home/pi
VPN=openvpn
pivpnPROTO=udp
pivpnPORT=1194
pivpnDNS1=1.1.1.1
pivpnDNS2=1.0.0.1
pivpnSEARCHDOMAIN=
pivpnHOST=REDACTED
TWO_POINT_FOUR=0
pivpnENCRYPT=2048
USE_PREDEFINED_DH_PARAM=1
INPUT_CHAIN_EDITED=0
FORWARD_CHAIN_EDITED=1
INPUT_CHAIN_EDITEDv6=
FORWARD_CHAIN_EDITEDv6=
pivpnDEV=tun0
pivpnNET=10.192.125.0
subnetClass=24
pivpnenableipv6=0
ALLOWED_IPS=""
UNATTUPG=1
INSTALLED_PACKAGES=(dnsutils grepcidr bsdmainutils iptables-persistent openvpn expect unattended-upgrades)
HELP_SHOWN=1
=============================================
:::: Server configuration shown below ::::
dev tun
proto udp
port 1194
ca /etc/openvpn/easy-rsa/pki/ca.crt
cert /etc/openvpn/easy-rsa/pki/issued/raspberrypi_f55e286b-94c2-4b4c-b43b-a5e53bf7e7d5.crt
key /etc/openvpn/easy-rsa/pki/private/raspberrypi_f55e286b-94c2-4b4c-b43b-a5e53bf7e7d5.key
dh /etc/openvpn/easy-rsa/pki/dh2048.pem
topology subnet
server 10.192.125.0 255.255.255.0
# Set your primary domain name server address for clients
push "dhcp-option DNS 1.1.1.1"
push "dhcp-option DNS 1.0.0.1"
# Prevent DNS leaks on Windows
push "block-outside-dns"
# Override the Client default gateway by using 0.0.0.0/1 and
# 128.0.0.0/1 rather than 0.0.0.0/0. This has the benefit of
# overriding but not wiping out the original default gateway.
push "redirect-gateway def1"
# push "route 192.168.1.0 255.255.255.0"
client-to-client
client-config-dir /etc/openvpn/ccd
keepalive 15 120
remote-cert-tls client
tls-version-min 1.2
tls-auth /etc/openvpn/easy-rsa/pki/ta.key 0
cipher AES-256-CBC
auth SHA256
user openvpn
group openvpn
persist-key
persist-tun
crl-verify /etc/openvpn/crl.pem
status /var/log/openvpn-status.log 20
status-version 3
syslog
verb 4
mssfix 1350
#DuplicateCNs allow access control on a less-granular, per user basis.
#Remove # if you will manage access by user instead of device.
#duplicate-cn
# Generated for use by PiVPN.io
=============================================
:::: Client template file shown below ::::
client
dev tun
proto udp
remote REDACTED 1194
resolv-retry infinite
nobind
key-direction 1
remote-cert-tls server
tls-version-min 1.2
verify-x509-name raspberrypi_f55e286b-94c2-4b4c-b43b-a5e53bf7e7d5 name
cipher AES-256-CBC
auth SHA256
auth-nocache
verb 3
=============================================
:::: Recursive list of files in ::::
::: /etc/openvpn/easy-rsa/pki shows below :::
/etc/openvpn/easy-rsa/pki/:
Default.txt
MirkoSmartphone.ovpn
Motog8Mirko3.ovpn
ca.crt
crl.pem
dh2048.pem
index.txt
index.txt.attr
index.txt.attr.old
index.txt.old
issued
openssl-easyrsa.cnf
private
revoked
safessl-easyrsa.cnf
serial
serial.old
ta.key
vars
vars.example
/etc/openvpn/easy-rsa/pki/issued:
MirkoSmartphone.crt
Motog8Mirko3.crt
motog8mirko.crt
raspberrypi_f55e286b-94c2-4b4c-b43b-a5e53bf7e7d5.crt
/etc/openvpn/easy-rsa/pki/private:
MirkoSmartphone.key
Motog8Mirko3.key
ca.key
motog8mirko.key
raspberrypi_f55e286b-94c2-4b4c-b43b-a5e53bf7e7d5.key
/etc/openvpn/easy-rsa/pki/revoked:
private_by_serial
reqs_by_serial
/etc/openvpn/easy-rsa/pki/revoked/private_by_serial:
/etc/openvpn/easy-rsa/pki/revoked/reqs_by_serial:
=============================================
:::: Self check ::::
:: [OK] IP forwarding is enabled
:: [OK] Iptables MASQUERADE rule set
:: [OK] Iptables FORWARD rule set
:: [OK] OpenVPN is running
:: [OK] OpenVPN is enabled (it will automatically start on reboot)
:: [OK] OpenVPN is listening on port 1194/udp
=============================================
:::: Having trouble connecting? Take a look at the FAQ:
:::: https://docs.pivpn.io/faq
=============================================
:::: Snippet of the server log ::::
Nov 7 08:49:16 raspberrypi ovpn-server[142996]: REDACTED:33665 peer info: IV_SSO=webauth,openurl
Nov 7 08:49:16 raspberrypi ovpn-server[142996]: REDACTED:33665 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, 2048 bit RSA
Nov 7 08:49:16 raspberrypi ovpn-server[142996]: REDACTED:33665 [Motog8Mirko3] Peer Connection Initiated with [AF_INET]REDACTED:33665
Nov 7 08:49:16 raspberrypi ovpn-server[142996]: Motog8Mirko3/REDACTED:33665 MULTI_sva: pool returned IPv4=10.192.125.2, IPv6=(Not enabled)
Nov 7 08:49:16 raspberrypi ovpn-server[142996]: Motog8Mirko3/REDACTED:33665 OPTIONS IMPORT: reading client specific options from: /etc/openvpn/ccd/Motog8Mirko3
Nov 7 08:49:16 raspberrypi ovpn-server[142996]: Motog8Mirko3/REDACTED:33665 MULTI: Learn: 10.192.125.3 -> Motog8Mirko3/REDACTED:33665
Nov 7 08:49:16 raspberrypi ovpn-server[142996]: Motog8Mirko3/REDACTED:33665 MULTI: primary virtual IP for Motog8Mirko3/REDACTED:33665: 10.192.125.3
Nov 7 08:49:16 raspberrypi ovpn-server[142996]: Motog8Mirko3/REDACTED:33665 Data Channel: using negotiated cipher 'AES-256-GCM'
Nov 7 08:49:16 raspberrypi ovpn-server[142996]: Motog8Mirko3/REDACTED:33665 Data Channel MTU parms [ L:1549 D:1350 EF:49 EB:406 ET:0 EL:3 ]
Nov 7 08:49:16 raspberrypi ovpn-server[142996]: Motog8Mirko3/REDACTED:33665 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Nov 7 08:49:16 raspberrypi ovpn-server[142996]: Motog8Mirko3/REDACTED:33665 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Nov 7 08:49:16 raspberrypi ovpn-server[142996]: Motog8Mirko3/REDACTED:33665 SENT CONTROL [Motog8Mirko3]: 'PUSH_REPLY,dhcp-option DNS 1.1.1.1,dhcp-option DNS 1.0.0.1,block-outside-dns,redirect-gateway def1,route-gateway 10.192.125.1,topology subnet,ping 15,ping-restart 120,ifconfig 10.192.125.3 255.255.255.0,peer-id 0,cipher AES-256-GCM' (status=1)
Nov 7 08:49:16 raspberrypi ovpn-server[142996]: Motog8Mirko3/REDACTED:33665 PUSH: Received control message: 'PUSH_REQUEST'
Nov 7 08:49:16 raspberrypi ovpn-server[142996]: Motog8Mirko3/REDACTED:33665 PID_ERR replay-window backtrack occurred [1] [SSL-0] [0_0] 0:3 0:2 t=1667807356[0] r=[0,64,15,1,1] sl=[61,3,64,528]
Nov 7 08:49:17 raspberrypi ovpn-server[142996]: Motog8Mirko3/REDACTED:33665 MULTI: bad source address from client [10.88.113.212], packet dropped
Nov 7 08:49:17 raspberrypi ovpn-server[142996]: Motog8Mirko3/REDACTED:33665 MULTI: bad source address from client [10.88.113.212], packet dropped
Nov 7 08:49:19 raspberrypi ovpn-server[142996]: Motog8Mirko3/REDACTED:33665 MULTI: bad source address from client [10.88.113.212], packet dropped
Nov 7 08:49:19 raspberrypi ovpn-server[142996]: Motog8Mirko3/REDACTED:33665 MULTI: bad source address from client [10.88.113.212], packet dropped
Nov 7 08:49:23 raspberrypi ovpn-server[142996]: Motog8Mirko3/REDACTED:33665 MULTI: bad source address from client [10.88.113.212], packet dropped
Nov 7 08:49:23 raspberrypi ovpn-server[142996]: Motog8Mirko3/REDACTED:33665 MULTI: bad source address from client [10.88.113.212], packet dropped
=============================================
:::: Debug complete ::::

mDNS (Avahi) working TO RPis but not between them

Avahi/mDNS is running by default on recent versions of Raspian. Great. Very convenient to just ssh pi#mypi.local.
I am doing development on a Mac and operating a local network of headless Raspberry Pis. Up until now, I was able to use mDNS to access the Pis, and the Pis used mDNS to connect to each other.
Today, I shifted the RPis to a private local network by setting them up on a wireless router unconnected to the internet. Once I join the private network, I am still able to access them via mDNS:
% ssh pi#scheduler.local
Linux scheduler 5.10.63-v7l+ #1459 SMP Wed Oct 6 16:41:57 BST 2021 armv7l
Last login: Mon Aug 1 09:07:43 2022
pi#scheduler:~ $
and
wes#macbook % ssh pi#crossing.local
Linux crossing 5.10.17-v7l+ #1414 SMP Fri Apr 30 13:20:47 BST 2021 armv7l
Last login: Mon Aug 1 09:07:46 2022
pi#crossing:~ $
But when they try to access each other, I get some results I don't understand:
pi#scheduler:~ $ ping crossing.local
PING crossing.local (10.0.0.1) 56(84) bytes of data.
From 192.168.0.1 (192.168.0.1) icmp_seq=1 Destination Net Unreachable
From 192.168.0.1 (192.168.0.1) icmp_seq=2 Destination Net Unreachable
From 192.168.0.1 (192.168.0.1) icmp_seq=3 Destination Net Unreachable
From 192.168.0.1 (192.168.0.1) icmp_seq=4 Destination Net Unreachable
Here's what Avahi reports:
pi#scheduler:~ $ service avahi-daemon status
● avahi-daemon.service - Avahi mDNS/DNS-SD Stack
Loaded: loaded (/lib/systemd/system/avahi-daemon.service; enabled; vendor preset: enabled)
Active: active (running) since Mon 2022-08-01 09:07:37 PDT; 41min ago
Main PID: 388 (avahi-daemon)
Status: "avahi-daemon 0.7 starting up."
Tasks: 2 (limit: 1438)
CGroup: /system.slice/avahi-daemon.service
├─388 avahi-daemon: running [scheduler.local]
└─414 avahi-daemon: chroot helper
Aug 01 09:08:08 scheduler avahi-daemon[388]: Leaving mDNS multicast group on interface wlan0.IPv4 with address 169.
Aug 01 09:08:08 scheduler avahi-daemon[388]: Joining mDNS multicast group on interface wlan0.IPv4 with address 192.
Aug 01 09:48:29 scheduler avahi-daemon[388]: Files changed, reloading.
Aug 01 09:48:29 scheduler avahi-daemon[388]: No service file found in /etc/avahi/services.
Here's my hosts and hostname files:
pi#scheduler:~ $ cat /etc/hosts
127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
127.0.1.1 scheduler
pi#scheduler:~ $ cat /etc/hostname
scheduler
What does avahi say about it? Let's see:
pi#brs-scheduler:~ $ avahi-resolve --name brs-crossing.local -4
brs-crossing.local 192.168.0.214
pi#brs-scheduler:~ $ ifconfig | grep "inet 192"
inet 192.168.0.109 netmask 255.255.255.0 broadcast 192.168.0.255
pi#brs-scheduler:~ $ ping brs-crossing.local
PING brs-crossing.local (10.0.0.1) 56(84) bytes of data.
From 192.168.0.1 (192.168.0.1) icmp_seq=1 Destination Net Unreachable
So for some reason, on this private network, mDNS is resolving correctly, but ping and ssh don't resolve properly?
What am I missing?
Unsurprisingly, since the pis worked fine on the local net and stopped working on a private net with a new router, it had to do with the configuration of the new router not mDNS.
mDNS was working fine:
pi#scheduler:~ $ avahi-resolve --name crossing.local -4
crossing.local 192.168.0.214
The new router on the private net had two operating modes "router" and "access point." In "router" mode, the router was pushing a DNS nameserver IP to clients which was somehow hosing ping and ssh and other services, despite mDNS working okay.
pi#scheduler:~ $ cat /etc/resolv.conf
# Generated by resolvconf
nameserver 192.168.0.1
Once the router was placed in "access point" mode, and DHCP was turned on manually, everything worked.
Obscure problem. Obscure solution.

Handshake Failed test connectivity for OpenVPN

I am trying to set up OpenVPN on Ubuntu 20.04. I'm not experienced in this area. After I set up OpenVPN, I perform test connectivity. I received handshake error message:
Sun Jul 26 05:53:17 2020 TCP/UDP: Preserving recently used remote address: [AF_INET]68.228.217.219:1194
Sun Jul 26 05:53:17 2020 Socket Buffers: R=[212992->212992] S=[212992->212992]
Sun Jul 26 05:53:17 2020 UDP link local: (not bound)
Sun Jul 26 05:53:17 2020 UDP link remote: [AF_INET]My_Public_ISP_IP:1194
Sun Jul 26 05:54:17 2020 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Sun Jul 26 05:54:17 2020 TLS Error: TLS handshake failed
Sun Jul 26 05:54:17 2020 SIGUSR1[soft,tls-error] received, process restarting
Sun Jul 26 05:54:17 2020 Restart pause, 5 second(s)
Then I check to log
journalctl --identifier openvpn
I found two error message I believe why my OpenVPN cannot connect:
This is one of the error messages:
Could not determine IPv4/IPv6 protocol. Using AF_INET
I notice it's using my old client .conf file:
Error Message
My new .conf file is local.ovpn/
I tried removing client conf. sudo rm -vf BigK and replace it with local.ovpn. but it didnt work.
I need help figuring this issue out. i tried researching on my own but i came up short.
UPDATE
After several hours of researching online. the closet post I see helping me is this post https://unix.stackexchange.com/questions/385966/openvpn-error-status-2-and-cant-connect-to-internet-while-usingwhich didn't help.
I checked my client.conf
client
dev tun
proto udp
remote Public_IP 1194
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
auth SHA512
cipher AES-256-CBC
ignore-unknown-option block-outside-dns
block-outside-dns
verb 3
<ca>
Here is my server.conf
local IP
port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh.pem
auth SHA512
tls-crypt tc.key
topology subnet
server 10.8.0.0 255.255.255.0
push "redirect-gateway def1 bypass-dhcp"
ifconfig-pool-persist ipp.txt
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"
keepalive 10 120
cipher AES-256-CBC
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
verb 3
crl-verify crl.pem
explicit-exit-notify
Here is localvpn.ovpn
client
dev tun
proto udp
remote Public_IP 1194
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
auth SHA512
cipher AES-256-CBC
ignore-unknown-option block-outside-dns
block-outside-dns
verb 3
I faced the same problem and didn't find any solution. I was looking for another way to connect to OpenVPN server and it helped me.
Ubuntu 20.04 has a default tool for using OpenVPN:
Settings -> Network
Click + icon on one line with the VPN title
Choose Import from file... option and select your .ovpn config file in the popup window
Click Add button and that's it
PS: I hope it will help somebody to save any hours

Why hackers hit port 161

Recently one of our servers faced a DOS attack, and from iptables log we found out that they hit port 161 of the server. I wonder why? Here is the iptable log
Mar 25 14:02:45 srv1 kernel: iptables denied: IN=eth0 OUT=MAC=xx:xx:xx SRC=xx.xx.xx.xx DST=xx.xx.xx.xx LEN=66 TOS=0x00 PREC=0x00 TTL=237 ID=1047 PROTO=UDP SPT=22 DPT=161 LEN=46
Mar 25 14:02:55 srv1 kernel: iptables denied: IN=eth0 OUT= MAC=xx:xx:xx SRC=xx.xx.xx.xx DST=xx.xx.xx.xx LEN=66 TOS=0x08 PREC=0x20 TL=232 ID=1047 PROTO=UDP SPT=7777 DPT=161 LEN=46
...
According to /etc/services, port 161 is the port of SNMP. Perhaps that could explain why hackers attacked that port? Lots of networking gear use SNMP for management.
They probably tried an SNMP amplification attack explained e.g. in https://isc.sans.edu/forums/diary/SNMP+The+next+big+thing+in+DDoS+Attacks/18089/
The idea of reflectors is to cause a small request packet to get a large reply packet response. The source IP address of the request packet is obviously spoofed to be the target of the attack. So, in other words: you weren't the real target of the attack, they just tried to use your network equipment to amplify traffic to the real attack target.