Expectation is tun device should be created as defined in .ovpn configuration. I got the client configuration from pivpn (with nopass option while creating client)
Network config, firewall config and vpn server/client startup log?
Server:
latest pivpn on rpi.
ovpn configured to listen on tcp:443
connected to main router - openwrt
main router WAN tcp:443 forwarded to pivpn's ip+firewall-zone
telnet proved connectivity using DDNS from another host connected to main router on same lan/firewall as client router below.
Client:
openwrt 23.05.2 on ASUS-RT-AC1200 (not v2)
default network and firewall from installation + (installed openssl+openvpn+luci)
ovpn conf using DDNS and proper port tcp:443 generated from pivpn server
WAN is client to same main router as server
config: ============================
client
dev tun0
proto tcp
remote <my DDNS> 443
resolv-retry infinite
nobind
remote-cert-tls server
tls-version-min 1.2
verify-x509-name pihole_.... name
cipher AES-256-CBC
auth SHA256
auth-nocache
verb 3
<ca>
-----BEGIN CERTIFICATE-----
. . .
logs show connection successful (but drops and reconnects repeatedly)
client LOGS:=========================================================
Mon Nov 27 14:37:50 2023 daemon.warn openvpn(piovpn)[2262]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Mon Nov 27 14:37:50 2023 daemon.notice openvpn(piovpn)[2262]: Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Mon Nov 27 14:37:50 2023 daemon.notice openvpn(piovpn)[2262]: Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Mon Nov 27 14:37:50 2023 daemon.notice openvpn(piovpn)[2262]: Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Mon Nov 27 14:37:50 2023 daemon.notice openvpn(piovpn)[2262]: Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Mon Nov 27 14:37:50 2023 daemon.notice openvpn(piovpn)[2262]: Attempting to establish TCP connection with [AF_INET]<my an ip> [nonblock]
Mon Nov 27 14:37:50 2023 daemon.notice openvpn(piovpn)[2262]: TCP connection established with [AF_INET]<my wan ip>:443
Mon Nov 27 14:37:50 2023 daemon.notice openvpn(piovpn)[2262]: TCP_CLIENT link local: (not bound)
Mon Nov 27 14:37:50 2023 daemon.notice openvpn(piovpn)[2262]: TCP_CLIENT link remote: [AF_INET]<my wan ip>:443
Mon Nov 27 14:38:20 2023 daemon.err openvpn(piovpn)[2262]: Connection reset, restarting [0]
Mon Nov 27 14:38:20 2023 daemon.notice openvpn(piovpn)[2262]: SIGUSR1[soft,connection-reset] received, process restarting
Mon Nov 27 14:38:20 2023 daemon.notice openvpn(piovpn)[2262]: Restart pause, 300 second(s)
same behaviour on TP-LINK WR1043NDv2 (with wolfssl)
So why am I quoting my self, that is the big question of life on earth or something?
Well you need two to dance tango so without network and firewall config in combination with openvpn there will be no tango called tunX.
Startup log…the tun0 interface is created at boot and startup of the openvpn service. The log you have shown is the tunnel activation log, not the startup log.
One easy way is to restart openvpn and the startup log will be found in the bottom part of systemlog.
But I doubt there is even a tunX error at this point of time. Your connection between the server and client isn’t even established at L3 level with timeout error according to the log and you don’t have a TLS handshake.
Have you tried udp instead of tcp?
Have you opened the firewall at both ends?
Do you have a real internet connection or are you behind any ISP nat or firewall?
tun is not needed to start the tunnel. That can start and connect the devices by itself without problem.
tun is only needed to route the data to a network at both ends.
udp: no - I would rather use wireguard. My use case needs TCP (target will be client from hotel wifi)
connectivity - I am able to telnet the port successfully from client router to piovpn server port 443 successfully. This is all within my home network (but have port forwarded in main router from WAN to my ovpn server (with proper firewall zones). this is a test setup before I try external/out-of-home network. I do have internet working sucessfully and resolves my DDNS properly.
Maybe so but your own log doesn’t lie, you have no L3 connection between the client and the server whatever you feel about it.
And without connection there will be no tls handshake and without that any tunX is worthless.
@flygarn12 Appreciate the response and hints. finally worked out
don't know why/how. I had rebooted by router. I am good, no more on this from myside
admitt ! - it was my local/internal firewall zones. all good now.
1 Like
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.