Issue with multiple VPN clients connectivity

[nerevar83]

I'm trying to link 3 locations togheter as in this graphic (via OpenVPN - pc client and 2 asus routers). The purpose is to be able to access both equipments from the pc(they have web interfaces) and the equipments should also be able to communicate to one another. This network was once operational but it lost the main router and i'm trying to recreate it as it once was since i dont want to screw with the equiments settings. Im having issues with connectivity to equipment 2, im not sure what setting im missing on router 1 to be able to see the equipment behind router 2. From router 1 i can ping everything but from the pc i cant ping router 2 and anything behind it. If i trace to router 2 i hit router 1 gateway and it then sends me to the ISP server. These are the vpn settings on the router

https://imgur.com/a/rMZ8r5d

Router 1 is a rt-ac51u and router 2 is a rt-n18u.

 

[somms]

but from the pc i cant ping router 2 and anything behind it.

Just confirmed on my OpenVPN TAP config: https://www.snbforums.com/threads/s...rk-bridge-over-the-internet.72453/post-688044

If I remove the client-to-client option from server config, I too can no longer ping remote OpenVPN client router (or anything else behind it) from a 3rd remote OpenVPN client...BTW: you may want to reconsider your current compression setting considering the advice from OpenVPN 2.5 man: https://build.openvpn.net/man/openvpn-2.5/openvpn.8.html

--compress algorithm

DEPRECATED Enable a compression algorithm. Compression is generally not recommended. VPN tunnels which use compression are susceptible to the VORALCE attack vector.

The algorithm parameter may be lzo, lz4, lz4-v2, stub, stub-v2 or empty. LZO and LZ4 are different compression algorithms, with LZ4 generally offering the best performance with least CPU usage.

The lz4-v2 and stub-v2 variants implement a better framing that does not add overhead when packets cannot be compressed. All other variants always add one extra framing byte compared to no compression framing.

If the algorithm parameter is stub, stub-v2 or empty, compression will be turned off, but the packet framing for compression will still be enabled, allowing a different setting to be pushed later. Additionally, stub and stub-v2 wil disable announcing lzo and lz4 compression support via IV_ variables to the server.

Note: the stub (or empty) option is NOT compatible with the older option --comp-lzo no.

*Security Considerations*

Compression and encryption is a tricky combination. If an attacker knows or is able to control (parts of) the plain-text of packets that contain secrets, the attacker might be able to extract the secret if compression is enabled. See e.g. the CRIME and BREACH attacks on TLS and VORACLE on VPNs which also leverage to break encryption. If you are not entirely sure that the above does not apply to your traffic, you are advised to not enable compression.

 

[nerevar83]

That was it thank you. I guess it was one of those times you miss the obvious.