Can only access Nethserver over VPN

NethServer Version: 7.7.1908
Module: OpenVPN RoadWarrior

In my lab I’m trying to set up a Nethserver as a simple VPN “appliance”. I am port-forwarding the VPN traffic to this server.
The current config is a routed, cert only VPN. I am able to connect to the VPN from a Win10 OpenVPN client, but I can only connect to the Nethserver (ssh, https). No other IP’s in the network are accessible.
Any ideas?

[EDIT]
I have also noticed there is no default gateway listed for the tap nic. See image below.
FYI…the client side routes look correct.

Selection_230

[EDIT2]
The client can ping the server, but the server can’t ping the client’s TAP IP address.
Does this server route table look correct?
ip route show
default via 192.168.255.1 dev em1
10.99.99.0/24 via 10.99.99.2 dev tunrw
10.99.99.2 dev tunrw proto kernel scope link src 10.99.99.1
192.168.255.0/24 dev em1 proto kernel scope link src 192.168.255.13

Maybe this thread can help you:

https://community.nethserver.org/t/vpn-server-to-the-local-lan

This seems to be a real pain to set up…if it’s even possible. Seems like he never got it working.
I’ve set up a similar scenario with CentOS 7 and a Roadwarrior Script I’ve found on github. I was hoping NS would be an easy way to implement this build.
I’ll do some more digging and see what I can come up with.
Thanks.

Due to the concept, I think that current design of NethServer do not apply at all for a pure VPN endpoint/appliance to add on a network; VPN module is built (both for IPSec and OpenVPN) to allow connection from RED interface and create a route to hosts on GREEN, even to BLUE but it’s not be meant to be bridged or routed on RED.
Adding NethServer as a second gateway to your current network also won’t solve the issue if you don’t add a static route to OpenVPN subnet for all the hosts needed to be reached.

NethServer currently has to been put as default gateway of your network, for allowing you the connection via OpenVPN and IPSec.

@pike Thank you.

In my lab I’m trying to set up a scenario of remotely accessing a network that is an internal island.
So, I’m trying a different approach than I had before.

The Corp LAN(1), I’ve set up with an internal IP address. It is now a RED connection.
VPN traffic is still forwarding to this internal LAN1 port from the Crop firewall.
The Island LAN(2), is set up as a Green connection.
VPN does connect, but I still only see the IP address of the LAN2 Green port and nothing else.
I’m guessing this is a routing issue, but I don’t know what to do next.
I would have thought this config would have automatically routed correctly.
Any assistance would be GREATLY appreciated!

Would you please share the current network structure and subnetting of your lab?

Lab LAN: 192.168.255.0/24
Gateway: 192.168.255.1
DNS: 192.168.255.2
Red: 192.168.255.13

Island LAN: 10.210.13.0/24
Gateway: 10.210.13.1
Green: 10.210.13.13

VPN: 10.99.99.0/24

It’s a bit messy for my comprehension. I hope that will be readable for you, @tl5k5.

Site LAB
Subnet: 192.168.255.0/24
Gateway: 192.168.255.1
DNS: 192.168.255.2

Site Island
Subnet: 10.210.13.0/24
NethServer
Red Interface: 192.168.255.13/24, GW 192.168.255.1
Green Interface: 10.210.13.13
OpenVPN/Purple: 10.99.99.0/24

Don’t forget that due to this setup, all Island subnet will have full access to Lab LAN, no matter what.

For create some rules to filter traffic and access from Island to LAB, an interface must be add into Gateway 192.168.255.1 for connecting Island subnet, and the gateway must have firewall capabilities for create any kind of regulation.
If the device is currently uncapable of any of this two requiremens, LAB’s Gateway must be replaced or add another device (maybe another NethServer?) between LAB LAN and the current gateway

If Island access to LAN is not an issue, IMVHO there are two ways to achieve something similar on what you’re looking for.
Option 1: whole subnet accessible both ways and static route.
NethServer should be configured as
Green Interface: 192.168.255.13/24, GW 192.168.255.1
Blue Interface: 10.210.13.13/24
On LAB Subnet a static route must be applied to all device that must reach or being reachable from Island, using 192.168.255.13 as a gateway to reach 10.210.13.0/24.
Firewall rules must be added to grant access From island to LAB, because as stated into docs
https://docs.nethserver.org/en/v7/firewall.html

https://docs.nethserver.org/en/v7/firewall2.html#firewall-new-section
(please read both links carefully)

Option2: OpenVPN client configured on all devices who must access Island subnet.
Don’t forget that due to this setup, all Island subnet will have full access to Lab LAN, no matter what.
RoadWarrior server should

  • push all static routes
  • not allow client-to-client traffic
  • Route all client traffic through VPN must be disabled

Create a RoadWarrior user for every installation should access, reserve IP address for every user. An administrative user (Linux or windows do not matter) should be able to start the client and open the tunnel automatically.
Therefore, firewall rules for allow access to Island’s green network segment should be created, if necessary.

Both solutions are a bandaid, not a “real” (IMHO) solution. Which is using a gateway into LAB capable of having another “Green” interface for Island subnet.
This will ease deployment of
OpenVPN (not always possible for “not computers” like printers and NAS or something similar)
or static route (sometimes can lock you out from the device if not well written, some devices do not support static routes).
Maybe a LAB gateway with enough interfaces (why not, realized on NethServer) can be the “real” solution, with a “normal” router on Island site capable of being DHCP server and traffic regulator.

Mine are just options. Bandaids one and “real” one. There are plenty way to create solutions for desires. :wink:

3 Likes

Thank you. This points me in the right direction.
I really appreciate your help on this!!!

Thanks for marking as solution my post.
Did you had any success with one of my suggestion?
If answer is yes, please share what you choose and why.