Is it possible to reach client subnets from server side?

[lrodorigo]

As in the title, I am trying to reach a subnet on client side (192.168.0.0/24) from the server side. The first test I am trying to do, is to reach the vpn client from the vpn server, by using its ip on the eth0 interface. I am able to properly ping the VPN client by using the vpn adapter ip address.

192.168.9.1 <---(wsvpn)---> 192.168.9.2 on wsvpn if, 192.168.0.10 on eth0 if

• 192.168.9.1 has 192.168.0.0/24 via 192.168.9.2 entry on its routing table
• 192.168.9.2 masquerades the source IP if the source subnet is 192.168.9.0/24
• 192.168.9.1 uses 192.168.9.1 as source ip when trying to reach 192.168.0.10
• the IP forwarding is enabled on both client and server
• the FORWARD chain has ACCEPT policy on both

But it seems that a tcpdump on the VPN CLIENT wsvpn interface is not receiving packets sent on the wsvpn tunnel, when the destination ip is not the ip address of the wsvpn iface. Is it correct? Am I missing something?

Regards

Is it

[Doridian]

@lrodorigo Such configuration is possible with routing entries as you described, given a couple constraints: Either of the following (TAP/TUN mode selection here: https://github.com/Doridian/wsvpn/blob/main/server/cli/server.example.yml#L4 ):

• You run WSVPN in TAP mode (the ideal configuration for your use-case, as routers usually operate at L2)
• You run WSVPN in TUN mode with one-interface-per-connection mode enabled ( https://github.com/Doridian/wsvpn/blob/main/server/cli/server.example.yml#L30 ), otherwise the WSVPN server router has no way to know where to route packets, as TUN mode is at L4, thusly it can only tell which client to talk to via the destination IP, no MAC address present in the packets

Ideally, if you configure WSVPN to TAP mode, this should "just work", as in this case WSVPN itself behaves like a normal "dumb" L2 network switch with some basic sanity checks (see allow-ip-spoofing and allow-client-to-client for examples if you need more advanced configs with clients needing to do more)

In case I am off base and you already use TAP mode, feel free to respond and ideally provide config snippets or full configs (with secrets and privacy sensitive details such as IPs redacted)

[lrodorigo]

Solved by switching to tap mode and allowing IP spoofing in order to receive IP packets with a source ip coming from the destination subnet, I think it is possible to overcome this by performing a better masquerading configuration.