In the case that C2 uses its own connection to the Internet, as you've shown, C2's default route should be to its own Internet connection. That will force C1 to use the VPN to get packets to C2, then C2 decides what to do with them. C1's default route should point to the VPN address of C2 as the router. Hopefully this is enough to answer your question and demonstrate that it's a lot easier to configure the VPN on the default gateway than it is to configure the VPN on a client, but there are use cases for both.Įdit: With this topology, and description of the problem, I believe there are routing issues on C1 and C2. ![]() This is assuming that C2 and C3's addresses are 192.168.2.2 and 192.168.3.2 respectively, and that C1 and C4 are on the same network as C2 and C3 respectively. Both of those routes should take precedence over the default. C1 sets the route to C4's network going VIA C2, and C4 sets the route to C1's network going VIA C3. That involves configuring the routing table on C1 and C4. The next is to get C1 to use C2 as the way to get packets to C4. The first hurdle is to get the OpenVPN tunnel established between C2 and C3, probably using port forwawding from R1 & R2 of UDP 1190 to C2 & C3 respectively. Where C2 and C3 are the OpenVPN endpoints and C1 should use the VPN to get to C4. This scenario is more difficult to get correct: C2 - R1 -(NAT)- Internet -(NAT)- R2 - C3 Here, if there's a (properly configured) OpenVPN tunnel created between R1 and R2, then C1 can talk to C2 and vice-versa. Though I think I can say that in general it is possible to do what you're asking.Ĭonsider the scenario below: C1 - R1 -(NAT)- Internet -(NAT)- R2 - C2 This seems to be problem with the OpenVPN server not wanting to send packets where they should go.Īnswering this completely is difficult without knowing the network topology you're trying to describe. I can route from C1 (and probably from C2) through S to the internet but routing through C2 does not work as the packets get forwarded by S instead. I want to route traffic from C1 through C2 to the internet. ![]() C1/C2/S can ping each other within the network no problem. The square brackets represent my virtual network (it does not physically exist). Is it possible to setup client as gateway for other clients in OpenVPN or is it property of the system that packets get routed by server event if the route on client is pointed onto other client? When i tcpdump on C2, there is no sign of anything arriving there. ![]() The problem is, that if I point C1 default route to C2, (Which is also properly configured to NAT traffic from VPN to internet) the traffic gets snatched by S anyway and forwarded by it. When I setup my default route on C1 to go through S (which does have ip forwarding and NATing enabled), everything works as expected. See for more info.įeb 17 13:59:34 ovpn-client2: NOTE: the current -script-security setting may allow this configuration to call user-defined scriptsįeb 17 13:59:34 ovpn-client2: TCP/UDP: Preserving recently used remote address: 198.13.36.179:1194įeb 17 13:59:34 ovpn-client2: Socket Buffers: R= S=įeb 17 13:59:34 ovpn-client2: UDP link local: (not bound)įeb 17 13:59:34 ovpn-client2: UDP link remote: 198.13.36.179:1194įeb 17 13:59:34 ovpn-client2: TLS: Initial packet from 198.13.36.179:1194, sid=f70eaa89 cb99bcb7įeb 17 13:59:34 ovpn-client2: VERIFY OK: depth=2, C=US, ST=New Jersey, L=Jersey City, O=The USERTRUST Network, CN=USERTrust RSA Certification Authorityįeb 17 13:59:34 ovpn-client2: VERIFY OK: depth=1, C=GB, ST=Greater Manchester, L=Salford, O=Sectigo Limited, CN=Sectigo RSA Domain Validation Secure Server CAįeb 17 13:59:34 ovpn-client2: VERIFY OK: depth=0, CN=*.įeb 17 13:59:34 ovpn-client2: Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, peer certificate: 2048 bit RSA, signature: RSA-SHA256įeb 17 13:59:34 ovpn-client2: Peer Connection Initiated with 198.13.36.I have OpenVPN network with one server and two clients. Feb 17 13:59:32 rc_service: httpd 512:notify_rc start_vpnclient2įeb 17 13:59:34 ovpn-client2: OpenVPN 2.5.5 arm-unknown-linux-gnu built on Jan 1 2022įeb 17 13:59:34 ovpn-client2: library versions: OpenSSL 1.1.1m, LZO 2.08įeb 17 13:59:34 ovpn-client2: WARNING: No server certificate verification method has been enabled.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |