Openvpn Port 943

[Yolette Langevin]

Thisis only the WebUI bug that the invalid port display shown when custom port is used. OpenVPN will still connect using the custom port. Tentatively the bug will be fix for coming firmware released.

#edit: ok, meanwhile i connected to the vpn (just needed to forwar port 1194 on the provider router to the ipfire) Within the firewall i allowed the vpn-client to connect to the red network (to get the internet connection). So it seems to work!

Haugene/transmission-openvpn port forwarding. I am trying to forward the 9091 & 51413 ports. I did the setup in the router but I couldn't set up in the haugene/transmission-openvpn docker.

I enabled the port forwarding in the config but it doesn't work. I don't see the "CONFIGURING PORT FORWARDING" in my log.

I attached my config and the screenshot of my router settings. My OMV is on 192.168.88.249 address. The port forwarding works on ftp server on port 21.

I got all "AEAD Decrypt error: bad packet ID (may be a replay):" on all hungarian NORDVPN servers.

I tested the port with forwarding on my PC (installed qbittorrent) everything is working fine (canyouseeme sees the opened port). But when I am using vpn docker the port seems to be closed. I tried to forward the Cloud commander on port 8000. No luck, I got the same message. The port unreachable for outside. I attached my cofigs and log files.

For example, say you want to run a web server but you do not want to hand out your real WAN IP address. You want to hand out your public VPN address instead and have the traffic go thru the tunnel to your server. This will require that your VPN provider open a port on their end of the connection and forward it thru the tunnel to you. This is not supported by NordVPN and others.

I am trying to forward a transmission port for example 51413 to the outside world. Without the opened peer port the torrent client is useless no upload and lack of peers.

The haugene version + Nordvpn service combination doesn't work for me. The peer and the service port (9091) unable to reach from outside.

I contacted the Nordvpn support they told that we don't support port forwarding (because the illegal uploading on a shared servers.).

And voila the port is open (I checked via canyouseeme.com) I got zero peers for the upload/seed. But In the torrent site stats I got a true seed flag instead of the haugene vpn which gives me a torrent stopped flag because the closed port). PIA supports port forwarding. Unfortunately I have a 3 years subscription on nordvpn

You shouldn't need any port forwarding set in your router. I use Deluge docker with Socks5 proxy and don't have any ports forwarded. One thing you may notice is that you have a red no incoming connections icon showing but this is not a problem.

However I want OpenVPN to use port 443 (because of port restrictions on public (wifi) networks).

So I changed via Luci the OpenVPN config to use port 443, adapted the firewall to accept port 443 iso 1194, and changed the client openvpn config to also use port 443.

I'd suggest only enabling HTTP-S on the standard port 443 and binding it explicitly to the IPv4 and possibly IPv6 address of your LAN (preferably a management VLAN, but I'll take specific LAN address over wildcard).

Again, running LuCI without HTTP-S is a significant security risk. It is a security "disaster" on your publicly accessible interfaces (which, unless you live in the middle of nowhere, you should consider your wireless as "publicly accessible" as well).

BTW is

tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 3304/openvpn

secure enought, or should I bind OpenVPN also to a specific IP address? If so to then IP address attached to the WAN interface, or the LAN interface?

DHCP makes a mess of this if you're not in control of your outside IP address. You can either be secure and "hard code" your outside IP address, but have things not work if your ISP changes them, or deal with the fact that OpenVPN will be listening on all addresses if you use a wildcard. Some applications will let you specify which interface by name (or number) and then adjust if that interface changes its IP address. If that were possible, you'd be able to have OpenVPN listening on 443 on your "WAN" interface (only) and LuCI being served on 443 on your "LAN" interface only.

What you've got is a reasonable compromise -- you have LuCI being served over HTTP-S, LuCI is only available on your LAN interface, and you can reasonably configure OpenSSL to listen on 443 and adapt to DHCP changes in your WAN IP.

-user/services/vpn/openvpn/basic is a good starting point for OpenVPN configuration on OpenWrt. I didn't see mention of which parameter to set there, so let's look at OpenVPN documentation to figure out what to set.

Sometimes the wiki content isn't complete for more advanced options and looking at the scripts that convert the UCI files in /etc/config/ to the format that the executable uses can be helpful. One way to find them is to search the package table for OpenVPN and then click on the sources link.

I found getting OpenVPN to work very confusing and frustrating. Eventually, I got OpenVPN working with two separate Orbi systems on Android, Linux, and Windows clients. in other words..... I am certainly no 'expert', but it does work.

The important part (to me) is that they are different. If an OpenVPN Client connection designed for tap tries to connect to an OpenVPN host designed for tun, it will fail. (And the reverse.)

Can you be a bit more specific about this? My 'sense' is that the laptop was taken to another place where it could connect to a different network. Is this correct? (My own test practice is to disconnect my smartphone from the Orbi WiFi, which causes it to revert to LTE data. Then open a "Hot Spot" and connect the laptop to that. My point is that this test has the laptop in no way connected to the Orbi network.

As I undertsand it, OpenVPN client versions prior to 3.x support both TUN and TAP connections. Starting with version 3.0, the client only supports TUN. If you want your device to be able to communicate with other devices on your network when connecting, it must use TAP. TUN is just for access to the Internet it seems, for example if you're traveling in another country and you're tryign to watch Netflix in your own country.

My understanding of the tun/tap difference is that tap puts the VPN client in the same IP subnet as the Orbi LAN, and thus all broadcast messages go across the VPN tunnel (in both directions). Here's how Wikipedia describes it:

Though both are for tunneling purposes, TUN and TAP can't be used together because they transmit and receive packets at different layers of the network stack. TUN, namely network TUNnel, simulates a network layer device and operates in layer 3 carrying IP packets. TAP, namely network TAP, simulates a link layer device and operates in layer 2 carrying Ethernet frames. TUN is used with routing. TAP can be used to create a user space network bridge.

The configuration files Orbi produces for Windows and 'non-Windows' (i.e. Linux) both specify tap as the default. The configuration file Orbi produces for 'smartphones' specified tun because iPhones and Android phones are restricted to using tun. Both tap and tun allow access to devices on the LAN. (I just verified this with my Android phone using tun)

For me, this has never been an issue because I typically connect to a Hot Spot on my phone, which hands out 192.168.43.x IP addresses. All subnets from 0 through 254 are valid private IP addresses. Maybe some engineer was thining ahead, "what if someone attempts to open a VPN on this phone's Hot Spot?" Or, maybe just dumb luck.

I'm currently in the situation of attempting to setup OpenVPN on a personal VPS, for connection primarily through an overly restrictive firewall. All of the setups mentioned below work when used through a reasonably-firewalled connection.

Connections being cut off after a length of time sometimes indicate a bytes-per-second type of limit. Try seeing if slowing down your VPN connection works. Also if you have OpenVPN configured for UDP try TCP (443 UDP may be blocked whereas 443 TCP may go undetected).

Visit a well known site that uses SSL and check the certificate. Then do the same at home. If they don't match then your location is using a transparent HTTPS SSL proxy and can actually see your HTTPS traffic.

I think i know why the stunnel methode behaves like that. It's because you net to set an "static route" for stunnel server.Let me explain that. When you connect to an openvpn server it changes your routing table and route all your packets trough the vpn ,except the openvpn packets. actualy openvpn will add a route for your server ip address. But when you using stunnel to connect to your openvpn server you will connect openvpn to a loopback interface and there is no route to your server outside your vpn, so stunnel packets want to go to server and they going to your vpn and your vpn packets going to stunnel :)

And for problem with method port 443 i ganna say that maybe your the firewall using SPI or DPI and the can easily make diffrent openvpn packets from https (ssl) packets. So best way is to use stunnel, or if firewall blocks ssl packets it's better to use obfsproxy or fteproxy to bypass it.

In addition to LawrenceC's answer, I would like to add that outgoing DDoS protection against slow loris and other "low and slow" DDoS attacks originating from that network will force-close sessions after a certain length of time.

As mentioned before, it might be caused by a traffic volume limit as well, but there is another reason why there would be such a limit; limiting bandwidth per device is trivial with today's (2021) tech and no longer uses session timeouts to enforce that, but outgoing DDoS protection might also kick sessions that send a constant stream of data that uses a protocol who's behavior is intrinsically sporadic, especially if the traffic contains packets that are either too uniform or too fragmented to match the behavior of legitimate HTTPS sessions (which is what a lot of flood-type DDoS attacks look like).

3a8082e126