VPN for 50+ branches on the knee

There was a need to make a VPN for an outsourcing company - to communicate with the networks of client companies in such a way that the admins of the customer and their own network saw every client host behind the NAT and the opposite was not possible. Hardware solutions were not considered in principle because of cost, and all proprietary software solutions were eliminated for the same reason. Only free software remained. The benefit of free solutions is more than enough

Since I started to get familiar with freeBSD free systems, I chose it. Immediately I ask the habra people not to plant a holivar on BSD vs Linux - the main reason for choosing was a deeper knowledge of this system (I still cannot master Linux enough to be confident in the results of my work with it). Actually, it was decided to organize the VPN on the basis of OpenVPN - again, I had to deal with it before, and I did not find any flaws. And again I will ask without a holivar on PPTP - if there are supporters of such a decision, it is better to write your article.

The customer also voiced the requirement for ease of management. So that in which case the employees of the customer could correct the configs on a piece of paper for specific needs.
Well, I needed full monitoring of the traffic passing between the networks and access through authorization in AD (the customer has Kerio Winroute Firewall on the main gateway)
So, summing up the requirements, got the following:
- Minimum equipment cost
- Ease of management
- Deployment speed
- Access control
Details of the solution - under the cut
The task of easy management, naturally, was reduced to the choice of a distribution kit with a user-friendly web interface. The choice fell on pfSense:

1. Minimum requirements for hardware - works on PII / 128RAM;
2. Stable, bug-free web-face - even an enikeyschik, superficially familiar with network technologies, will figure it out;
3. Installation in 10 minutes - saving all settings in one XML file;
4. In addition, as a bonus, a large amount of software, which is also controlled from the web interface and the whole set of software for FreeBSD, if something specific is needed.
')
What we actually did in steps:
1. Delivered to a virtual machine (on XEN) net FreeBSD 8.2, which was given one core and 256 memory
2. OpenVPN is installed (just #pkg_add -r openvpn20)
3. Compiled OpenVPN config with the following content:

port 1194 # which port to knock clients
proto udp our choice of UDP
dev tap # was chosen for addressing reasons - I didn't want to see a bunch of tunnels

#keys
ca /usr/local/etc/openvpn/keys/ca.crt
cert /usr/local/etc/openvpn/keys/server.crt
key /usr/local/etc/openvpn/keys/server.key
dh /usr/local/etc/openvpn/keys/dh1024.pem

# server`s IP
server 10.17.0.0 255.255.0.0 # actually, server IP
push "route 10.17.0.0 255.255.0.0" # route clients for our VPN
push "route-gateway 10.17.0.1" For some reason it did not work without it, although it should
client-config-dir ccd # directory in which client configs are located
client-to-client # allow clients to see each other
route 10.17.0.0 255.255.0.0 # route for our VPN
#authentification
tls-server # force TLS
tls-auth keys / ta.key 0
tls-timeout 120
auth MD5 # force MD5
cipher BF-CBC # force to encrypt
keepalive 10 120
comp-lzo # compress traffic
max-clients 4000 # taken from the ceiling
user nobody # for paranoia and system philosophy
group nobody
persist-key

#logging
status /var/log/openvpn/openvpn-status.log
log /var/log/openvpn/openvpn.log
verb 3

I do not think it is necessary to paint the configuration completely - there are enough specific articles.

4. Actually, I added all this to autoload:

server # more /etc/rc.conf

defaultrouter = "192.168.0.247"
gateway_enable = "YES"
hostname = "server.nerv.local"
ifconfig_re0 = "inet 192.168.0.244 netmask 255.255.255.0"
keymap = "ru.koi8-r"
sshd_enable = "YES"
openvpn_enable = "YES"
openvpn_if = "tap"
openvpn_configfile = "/ usr / local / etc / openvpn / server"
openvpn_dir = "/ usr / local / etc / openvpn"
startroute_enable = "YES"

IP distribution to clients is carried out from the ccd directory files - this is clear from the config on this, the entire server setup is complete - again I will not describe the generation of keys - this is all very correctly and detailed, for example, here: www.lissyara.su/articles/freebsd/ security / openvpn

Only one line is written in the client file in the ccd directory:
ifconfig-push 10.17.0.131 255.255.0.0 # give the client a specific address with a mask
All operations to raise the combat server on the customer's hardware were completed in 20 minutes, not counting the creation of keys.

It took some shamanism to set up clients - but they did not have to force enikeyschikov to touch the console. In the article I just give instructions for action, which was issued to the customer:

========== OpenVPN client configuration on pfSense ======
1. System> Cert Manager> CA tab
add new CA
1. In the Descriptive name field enter an arbitrary identifier;
2. in the Method list, select "Import an existing Certificate Autority"
3. in the field Certificate data enter the contents of the ca.crt certificate
save
2. System> Cert Manager> Certificates tab
add a new client certificate
1. In the Method list, select “Import an existing Certificate”
2. in the field Descriptive name enter an arbitrary identifier;
3. in the field Certificate data enter the contents of the certificate name_client.crt
4. in the field Private key data enter the contents of the file name_client.key
save
3. VPN menu> OpenVPN> Client tab
add new connection
1. In the list of Server Mode, select Peer to Peer (SSL / TLS)
2. UDP protocol
3. Device mode - TAP
4. Interface - WAN
5. local port - left blank
6. server host or address enter the ip-address of the server
7. server port 1194
8. proxy do not fill
9. In the TLS Authentication section, uncheck the box (Automatically generate a shared TLS authentication key)
10.In the field that opens, enter the contents of ta.key
11.Peer Certificate Authority choose what you entered in section 1.1
12. In the Client Certificate list, select the one that you entered in section 2.2
13. In the Encryption algorithm list, select BF-CBC (128 bit)
14. In the Compression field, put a tick (Compress tunnel packets using the LZO algorithm)
15 in the Advanced field enter
auth MD5
ns-cert-type server
persist-key
verb 3
save If everything is done correctly, then in 15-45 seconds the connection will become active.
4. Select the menu item Interfaces -> (assign)
1. Add a new interface with the "+" button
2. Select the ovpnc1 interface in the drop-down list, press the “Save” button
3. Select the menu item Interfaces -> OPT1, tick the “Enable interface” checkbox, click “Save”, click the “apply change” button
4. In the Description line, enter the VPN, select “Static” in the Type list, enter the VPN client address in the “Static IP configuration” field that appears and select the mask 16 (do not enter the gateway !!!)
5. If there are checkmarks in the Private networks section - remove them and click the “Save” button
5. Select the menu item Firewall -> NAT
1. select the Outbound tab
2. Put the mode switch to manual mode (right position) and press save
3. In the NAT list, add a new option by pressing the "+" button
4. In the Interface field, select OpenVPN (not VPN !!!)
5. in the Source field enter the address of the local network (this is usually 192.168.x.0 / 24) and select the mask
6. In the Destination field enter the network 10.17.0.0 and mask 16
7. In the Translation field, tick the Static port
8. Press the SAVE button.
======================================

Naturally, pfSense should be configured as the main gateway on the client’s client side.

And finally, the last step is setting up access from the customer's network to the customer's network: an OpenVPN client was raised on the customer's gateway (using the OpenVPN-GUI) and static routes to the networks were registered through the IP addresses of the network 10.17.0.0/16

That's all that was needed. The only requirement for the simplicity of setting up this scheme is that the networks of all clients must be different. For the customer, this condition turned out to be simple - where the networks coincided, everything was reconfigured without problems and completely remotely via the same VPN network.