[Openvpn-users] mssfix max is the guide broken
According to it's definition: Announce to TCP sessions running over the tunnel that they should limit their send packet sizes such that after OpenVPN has encapsulated them, the resulting UDP packet size that OpenVPN sends to its peer will not exceed maxbytes. The default value is 1450.The max parameter is interpreted in the same way as the –link-mtu parameter, i.e. the UDP packet size after encapsulation overhead has been added in, but not including the UDP header itself. Resulting packet would be at most 28 bytes larger for IPv4 and 48 bytes for IPv6 (20/40 bytes for IP header and 8 bytes for UDP header). Default value of 1450 allows IPv4 packets to be transmitted over a link with MTU 1473 or higher without IP level fragmentation. So if the default value is 1450 and the ipv4 header is + 28 = 1478 and the guide continues with "allows IPv4 packets to be transmitted over a link with MTU 1473 or higher" Is this a typo? I have a setup where the OpenVPN server is behind a link with MTU 1350. The VPN uses UDP. What can be the maximal mssfix size then, 1322 bytes? Also would you care explaining what is the advantage of setting the MSSFIX over setting the tunnel MTU to the highest possible value? The problems are that OpenVPN does not force you to do anything with the MTU, it even defaults to 1500bytes like it would be ethernet but when sending oversized packets inside the tunnel they will just get lost and you have to play around with this until apps start behaving correctly. Thanks ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] OpenVPN 3 Linux client - v8 beta released
On 10/02/2020 23:32, David Sommerseth wrote: > > Hi, > > The OpenVPN 3 Linux v8 beta is now released. > > This is available in our git repositories [0] and URLs for source tarballs > are listed later in this e-mail. We have pre-built binaries for the > following Linux distributions: > > * Fedora 30, 31 and Rawhide(via Fedora Copr: x86_64, ppc64le, aarch64) > * RHEL/CentOS 7 and 8 (via Fedora Copr: x86_64, ppc64le, aarch64) > * Debian 9 and 10 (amd64) > * Ubuntu 16.04, 18.04, 19.04 and 19.10 (amd64) > > But there is an annoying detail with this release. Cloudflare is doing > its best to ensure that the .deb package repositories are corrupt, invalid, > missing or not seeing the new files. I've tried to do the magic steps > required to clean up this, with no results. This issue should now be resolved. If you have issues with the openvpn3 Debian or Ubuntu packages, please get in touch so we can figure it out. -- kind regards, David Sommerseth OpenVPN Inc signature.asc Description: OpenPGP digital signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] Connection attempts to seemingly random IP addresses
On Mon, Feb 10, 2020 at 12:00:32 +0100, Reto Schneider wrote: > addresses it never should. The devices it is running on are Yocto based, > embedded, 32bit MIPS and deployed in remote networks which are not under > my control. [...] > 5) Optional: Wifi comes up again, interface gets IP address and route > assigned (dhcpcd logs): [...] > 6) OpenVPN suddenly tries to connect to a faulty IP: [...] > In this case there seems to be a correlation to the router IP address in > 5), but I have many more examples of unexplicable IP addresses (e.g. > 1.1.1.11, 212.27.38.252, 192.168.246.123, ...), all of which are > definitely not assigned to example.com. How much do you know about the remote (Wifi) networks these clients are connecting to? Is there a correlation between the different inexplicable IP addresses used and the particular remote network for that client? In particular I'm wondering if these are networks where when you first connect all traffic is directed to an "accept our terms of service" page (In this case, it would seem to involve overriding DNS responses from the networks local DNS server(s) so all domain names point to the local IP of the system hosting that page.) Nathan Nathan Stratton Treadway - natha...@ontko.com - Mid-Atlantic region Ray Ontko & Co. - Software consulting services - http://www.ontko.com/ GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239 Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239 ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] Connection attempts to seemingly random IP addresses
Hi, On 11/02/20 12:06, Reto Schneider wrote: On 2/10/20 5:23 PM, Jan Just Keijser wrote: the line push "dhcp-option DNS 10.176.0.1" is the main suspect here... my guess as to what happens is this: 1) VPN is started 2) that line causes the local /etc/resolv.conf file to be overwritten with the new DNS setting I just verified this: resolv.conf does not get adapted I would also not have expected it because on the client side "route-nopull" is specified. if your clients would have an update-resolv-conf script then the file would have been updated, regardless of 'route-nopull' - pushing a DNS server is not overruled by 'route-nopull' Also, I see in the clients log twice the following line: Options error: option 'dhcp-option' cannot be used in this context ([PUSH-OPTIONS]) (Guess I should do [1]...) My takeaway is that you think that this issue is because of funky DNS stuff going on. I will investigate some more in this area, but since I do not have access to the affected devices (only logs), actions like taking down OpenVPN to do analysis are pretty much impossible to do. there's two things I would try in your case, but for both you need access to a client device 1) replace 'remote example.com' with 'remote a.b.c.d' and see if that particular client is not making connection attempts to seemingly random IPs 2) add a flag 'bypass-dns' to the "redirect-gateway" directive if that is used on the client side to ensure that your DNS server is still reachable after the VPN comes up A short analysis of your problem is: - it works the first time a client connects - after a reconnect/wifi drop , the client resolves the remote host to the wrong IP conclusion: either the DNS server setting is modified OR the route to the DNS server is altered by the VPN. HTH, JJK ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
