Have been running Nethserver as VPN gateway for some time without a problem. Today I lost acces from VPN network and NS gateway to part of my LAN. The LAN is a /23 network. The ‘lower’ part is not reachable, the NS itself is on that lower part. The ‘upper’ part is reachable, so are several other routed networks (green).
The firewall log shows no drops while pinging from the NS to the LAN, but shows the following when pinging from a connected VPN client to the LAN:
Sep 22 22:24:12 vpn kernel: Shorewall:sfilter:DROP:IN=tunrw OUT=tunrw MAC= SRC=DST= LEN=64 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=TCP SPT=58614 DPT=443 WINDOW=65535 RES=0x00 SYN URGP=0
Disabeling the VPN makes the LAN reachable from the NS again.
The issue appeared out of the blue, I have no idea what triggered it. I tried al kind of settings for the VPN config but to no result.
Would you please post some informations?
Green Subnet
Blue Subnet (if present)
VPN subnet (OpenVPN or IPSec?)
VPN kind (routed or bridged?)
NSDC/AD present?
Worth the shot. So, could be an issue to you use another subnet instead of 192.168.101.0/24, for OpenVPN?
I’d go for 172.30.254.0/24, but feel free to do any kind of test/trick down this hill.
I’m delibeately avoiding 192.168.x.x.
The error was in the routing table. The LAN was routed twice, one of the entries pointing to an IP on the VPN network. I manually deleted the first entry and for now that resolves the issue.
… 192.168.30.0 192.168.101.2 255.255.255.0 UG 0 0 0 tunrw 192.168.30.0 0.0.0.0 255.255.254.0 U 0 0 0 enp1s0
…
( To delete the entry: route del -net 192.168.30.0 gw 192.168.101.2 netmask 255.255.255.0 dev tunrw)
The question remains: Where did that come from? I have no idea.
Found an entry in the VPN user database assigning a ‘remote network’ to a user. Put it there some weeks ago to test the purpose and forgot.
This entry in retrospect declared my LAN as a remote network and had a system wide impact through the kernel routing table. Bug or feature?
