Setup muliple site office with point-to-point ipsec vpn and separate DC

I used NethServer as a firewall/UTM/VPN appliance to setup a multi-site network today. The documentation seemed to be lacking a bit, so I thought I’d fill in the gaps with a howto. It’s more of a list of screenshots per site rather than a step-by-step how to.

In this test setup, I used the 192.168.99.0 subnet as the WAN. I have about 150 available public IPs left on my fiber connection, but they’re all on the same subnet too, so there’s really no difference in using the 99.0 subnet and actual public IPs… plus I don’t have the blur things out this way. :smile:

I had these packages installed on all three NethServer instances to accomplish this setup:

Test network/site #1:


This is the “main site” aka corporate headquarters.
eth0: WAN
eth1: LAN for AD DC, desktops, etc
eth2: LAN for PBX and phones
eth3: public wifi

DHCP setup for network/site #1:


The AD DC is handling DHCP and DNS for eth1, which is why it’s disabled for that adapter. You can see its IP listed as the DNS server for eth2.

IPsec setup for network/site #1 to network/site #2:


Local subnets field is cut off, but says 192.168.1.0/24,192.168.0.0/24

IPsec setup for network/site #1 to network/site #3:

Test network/site #2:


Remote site #1 is a small office with only 1 green zone and 2 red zone

DHCP for network/site #2:


My test domain at the corporate headquarters is “lan.local” I had to fill that in for DNS to resolve properly.

IPsec for network/site #2 to network/site #1:


I noticed the VPN would not establish connection until after rebooting this NethServer instance. The log was producing an error that it could not authenticate.

Test network/site #3 is another small remote office:

DHCP for network/site #3:

IPsec for network/site #3 to network/site #1:

Had to reboot this instance too before the vpn would connect. Then everything worked great!

PCs in remote locations can join the domain, map drives, place phone calls, etc… all using the server and PBX in the main location.

4 Likes

I can’t see any error log extract in your post…

so, the fact everything is working could be just a lucky event.

you’d always post error messages, to make readers able to help diagnose and eventually identify the source

Since it was consistent between both of the “remote” NS instances, I’d say it was more than luck or lack there of. It seemed like a service that needed to be restarted before it would authenticate. I’m not sure which. I just thought I’d add that because it could be frustrating if I skipped something as simple as a quick reboot.

Since you seem interested to see what was logged before the reboot, here ya go! :smile:

On site/network #2 NS instance:

Sep 24 15:41:45 ns-test3 pluto[21164]: packet from 192.168.99.178:500: received Vendor ID payload [Openswan (this version) 2.6.32 ]
Sep 24 15:41:45 ns-test3 pluto[21164]: packet from 192.168.99.178:500: received Vendor ID payload [Dead Peer Detection]
Sep 24 15:41:45 ns-test3 pluto[21164]: packet from 192.168.99.178:500: received Vendor ID payload [RFC 3947] method set to=109 
Sep 24 15:41:45 ns-test3 pluto[21164]: packet from 192.168.99.178:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03] meth=108, but already using method 109
Sep 24 15:41:45 ns-test3 pluto[21164]: packet from 192.168.99.178:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] meth=106, but already using method 109
Sep 24 15:41:45 ns-test3 pluto[21164]: packet from 192.168.99.178:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02] meth=107, but already using method 109
Sep 24 15:41:45 ns-test3 pluto[21164]: packet from 192.168.99.178:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-00]
Sep 24 15:41:45 ns-test3 pluto[21164]: packet from 192.168.99.178:500: initial Main Mode message received on 192.168.99.179:500 but no connection has been authorized with policy=PSK

On site/network #1 NS instance:

Sep 25 11:41:36 ns-test pluto[3258]: ERROR: asynchronous network error report on eth0 (sport=500) for message to 192.168.99.178 port 500, complainant 192.168.99.178: Connection refused [errno 111, origin ICMP type 3 code 3 (not authenticated)]

Obviously these locations are in different time zones. LOL

1 Like

Good stuff! Thanks for your effort.
@davide_Marini what do you think?

1 Like

One of the main reasons why I was looking into setting up Nethserver was for this scenario in particular. I’ve finally got a chance to work on it this weekend. One thing to note - I don’t have a deep understanding of networking. I have enough to get by so some of my questions or assumptions will be based on that context.

Here’s my scenario:
My network is set up such that we have both cloud instances as well as local instances. The cloud instances is where our main configuration (or in your scenario main office) will be and then we have local instances that will act similar to your remote offices. One thing to note is that our remote offices do not have fixed IP addresses. I’d like to setup permanent connection between the two and I feel like IPSec seems like the more standard way to go.

My general objective to allow users to connect to the main/cloud instance but have connection to a number of machines in the local instances

Can I use IPSec in this instance? The reason I ask is that in the example above the Remote IP of the IPSec tunnel is provided. In this case was the IP address of 192.168.99.178 assigned through another service? In my case the remote IP addresses of the local instances are out of my control as they are provided by a third party provider and the IPs do change from time to time

There’s a package for dynamic dns services. It sounds like you’ll need to set that up for your local instances. However, I’m not sure if nethserver will resolve a hostname if entered in place of a static ip in the ‘Remote IP’ field. Anyone have that answer?

It should work even with the hostname address.
At least you can try by setting it using db command from shell and check if the ipsec deamon works.

1 Like

I’m including how my network is setup

To add to the complexity, the nethbridge server sits behind another networking layer. Will this cause complications? I will try the dynamic dns package. I love how full featured Nethserver is.

Our best Ipsec specialists are @filippo_carletti and @davide_marini, hopefully they can give some hints here.

Pre shared key usually looks like:
-----BEGIN OpenVPN Static key V1-----
6fc7b4442bb9fee45a1bb21911922876
bunch of numbers and letters…
675e219efdb3c81b82440f1cab039c77
6b0304122ccccfcf10e2fa4fe785c300
-----END OpenVPN Static key V1-----

What i should put in the pre-shared keys box in IPSec tunnel tab?
The name of the file or its content?