What's new

OpenVPN both TCP and UDP?

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

gjf

Senior Member
Hi all.

I have configured OpenVPN using UDP succesfully.
But as I was found some countries block VPN based on port number and UDP so for some cases I need TCP on port 443.

When I tried to copy configuration from working UDP one with changing UDP to TCP and port number to 443 the configuration does not intitialize - I can see the following in log:
an 21 13:24:01 rc_service: service 22971:notify_rc restart_vpnserver2
Jan 21 13:24:02 kernel: br0: topology change detected, propagating
Jan 21 13:24:02 kernel: br0: port 5(tap22) entering forwarding state
Jan 21 13:24:02 kernel: br0: port 5(tap22) entering forwarding state
Jan 21 13:24:02 kernel: br0: port 5(tap22) entering forwarding state
Jan 21 13:24:02 kernel: br0: port 5(tap22) entering disabled state
Jan 21 13:24:03 kernel: Interface tap22 doesn't exist
Jan 21 13:24:03 kernel: Interface tun22 doesn't exist
Jan 21 13:24:03 kernel: device tap22 entered promiscuous mode
Jan 21 13:24:03 kernel: ADDRCONF(NETDEV_UP): tap22: link is not ready
Jan 21 13:24:03 ovpn-server2[23027]: WARNING: POTENTIALLY DANGEROUS OPTION --verify-client-cert none|optional (or --client-cert-not-required) may accept clients which do not present a certificate
Jan 21 13:24:03 ovpn-server2[23027]: OpenVPN 2.4.8 arm-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Dec 31 2019
Jan 21 13:24:03 ovpn-server2[23027]: library versions: OpenSSL 1.1.1d 10 Sep 2019, LZO 2.08
Jan 21 13:24:03 ovpn-server2[23028]: NOTE: when bridging your LAN adapter with the TAP adapter, note that the new bridge adapter will often take on its own IP address that is different from what the LAN adapter was previously set to
Jan 21 13:24:03 ovpn-server2[23028]: WARNING: using --duplicate-cn and --client-config-dir together is probably not what you want
Jan 21 13:24:03 ovpn-server2[23028]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Jan 21 13:24:03 ovpn-server2[23028]: PLUGIN_INIT: POST /usr/lib/openvpn-plugin-auth-pam.so '[/usr/lib/openvpn-plugin-auth-pam.so] [openvpn]' intercepted=PLUGIN_AUTH_USER_PASS_VERIFY
Jan 21 13:24:03 ovpn-server2[23028]: Diffie-Hellman initialized with 2048 bit key
Jan 21 13:24:03 ovpn-server2[23028]: Failed to extract curve from certificate (UNDEF), using secp384r1 instead.
Jan 21 13:24:03 ovpn-server2[23028]: ECDH curve secp384r1 added
Jan 21 13:24:03 ovpn-server2[23028]: Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Jan 21 13:24:03 ovpn-server2[23028]: Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Jan 21 13:24:03 ovpn-server2[23028]: Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Jan 21 13:24:03 ovpn-server2[23028]: Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Jan 21 13:24:03 ovpn-server2[23028]: TUN/TAP device tap22 opened
Jan 21 13:24:03 ovpn-server2[23028]: TUN/TAP TX queue length set to 1000
Jan 21 13:24:03 ovpn-server2[23028]: updown.sh tap22 1500 1656 init
Jan 21 13:24:03 kernel: ADDRCONF(NETDEV_CHANGE): tap22: link becomes ready
Jan 21 13:24:03 kernel: br0: topology change detected, propagating
Jan 21 13:24:03 kernel: br0: port 5(tap22) entering forwarding state
Jan 21 13:24:03 kernel: br0: port 5(tap22) entering forwarding state
Jan 21 13:24:03 ovpn-server2[23028]: Could not determine IPv4/IPv6 protocol. Using AF_INET6
Jan 21 13:24:03 ovpn-server2[23028]: Socket Buffers: R=[87380->87380] S=[16384->16384]
Jan 21 13:24:03 ovpn-server2[23028]: setsockopt(IPV6_V6ONLY=0)
Jan 21 13:24:03 ovpn-server2[23028]: TCP/UDP: Socket bind failed on local address [AF_INET6][undef]:443: Address already in use (errno=98)
Jan 21 13:24:03 ovpn-server2[23028]: Exiting due to fatal error
Jan 21 13:24:03 ovpn-server2[23028]: Closing TUN/TAP interface
Jan 21 13:24:03 ovpn-server2[23028]: updown.sh tap22 1500 1656 init

So what is wrong? Does it mean it is not possible to run two instances of OpenVPN?
 
Hi all.

I have configured OpenVPN using UDP succesfully.
But as I was found some countries block VPN based on port number and UDP so for some cases I need TCP on port 443.

When I tried to copy configuration from working UDP one with changing UDP to TCP and port number to 443 the configuration does not intitialize - I can see the following in log:


So what is wrong? Does it mean it is not possible to run two instances of OpenVPN?
I think your problem is here:
Code:
Jan 21 13:24:03 ovpn-server2[23028]: TCP/UDP: Socket bind failed on local address [AF_INET6][undef]:443: Address already in use (errno=98)
Jan 21 13:24:03 ovpn-server2[23028]: Exiting due to fatal error
Something else is sitting on port 443. Perhaps you have the webgui there, or maybe one of the Asus applications, and you could turn them off. Or, you could set openvpn to bind only to the wan address.

It looks like you have compression enabled and are not requiring a client certificate. If you are worried about state actors you might rethink both those.
 
  • Like
Reactions: gjf
Something else is sitting on port 443. Perhaps you have the webgui there, or maybe one of the Asus applications, and you could turn them off. Or, you could set openvpn to bind only to the wan address.
Yes, I see it and it is really the case - but how to identify what is sitting at 443?
Any idea?
 
In a terminal, run
Code:
netstat -tulpn | grep LISTEN
You'll get something like:

Code:
elorimer@RT-AC86U:/tmp/home/root# netstat -tulpn | grep LISTEN
netstat: showing only processes with your user ID
tcp        0      0 0.0.0.0:5152            0.0.0.0:*               LISTEN      607/envrams
tcp        0      0 0.0.0.0:5473            0.0.0.0:*               LISTEN      1838/u2ec
tcp        0      0 0.0.0.0:18017           0.0.0.0:*               LISTEN      923/wanduck
tcp        0      0 0.0.0.0:3394            0.0.0.0:*               LISTEN      1838/u2ec
tcp        0      0 192.168.50.1:515        0.0.0.0:*               LISTEN      1839/lpd
tcp        0      0 127.0.0.1:47753         0.0.0.0:*               LISTEN      1986/mcpd
tcp        0      0 192.168.50.1:9100       0.0.0.0:*               LISTEN      1839/lpd
tcp        0      0 0.0.0.0:7788            0.0.0.0:*               LISTEN      1145/cfg_server
tcp        0      0 192.168.50.3:80         0.0.0.0:*               LISTEN      2602/pixelserv-tls
tcp        0      0 127.0.0.1:80            0.0.0.0:*               LISTEN      1026/httpd
tcp        0      0 192.168.50.1:80         0.0.0.0:*               LISTEN      1026/httpd
tcp        0      0 127.0.0.1:53            0.0.0.0:*               LISTEN      2404/dnsmasq
tcp        0      0 192.168.50.1:53         0.0.0.0:*               LISTEN      2404/dnsmasq
tcp        0      0 10.8.0.1:53             0.0.0.0:*               LISTEN      2404/dnsmasq
tcp        0      0 10.16.0.1:53            0.0.0.0:*               LISTEN      2404/dnsmasq
tcp        0      0 192.168.50.1:22         0.0.0.0:*               LISTEN      981/dropbear
tcp        0      0 0.0.0.0:41240           0.0.0.0:*               LISTEN      2971/miniupnpd
tcp        0      0 127.0.0.1:8888          0.0.0.0:*               LISTEN      1074/vis-dcon
tcp        0      0 192.168.50.3:443        0.0.0.0:*               LISTEN      2602/pixelserv-tls
tcp        0      0 xxx.xxx.xxx.xxx:443        0.0.0.0:*               LISTEN      2234/vpnserver1
tcp        0      0 192.168.50.1:3838       0.0.0.0:*               LISTEN      1839/lpd
From that you can see I have pixelserv running on the LAN side port 443, and vpn server 1 on the WAN side port 443.
 
In a terminal, run
Code:
netstat -tulpn | grep LISTEN

tcp 0 0 0.0.0.0:18017 0.0.0.0:* LISTEN 196/wanduck
tcp 0 0 127.0.0.1:80 0.0.0.0:* LISTEN 262/httpd
tcp 0 0 192.168.111.1:80 0.0.0.0:* LISTEN 262/httpd
tcp 0 0 0.0.0.0:8082 0.0.0.0:* LISTEN 1023/lighttpd
udp 0 0 0.0.0.0:18018 0.0.0.0:* 196/wanduck
udp 0 0 0.0.0.0:38000 0.0.0.0:* 218/eapd
udp 0 0 127.0.0.1:38032 0.0.0.0:* 230/nas
tcp 0 0 0.0.0.0:59328 0.0.0.0:* LISTEN 1386/miniupnpd
tcp 0 0 0.0.0.0:5473 0.0.0.0:* LISTEN 705/u2ec
tcp 0 0 192.168.111.1:33 0.0.0.0:* LISTEN 212/dropbear
tcp 0 0 0.0.0.0:18017 0.0.0.0:* LISTEN 196/wanduck
tcp 16 0 0.0.0.0:3394 0.0.0.0:* LISTEN 705/u2ec
tcp 0 0 0.0.0.0:9091 0.0.0.0:* LISTEN 898/transmission-da
tcp 0 0 192.168.111.1:515 0.0.0.0:* LISTEN 706/lpd
tcp 0 0 0.0.0.0:8200 0.0.0.0:* LISTEN 1391/minidlna
tcp 0 0 127.0.0.1:139 0.0.0.0:* LISTEN 1359/smbd
tcp 0 0 192.168.111.1:139 0.0.0.0:* LISTEN 1359/smbd
tcp 0 0 192.168.111.1:9100 0.0.0.0:* LISTEN 706/lpd
tcp 0 0 0.0.0.0:7788 0.0.0.0:* LISTEN 394/cfg_server
tcp 0 0 127.0.0.1:80 0.0.0.0:* LISTEN 262/httpd
tcp 0 0 192.168.111.1:80 0.0.0.0:* LISTEN 262/httpd
tcp 0 0 0.0.0.0:8082 0.0.0.0:* LISTEN 1023/lighttpd
tcp 0 0 0.0.0.0:21 0.0.0.0:* LISTEN 1364/vsftpd
tcp 0 0 0.0.0.0:51413 0.0.0.0:* LISTEN 898/transmission-da
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 253/dnsmasq
tcp 0 0 192.168.111.1:53 0.0.0.0:* LISTEN 253/dnsmasq
tcp 0 0 0.0.0.0:3702 0.0.0.0:* LISTEN 1362/wsdd2
tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 1023/lighttpd
tcp 0 0 0.0.0.0:1723 0.0.0.0:* LISTEN 738/pptpd
tcp 0 0 127.0.0.1:445 0.0.0.0:* LISTEN 1359/smbd
tcp 0 0 192.168.111.1:445 0.0.0.0:* LISTEN 1359/smbd
tcp 0 0 192.168.111.1:3838 0.0.0.0:* LISTEN 706/lpd
tcp 0 0 :::51413 :::* LISTEN 898/transmission-da
 
AICloud?
 
  • Like
Reactions: gjf
It looks like you have compression enabled and are not requiring a client certificate. If you are worried about state actors you might rethink both those.
Could you explain it more detailed?
Unfortunately I was not able to find the way to generate client certificates in Asus Merlin.
 
Two separate security issues.

Unless you require certificates, all it takes to get access to your network is the username and password. That includes the admin name for the router too. The router automatically generates client certificates and exports them with the configuration. You can see them from the advanced settings.

Compression is said not to do much, since a lot of traffic is compressed anyway. But compression offers a way to crack the encryption.
 
Two separate security issues.

Unless you require certificates, all it takes to get access to your network is the username and password. That includes the admin name for the router too. The router automatically generates client certificates and exports them with the configuration. You can see them from the advanced settings.

Compression is said not to do much, since a lot of traffic is compressed anyway. But compression offers a way to crack the encryption.
1. The config soes not include it, but the lines:
</ca>
<cert>
paste client certificate data here
</cert>
<key>
paste client key data here
</key>
So this is exactly why I switched it off.

2. As for compression - should it be "disabled" or "none" - and what's the difference?
 
Last edited:
Ah. Yes, I don't know why sometimes the exported configuration for a second server is incomplete this way. So for the second configuration file, just paste in the certificate info from that server's advanced setting page by opening up the "keys" button.

"Disabled" means packets aren't framed for compression. "None" means they are framed for compression, even if the data isn't compressed according to one of the protocols. If the client and server are mismatched here, a connection will be made but no data will transfer, because they are talking different languages.
 
Does it mean I have to switch to Static Key Authorization Mode?
No, just change the radio button for password only from yes to no.
 
Anyway - even first VPN does not export the correct ovpn files with client keys.
On VPN tab in keys section I see: Static Key, Certificate Authority, Server Certificate, Server Key and Diffie Hellman parameters. All these data were generated by me when configuring the server.
So - what I should copy for client certificate data and what - for client key data? It is not very clear for me.

Let's focus on this for the moment as I have a number of questions regarding compression also.
 
You would copy the CA, SC and SK fields into the corresponding places in the configuration file.

But you might consider resetting the VPN servers to default and starting over. I'm not sure how you generated those on your own.
 
CA is already there in <ca> node as well as SK is in <tls-crypt> node.
As I mentioned two new fields appear when changing redio button: <cert> and <key>.
So what I should put there? SC in both looks incorrect.

Please note all these valuse were generated a years ago and work OK on a number of devices.
 

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top