[Openvpn-users] OpenVPN for retro network
Hello List, I working on some unconventional setup for RETRO OSes... The setup is: -- openvpn -- internet -- openvpn -- retro network The servers range from old versions of Novell Netware like 2.x 3.x 4.x, Solaris, Windows NT and alikes running old protocols like ipx/spx and some even use not standard Ethernet frame types like: In NetWare, frame types are an issue only for Ethernet networks, those that use the CSMA/CD (Carrier Sense Multiple Access with Collision Detection) media access method on a bus topology. On Token-Ring and other networks, IPX/SPX has always used the IEEE 802.2 frame format. Over the years, several frame types have been defined for Ethernet: Ethernet II IEEE 802.3 "raw" IEEE 802.3 with 802.2 IEEE 802.3 with 802.2 SNAP Before I spending more time on this can OpenVPN 2.6.3 bridged network transport all these? I would like to bridge those old VMs just like they would be on a local LAN. If not what else solution can you recommend? One end on that server must be software only, can be some old cisco vpnc with a cisco appliance on the other end or kame ipsec etc. Thanks ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
[Openvpn-users] TLS key negotiation failed to occur ISP screws up the VPN
Hello Folks, I have a VPN setup which works since years it's a simple peer to peer udp VPN. There was absolute zero change on the two endpoints, nothing on the routers, network equipment, servers etc. The VPN simply stopped functioning like a week ago with no reason. I have pretty much restarted all components (of course did not change anything). I get this in the log on the server: RFri May 17 13:22:15 2024 us=116136 TLS: Initial packet from [AF_INET]:39729, sid=77d2b662 053040f3 WWWWrrWrFri May 17 13:23:15 2024 us=858988 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) Fri May 17 13:23:15 2024 us=859084 TLS Error: TLS handshake failed Fri May 17 13:23:15 2024 us=859405 TCP/UDP: Closing socket Fri May 17 13:23:15 2024 us=859487 Closing TUN/TAP interface Fri May 17 13:23:15 2024 us=859528 /sbin/ip addr del dev tun1 local 10.0.0.1 peer 10.0.0.2 Fri May 17 13:23:15 2024 us=936860 SIGUSR1[soft,tls-error] received, process restarting Fri May 17 13:23:15 2024 us=937343 Restart pause, 300 second(s) Fri May 17 13:28:15 2024 us=939065 Diffie-Hellman initialized with 2048 bit key Fri May 17 13:28:15 2024 us=942435 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication Fri May 17 13:28:15 2024 us=942581 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication Fri May 17 13:28:15 2024 us=943674 Control Channel MTU parms [ L:1557 D:1184 EF:66 EB:0 ET:0 EL:3 ] Fri May 17 13:28:15 2024 us=947603 TUN/TAP device tun1 opened Fri May 17 13:28:15 2024 us=949077 TUN/TAP TX queue length set to 100 Fri May 17 13:28:15 2024 us=949249 do_ifconfig, tt->did_ifconfig_ipv6_setup=0 Fri May 17 13:28:15 2024 us=949702 /sbin/ip link set dev tun1 up mtu 1500 Fri May 17 13:28:15 2024 us=961794 /sbin/ip addr add dev tun1 local 10.0.0.1 peer 10.0.0.2 Fri May 17 13:28:15 2024 us=975521 Data Channel MTU parms [ L:1557 D:1269 EF:57 EB:395 ET:0 EL:3 ] Fri May 17 13:28:15 2024 us=975855 Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1557,tun-mtu 1500,proto UDPv4,ifconfig 10.0.0.2 10.0.0.1,keydir 0,cipher AES-256-CBC,auth SHA1,keysize 256,tls-auth,key-method 2,tls-server' Fri May 17 13:28:15 2024 us=976030 Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1557,tun-mtu 1500,proto UDPv4,ifconfig 10.0.0.1 10.0.0.2,keydir 1,cipher AES-256-CBC,auth SHA1,keysize 256,tls-auth,key-method 2,tls-client' Fri May 17 13:28:15 2024 us=976118 Could not determine IPv4/IPv6 protocol. Using AF_INET Fri May 17 13:28:15 2024 us=976236 Socket Buffers: R=[163840->163840] S=[163840->163840] Fri May 17 13:28:15 2024 us=976352 UDPv4 link local (bound): [AF_INET][undef]:43000 Fri May 17 13:28:15 2024 us=976428 UDPv4 link remote: [AF_UNSPEC] RFri May 17 13:28:16 2024 us=563831 TLS: Initial packet from [AF_INET]:45086, sid=94460619 1b42cb70 WWrrWrrrWrWrFri May 17 13:29:16 2024 us=241264 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) Fri May 17 13:29:16 2024 us=241385 TLS Error: TLS handshake failed Fri May 17 13:29:16 2024 us=242113 TCP/UDP: Closing socket Fri May 17 13:29:16 2024 us=242322 Closing TUN/TAP interface Fri May 17 13:29:16 2024 us=242433 /sbin/ip addr del dev tun1 local 10.0.0.1 peer 10.0.0.2 Fri May 17 13:29:16 2024 us=356949 SIGUSR1[soft,tls-error] received, process restarting Fri May 17 13:29:16 2024 us=357112 Restart pause, 300 second(s) Fri May 17 13:34:16 2024 us=357823 Diffie-Hellman initialized with 2048 bit key Fri May 17 13:34:16 2024 us=358991 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication Fri May 17 13:34:16 2024 us=359037 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication Fri May 17 13:34:16 2024 us=359179 Control Channel MTU parms [ L:1557 D:1184 EF:66 EB:0 ET:0 EL:3 ] Fri May 17 13:34:16 2024 us=359788 TUN/TAP device tun1 opened Fri May 17 13:34:16 2024 us=359859 TUN/TAP TX queue length set to 100 Fri May 17 13:34:16 2024 us=359905 do_ifconfig, tt->did_ifconfig_ipv6_setup=0 Fri May 17 13:34:16 2024 us=359947 /sbin/ip link set dev tun1 up mtu 1500 Fri May 17 13:34:16 2024 us=365445 /sbin/ip addr add dev tun1 local 10.0.0.1 peer 10.0.0.2 Fri May 17 13:34:16 2024 us=371612 Data Channel MTU parms [ L:1557 D:1269 EF:57 EB:395 ET:0 EL:3 ] Fri May 17 13:34:16 2024 us=371770 Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1557,tun-mtu 1500,proto UDPv4,ifconfig 10.0.0.2 10.0.0.1,keydir 0,cipher AES-256-CBC,auth SHA1,keysize 256,tls-auth,key-method 2,tls-server' Fri May 17 13:34:16 2024 us=371808 Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1557,tun-mtu 1500,proto UDPv4,ifconfig 10.0.0.1 10.0.0.2,keydir 1,cipher AES-256-CBC,auth SHA1,keysize 256,tls-auth,key-method 2,tls-client' Fri May 17 13:34:16 2024 us=371841 Could n
Re: [Openvpn-users] TLS key negotiation failed to occur ISP screws up the VPN
Dude why do you say it is not responding when it clearly is both on the log file and tcpdump? WRWrrRWWRWrWRWFri May 17 15:42:17 2024 us=59314 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) Isn't that r read socket w write socket plus on the tcpdump you can see that there are in and out packages. No it does not use multiple interfaces. To make it even more annoying there is another point to point tunnel terminated there same udp on a different port which works fine even restating it so this is why I say this might be some blocking/slowdown/crapping coming from the isp. Time is correct on the machines, certs expire in 2049. Sent with Proton Mail secure email. On Friday, May 17th, 2024 at 12:38 PM, Antonio Quartulli wrote: > Hi, > > On 17/05/2024 14:12, shadowbladeee via Openvpn-users wrote: > > > So here is what is interesting, packets are "sipping in" so you cannot say > > it's a firewall issue, especially as I said nothing changed from my side > > and all the components were even rebooted. > > > > Here is what I tried: > > > > 1, tried to move the udp port -> didn't help > > > > 2, switched from udp to tcp -> didn't help > > > Am I right saying that both log and tcpdump output are from the endpoint > that "receives" the connection? (i.e. the server). > > If that's the cas,e we see the server that does not reply (tcpdump), but > also does not print any reason for rejection. > > I wonder if the server is sending its reply over another interface and > thus getting lost? > > Have you tried running tcpdump with '-i any'? > > Regards, > > > -- > Antonio Quartulli ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] TLS key negotiation failed to occur ISP screws up the VPN
Nope and btw OpenVPN does not care about the CRL unless you specifically define it in the config. I even use the same CA, client cert as on the other openvpn node on this host on other port so even that issue is excluded. The fact that it worked for years and now misbehaves with no reason the only logical thing is that the other isp where that node connects from breaks the connection. I have tried to lower the tun mtu to all the way down to 1200 does not help at all as it does not even get to the point to establish any tunnel :/ Sent with Proton Mail secure email. On Friday, May 17th, 2024 at 2:01 PM, Jochen Bern wrote: > On 17.05.24 15:49, shadowbladeee via Openvpn-users wrote: > > > Time is correct on the machines, certs expire in 2049. > > > Any CRLs that might have expired? > > I note that the tcpdump shows only quite small packets. MTU issues > that could lead to (persistent) loss of large ones from the other end? > > Kind regards, > -- > Jochen Bern > Systemingenieur > > Binect GmbH > ___ > Openvpn-users mailing list > Openvpn-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/openvpn-users ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] TLS key negotiation failed to occur ISP screws up the VPN
Sat May 18 09:40:24 2024 us=695267 TUN READ [60] Sat May 18 09:40:25 2024 us=715627 TUN READ [60] Sat May 18 09:40:27 2024 us=795669 TUN READ [60] Sat May 18 09:40:31 2024 us=875634 TUN READ [60] Sat May 18 09:40:37 2024 us=96530 [UNDEF] Inactivity timeout (--ping-restart), restarting Sat May 18 09:40:37 2024 us=97013 TCP/UDP: Closing socket Sat May 18 09:40:37 2024 us=97165 SIGUSR1[soft,ping-restart] received, process restarting Sat May 18 09:40:37 2024 us=97278 Restart pause, 5 second(s) Sat May 18 09:40:42 2024 us=97476 Re-using SSL/TLS context Sat May 18 09:40:42 2024 us=97976 Control Channel MTU parms [ L:1557 D:1184 EF:66 EB:0 ET:0 EL:3 ] Sat May 18 09:40:42 2024 us=123404 Preserving previous TUN/TAP instance: tun1 Sat May 18 09:40:42 2024 us=123660 Data Channel MTU parms [ L:1557 D:1450 EF:57 EB:395 ET:0 EL:3 ] Sat May 18 09:40:42 2024 us=123845 Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1557,tun-mtu 1500,proto UDPv4,ifconfig 10.0.0.1 10.0.0.2,keydir 1,cipher AES-256-CBC,auth SHA1,keysize 256,tls-auth,key-method 2,tls-client' Sat May 18 09:40:42 2024 us=123918 Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1557,tun-mtu 1500,proto UDPv4,ifconfig 10.0.0.2 10.0.0.1,keydir 0,cipher AES-256-CBC,auth SHA1,keysize 256,tls-auth,key-method 2,tls-server' Sat May 18 09:40:42 2024 us=124013 TCP/UDP: Preserving recently used remote address: [AF_INET]:43000 Sat May 18 09:40:42 2024 us=124121 Socket Buffers: R=[163840->163840] S=[163840->163840] Sat May 18 09:40:42 2024 us=124191 UDP link local: (not bound) Sat May 18 09:40:42 2024 us=124269 UDP link remote: [AF_INET]:43000 Sat May 18 09:40:42 2024 us=124486 UDP WRITE [42] to [AF_INET]:43000: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 pid=[ #1 ] [ ] pid=0 DATA len=0 Sat May 18 09:40:42 2024 us=124851 TUN READ [60] Sat May 18 09:40:44 2024 us=287471 UDP WRITE [42] to [AF_INET]:43000: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 pid=[ #2 ] [ ] pid=0 DATA len=0 Sat May 18 09:40:45 2024 us=728789 TUN READ [60] Sat May 18 09:40:46 2024 us=755652 TUN READ [60] Sat May 18 09:40:48 2024 us=835630 TUN READ [60] Sat May 18 09:40:48 2024 us=835961 UDP WRITE [42] to [AF_INET]:43000: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 pid=[ #3 ] [ ] pid=0 DATA len=0 Sat May 18 09:40:52 2024 us=915608 TUN READ [60] Sat May 18 09:40:56 2024 us=90304 UDP WRITE [42] to [AF_INET]:43000: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 pid=[ #4 ] [ ] pid=0 DATA len=0 Sat May 18 09:41:01 2024 us=475633 TUN READ [60] Sat May 18 09:41:06 2024 us=762545 TUN READ [60] Sat May 18 09:41:07 2024 us=795663 TUN READ [60] Sat May 18 09:41:09 2024 us=875647 TUN READ [60] Sat May 18 09:41:12 2024 us=352579 UDP WRITE [42] to [AF_INET]:43000: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 pid=[ #5 ] [ ] pid=0 DATA len=0 Sat May 18 09:41:13 2024 us=955606 TUN READ [60] Sat May 18 09:41:22 2024 us=595711 TUN READ [60] Sent with Proton Mail secure email. On Friday, May 17th, 2024 at 5:29 PM, Selva Nair wrote: > Hi, > > > Fri May 17 13:23:15 2024 us=936860 SIGUSR1[soft,tls-error] received, > > process restarting > > Fri May 17 13:23:15 2024 us=937343 Restart pause, 300 second(s) > > If this is the tls-server side of the p2p connection, this is weird. What > version of OpenVPN is this? > We fixed the backoff logic in 2.5.3 to delay only on one side (the > client-side iirc) as otherwise the two sides could miss each other and lead > to timeout. > > Could you please post matching logs from the other side as well? > > Selva > > On Fri, May 17, 2024 at 8:15 AM shadowbladeee via Openvpn-users > wrote: > > > Hello Folks, > > > > I have a VPN setup which works since years it's a simple peer to peer udp > > VPN. There was absolute zero change on the two endpoints, nothing on the > > routers, network equipment, servers etc. The VPN simply stopped functioning > > like a week ago with no reason. I have pretty much restarted all components > > (of course did not change anything). I get this in the log on the server: > > > > RFri May 17 13:22:15 2024 us=116136 TLS: Initial packet from > > [AF_INET]:39729, sid=77d2b662 053040f3 > > WWWWrrWrFri May 17 13:23:15 2024 us=858988 > > TLS Error: TLS key negotiation failed to occur within 60 seconds (check > > your network connectivity) > > Fri May 17 13:23:15 2024 us=859084 TLS Error: TLS handshake failed > > Fri May 17 13:23:15 2024 us=859405 TCP/UDP: Closing socket > > Fri May 17 13:23:15 2024 us=859487 Closing TUN/TAP interface > > Fri May 17 13:23:15 2024 us=859528 /sbin/ip addr del dev tun1 local > > 10.0.0.1 peer 10.0.0.2 > > Fri May 17 13:23:15 2024 us=936860 SIGUSR1[soft,tls-error] received, > > process restarting > > Fri May 17 13:23:15 2024 us=937343 Restart pause, 300 second(s) > > F
Re: [Openvpn-users] TLS key negotiation failed to occur ISP screws up the VPN
YEss please do NOT, exactly what I wanted to say ;) Listen phal I been in IT since 15 years you can go on all day long with this restart this restart that stuff but 99.99% of the time if there is a working system there is a clear reason why that stops functioning and if the reason is not configuration change then in this case something related to the network in between those nodes. I can restart this thing all day long it will not make any difference. BTW I tried what you said multiple times with terminator where you can broadcast commands so the restart happens in the exact same time on both nodes. What makes it more annoying is there is another p2p vpn on another port on the same server using the same settings, same ca etc just terminated elsewhere and that works flawlessly so my best guess is the isp is screweing around with the packets. IF I ever find a solution for this I post it ;) On Saturday, May 18th, 2024 at 4:08 PM, Selva Nair wrote: > > > On Sat, May 18, 2024 at 12:00 PM Bo Berglund wrote: > > > On Sat, 18 May 2024 11:22:37 +0200, Gert Doering > > wrote: > > > > >Since you do not want to hear that, we won't tell you that 2.4.0 is > > >8 years old, and a zillion improvements went into what is now 2.6.10, > > > > Just curious: > > I am running openvpn server on an Ubuntu 22.04.4 LTS and here is what I get > > from > > apt: > > > Please do not hijack an ongoing discussion. Ask in a new thread. > > Selva ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
[Openvpn-users] Android DNS double connect bug
Hello List, I am using version 3.7.1 on Android 13, even tho I have noticed this behavior in earlier versions as well. The VPN server running on a Debian box, it pushes the default route and DNS servers to Android. This DNS server is a dnsmasq on that server which routes the requests (local ones with .lan extension) to the local DNS server, the rest to public servers. I noticed that many times after connecting this just don't work, the lan addresses stay unresolvable, I reconnect again and DNS works (until next reconnect). Anyone seen this behavior? Any workaround for it? I would be ok using dnsmasq on Android directly or even hosts file but sadly this cannot be done on unrooted phone :/ Thanks ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
