OpenVPN MULTI: bad source address from client

Back again, I am sorry for the late reply, but was absent for work. Nevertheless, read a lot which thanks to the above given advise now were understandable to me.

What I understand so far is

  1. connecting from an outside LAN, e.g. hotel router, is not possible. This is because OpenVPN receives both the WAN IP of the hotel router and the LAN IP of your device. A WAN IP is accepted, but when it is associated with a LAN IP, OpenVPN refuses the connection.
    This explains, why my sister's mobile phone could connect for a while and suddenly it did not work any more: she was then in the hotel and logged into the hotel's LAN.
    Notwithstanding, it does work if you are in the same LAN as the OpenVPN server. It may be a setting independent of the server configuration file

:joy::joy::joy::joy: I am from Germany, a third world country in IT technology. The average upload is 2.4 MHz, and I am having ........ 750 kHz, theoretically. 50% of the values will normally be achieved, except for rush hours.

Right, this was an interesting learning experience, because of my wrong assumptions:
A) securing internet access when travelling with mobile and laptop while travelling, protecting oneself from the LAN of the hotels, is not a practical solution.
B) OpenVPN requires much bandwidth, apoint that I have not yet seen so clearly stated

The bottom line for me is:
The initial problem has been solved, it was definitely the outside LAN. I know that it is possible to make a redirection rule for individual LANs, but that is not practical for me.
Anyway, just because it is fun, I shall test all the proposed tests to see the influence of the encryption method on the speed. I took it for granted so far, that with modern PCs and routers, this is neglegible.

Cheers and thank you very much
Oscar

PS: What is a 3rd party VPN? A professional VPN provider?

No.

  • You cannot connect to the OpenVPN server while connected to another interface on the same router as the OpenVPN server if your OpenVPN server is not configured for Gateway Redirect (yours is not)
    • There should be no issue connecting to the remote [your home] router running the OpenVPN server while behind your router at a hotel, which is behind the hotel's router, and receiving a LAN [RFC1918] IP from the hotel's router.
      • The only potential issue that would arise is many hotels utilize extremely strict firewalling, blocking most ports except 80 and 443. If this is the case, 443 should be used for your VPN server port (I again recommended configuring a separate OpenVPN server for securing your public internet traffic while away from home)

2.4mbit/s and 750kbit/s?

  • If so, you really should pay for a 3rd party VPN service, which would guarantee full access speeds at whatever the max speed is for whatever public connection you happen to be utilizing. Check out The Hacker News deals, as you'll find several VPNs discounted through them.
    • Before purchasing a 3rd party VPN subscription, do some comparison shopping between different ones to determine which one offers the features you want (some have far more remote servers than others)

A 3rd party VPN is a commercial VPN server where your router would be configured as an OpenVPN client that would connect to the commercial VPN service's server.

OpenVPN doesn't require any bandwidth, but when you connect to an OpenVPN server, your download/upload speed will be limited to the upload speed of whatever ISP plan the router running the server has.

According to these sites (OpenVPN wiki and here also) it is not possible to connect when the client is behind a router in a LAN. "iroute" is required.

From the a.m. OpenVPN web site:

OpenVPN advises to add an iroute statement for every client-LAN that wants to connect to the OpenVPN server (in ccd/common-name-client).

Did I misunderstand something (most likely)?

You're conflating two completely different things...

  • Your OpenVPN server is running on your home router, of which is connected to a modem, with it's WAN interface receiving a WAN IP
    • Any client connecting to the home router running the OpenVPN server does not need an iroute command, as the client's ovpn file should have the following line:
      remote your.ddns.com <vpn server port #>
      • This tells the client where to find the VPN Server at, and it doesn't matter if your client is behind a remote router receiving a LAN [RFC1918] IP.
        • The only thing that may need to be done is depending on how how restrictive the firewall of the hotel's router is, as many will block all ports except 80 [HTTP] and 443 [HTTPS]. If this is the case, the OpenVPN server should be ran on port 443.
          • This is not recommended unless once encounters highly restrictive firewalls, as it can result in excess traffic to 443.

Note:

  • The OpenVPN link's iroute scenario does not apply to you (note the 3rd paragraph):
    You may realize that client1 should not route 10.10.1.0 traffic over the vpn, and that client2 should not route 10.10.3.0 traffic over the vpn (because those networks are local to each client). Because of the iroute entries you will see below, openvpn knows this too and skips the push for the client.
    
    The route entries are telling his server to add a route for each of 10.10.1.0, and 10.10.3.0 to its kernel's routing table, and both will be routed to the tunnel interface and to openvpn. How will openvpn know what client to send each network to? The answer is iroute!
    
    Iroute does not bypass or alter the kernel's routing table, it allows openvpn to know it should handle the routing when the kernel points to it but the network is not one that openvpn knows about. The iroute entry tells the openvpn server which client is responsible for the network. Without the iroute entry you will find the following in your logfiles:
    

My sincere apologies. I read this stuff many times again and again, but still don't get it, why the server refuses the connection (note: the OpenVPN server, the firewall has already been crossed successfully)

the client did indeed contact the OpenVPN server properly. However, it was the server that refused the connection.

This I believe refers to LAN communication within the clients LAN.Just above is a server configuration, that informs the OpenVPN server about LANs of clients (in my a.m. configuration, and in your wiki, only the LAN of the server ist described: "list push 'route 192.168.0.0 255.255.255.0").

I am feeling pretty unpleasant, apparently you are the expert and I am the beginner, and I keep on dissenting. Its just that I do want to understand (will upgrade my internet speed soon...). Hope for your acceptance.

I'd encourage doing some research on the OpenVPN wiki site, especially the man page

Not according to this post above.