Totally fair that you don't want to apply a patch that you don't
understand. I on the other hand do not see why you're unable to reproduce.
The scenario is not at all complicated:
- Two vpn servers;
- first vpn server pushes a default gateway;
- second vpn server pushes its external IP as net_gateway (*);
- second vpn server immediately sees the client float from one IP to another.
What I understand so far:
- so you connect to vpn 1 first and that is a normal VPN with a default
gateway and you get VPN1 IP
- Then via that VPN, you connect a 2nd VPN and you have as source the
VPN IP, so the 2nd VPN server only see the VPN1 IP.
- after connection is established, you do the host route directly to
the server.
- 2nd VPN server sees a float from VPN1 IP to extern IP (EXTIP) of client
- Server refuses the float since there is already a not fully
established connection on EXTIP
What I don't understand where the this not fully established connection
should be coming from. That would mean that the server would have need
to have received a valid connection attempt from EXTIP that was never
established. And I do not understand from you explaination where that
happens.
If you're unable to reproduce that, then:
- Either you're using a vastly different version and it has been fixed
since then (but not something that landed in debian/bookworm or
ubuntu/noble, and I _think_ I did try latest 2.6 as well);
- or you're using different settings (udp; auth/tls-auth; dev-tun;
subnet-topology);
- or there is some unknown factor involved that neither of us can think or
right now.
I will create a reproducer config so you can see the exact settings (apart
from the IP addresses).
In the mean time, can you confirm that you understand the scenario or ask
for additional clarification?
I wrote again down what you basically told me and there is still this
mystery connection that blocks you. And there is no explaination why
this connection exist in the first place. You are fixing the sympton of
this ghost connection that blocks your float but from my perspective we
have not really established why it exists in the first place.
Arne
_______________________________________________
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
