> On 7/5/24 16:32, Rodney W. Grimes wrote: > > >> However, I just changed UDP port and it seems to work! > > The "solution" didn't last: after a little more than 3 hours, this > tunnel stopped working again :( > > Strangely restarting openvpn on both sides fixed this, this time. > > > > > > Or host A has a zombie process with a UDP listen on the port? > > It's host B listening as a server: host A connects to it. > So I guess I should look into host B...
Host A *still* has/had a port open, and that port can lingere for several reasons, and that can cause issues. It can also happen on Host B, but we always look there, right? What I am getting at is you shouldnt assume the problem could not be on the orignating(client) end. > > And no, "netstat -na" show no udp4 line with the choosen port, after I > stop openvpn. Ok, good, check both A and B. > > To my ignorance, this reminds me of the "no buffer space available" I > sometimes get with ping. Thats usually a stuffed up tunnel that can't transmit for some reason. ppp will do this if it things the link is down for any reason. > That's just a wild guess, of course, but I suspect something is wrong > with UDP on the "server" host... MTU's? Have you manually checked path MTU to make sure that it can carry your payload correctly IN BOTH DIRECTIONS. I have seen asymetrical routes cause MTU issues due to it being smaller in one direction. > bye & Thanks > av. -- Rod Grimes rgri...@freebsd.org
