It’s been a couple of years, but I think it was this:
Ok, I’ll set up a new Test-NethServer, using this instruction and see how far I get.
I’ll get back to you, but might be in 1-2 hours.
I’ll try to connect to the same Site I’m presently using.
Dinnertime here… 
1 Like
Yeah, I have some actual work to do too. Thanks for all the help, though, and at least it seems like I wasn’t missing something totally obvious. For the time being, I’m going to disable IPsec, delete that route via 173.249.19.1, and re-enable OpenVPN.
1 Like
Something in your setup is screwed up, now just need to pinpoint the problem…
Step one in solving an issue!
Hi Dan
Took a while, but i did want to replicate as accurate as possible your situation.
So I had to first grab me the Centos 7 minimal, and set up a basic centos like on a hoster.
This time I only allocated one network interface.
I followed more or less exactly this instruction - judging from the IP, most likely the same as you did…
https://wiki.nethserver.org/doku.php?id=virtual_network_interface&s[]=dummy
Installed Centos 7 minimal:
Then added the “dummy”.
Configured the VPN - as yesterday, but with the relevant differences:
First time up, however:
I did forget first time to adapt the target network on the other side, corrected.
It still took several restarts on the VPN (on both sides!) entailing me having to switch several times from Home WLan to Mobile Hotspot WLan…
And things start to look better:
Pinging from Side B to my “hosted” NethServer worked:
Pinging the other side took one or two restarts, but finally worked:
The route to Side B (192.168.43.0/24) gets set automatically - and also removed, when the VPN is stopped.
Bottom Line:
- IPsec does work from such a “hosted” setup.
- It does seem faster than OpenVPN - but I’d need to do some serious tests before making a definitive statement.
- I will (later on) do a backup on the other side with OpenVPN and one with IPsec, just to compare. I do need to create a backup destination on the other side’s NAS.
- This whole setup was created using Centos 7.8.2003 minimal (ISO) ob Proxmox, also with double NAT.
- The Other end uses OPNsense, virtually feature and setup identical to a current PFsense.
Ergo (The BIG conclusion):
Either there’s a difference somewhere on the way from your setup to mine, implying differences in Versions at the time of installation, accumulated till current today.
Maybe software installations / testing / OpenVPN / whatever unknown is interfering with the correct setup of IPsec and routing on your setup. This could be some minor, easily overlooked detail, like wrong permissions on some routing file set by starting the VPN. And not able to remove or correct the settings therein…
It could also be the digitalised version of Murphy, throwing a digital wrench into the gearbox just for the kicks…
\
\
\
Possible Solutions?
If this were my server, I’d want it fixed, just not to run into lurking issues in the future.
And routing / VPN I consider basic musts!
Complete reinstallation with Centos 7.8.2003, install NethServer over this.
Test Backup / VPN
Restore Data and config and re-test VPN
Depending what you actually have / use and run on your external NethServer and also if you used that box to run tests, it might be worth it!
I leave it up to you to decide, I just wanted to try to collect the facts, as identical to your environment as possible. As in good law: Present the pure facts, envision and present the follow up logic, and let the court decide if this is sound!
Installing a minimal OS like Centos, and NethServer over it is not quite the same thing as installing NethServer directly, but is certainly much closer than eg a debian install, then Proxmox over that. Just bootable ZFS stuff alone can be a headache in Debian, whereas in Proxmox this is really smooth…
So it’s not really a bug, but something “irregular” on your system not allowing correct routing…
My 2 cents
Andy
1 Like