How to create site to site VPN for SMB with low IT budget. part1

July 19, 2017 by Munkhtuvshin Baatar
2 comments

It’s commonplace to connect multiple company branches and central office by VPN. For my customers for example it’s needed to :

  1. implement Active Directory (for small companies with single IT team – only one AD domain and multiple AD sites, everywhere if possible one AD DC)
  2. integrate into one DB all Time Attendance machines – one Zkteco application for accountant at central office connects thru vpn to each branch office zkteco T&A machine and remotely registers new fingerprints, syncs users/fingerprints for all sites, downloads everyday check-ins and check-outs.
  3. remote support thru RDP/dameware/idrac from central office
  4. access to company ERP/web and so on resources from branch office to central office and vice versa
  5. Video Management System/VMS, for example Milestone xProtect Mobile servers (only mobile server at central office published to Internet and accessible from smartphones, but recording servers at branch site, connection between them thru vpn). This is only one chance to access IP cameras from outside of company for branches without static IP, or without real dynamic IP.
  6. and so on

 

The easiest case to build site to site/s2s VPN is when central office and all branches have static real IP(s) and used professional routers/modems allows l2tp/ipsec site-to-site/s2s VPN. The majority manuals and instructions in the Internet are usually exactly for a such classic and the most recommended case (just differenet manuals for various vendors).

But real life cases are more diverse, there are many exceptions, special cases for SMB:

  1. first of all, classic approach is expensive (for example in Mongolia for remote suburban locations  10Mbit/sec triple[tv, internet, phone] home ISP service is about 20-30 usd/month, but ISP SLA with the same speed for companies with  static ip is more than 400 usd/month, 20 times more). For companies with multiple small/tiny branch shops or branch offices it’s too expensive.
  2. The majority small companies have just cheap wifi routers from tplink or dlink without any s2s vpn support.
  3. no cable connection is available (many large department stores provides renting areas for retail shop branches without any cabling, moreover some of them (for example Nomin Holding and State Department Store) prohibits any cabling – so no affordable ADSL + phone lines, no fiber or UTP). And the only alternative is wireless internet – mobinet wimax (since 07.01.2017 only LTE). But unlike wimax subscriptions, LTE subscriptions in Mongolia doesn’t allow real static IPs,
  4. the provided by ISP and demanded only to be used modem/routers cannot be replaced by own cisco or other vendors vpn routers. Univision smartbox, SkyTel ZTE routers for customers are deliberately limited in configuration abilities (all settings are done remotely by only ISP engineers)
  5. PPTP or vpn pass-through by some ISP can be blocked or not configured on intermediate routers
  6. no real IP for modem WAN port (Static, but fake IP)
  7.  and so on

So let’s consider that SMB company central office has good ISP SLA with static real IP(s), but they have the worst case at multiple small branch offices:

  1. monopolized market, without options and alternatives one ISP at needed geolocation
  2. only consumer level access to internet (no static real IP), maybe even only 80, 443 ports, only web proxy
  3. no cabling allowed by renting agreement, only wireless
  4. ISP devices/modems shouldn’t be replaced, full dependence on ISP support service
  5. vpn passthrough is blocked at ISP routers
  6. modem WAN port has dynamic IP, and this IP is not real IP address (DynDNS will not help us)
  7. and so on

So is it possible to create a rather stable s2s vpn in a such case?

Yes. We can use OpenVPN plus pfsense VM with openvpn support.

Why openvpn?

Usually 443 port is not blocked, openvpn client can reach openvpn server even thru proxy. OpenVPN client doesn’t need to have static real IP and in spite of own name “openvpn client” still provides site to site connection(whole network can work over a such VPN). Unlike pptp openvpn is not yet compromised  and vulnerable (just use latest version of OpenVPN without heartbleed bug). Moreover Microsoft RRAS demand-dial pptp vpn works only if both endpoints have static real IP.

Why pfsense (or other free alternative with openvpn support)?

Why not just another openvpn client/server (exists even for windows)? The reason is that to create s2s vpn each branch site should have unique subnet (to avoid later on routing problems). Some ISP not only limits you in the choice of equipment and access to the management of these foisted devices, but even limits you in the used subnets – so you cannot even change identical 192.168.0.0/24 subnet in several branches. Pfsense divides network to wan subnet (for pfsense it is “bad” 192.168.0.0/24 subnet) and lan subnet (you choose it), and you can use openvpn connection from new lan subnet (for example 172.16.101.0/24 for branch01; 172.16.102.0/24 for branch02 and so on)  to central office subnet. OpenVPN client on pfsense are configured for LAN interface. Surely it adds overheads and can make inter-site network slow, but you can add vcpu/vram for pfsense or eventually give up with hope to build s2s vpn.

Why VMs, virtualization? Why Hyper-V?

At first easy deployment (one template for pfsense VM just copied to multiple branch servers), easy backup, restore and so on. The whole suggested solution is software solution, no need to buy, change network hardware (agree that it’s not so reliable and not so quick booting and so on, but flexible and almost for free). So to save on hardware we will use Hyper-V with debian(or other linux) openvpn VM server at central office and for each branch hyper-v server with pfsense VM.

For small branch offices (5-10 employees) Hyper-V will help to consolidate on one physical server VMs for pfsense, domain controller, file server and so on. In a such case Hyper-v is preferable also because of  the fact that UPS Powerchute, VM backup solutions can be installed directly on the hypervisor (unlike esxi which also doesn’t support many desktop drivers for NIC/storage; usually experts don’t like to overburden hypervisor by third-party software, but in budget all-in-one solution better to have data backups and smart power backups and consciously weigh risks). Other reason is that these Hyper-V servers can be ordinary desktop computer (at least i3 and at least 4gb RAM) with only one built-in NIC. Both WAN and LAN virtual networks for pfsense can be connected to one NIC (virtual switch) to already existing physical LAN switch (no need to install second NIC). We use pfsense not as a firewall (it implies that we already have ISP modem/router/firewall device which cannot be removed from the chain), but just as a router between branch networks. So you don’t need to place whole branch network behind this new Hyper-V server like behind firewall – just connect Hyper-V server to your branch office switch as another computer – that’s all. You even don’t need to run  “route add -p ….” commands on all branch computers to connect to the central office thru vpn if all computers access to internet now thru new pfsense as thru default gateway.

Hyper-V servers, physical servers should have in the CMOS BIOS power setting to autostart OS at restore of power after power failure (it’s true even if your server are protected by UPS and shutdowned via USB cable). The same for VMs (openvpn server and pfsense) they should autostart. Especially it’s true for branch office pfsense VMs – branch offices pfsenses initiate all vpn connections (they don’t have static ip so cannot be accessed/initiated by central office openvpn).

 

 

Conclusion:

Advantages of a such configuration:

  1. relatively cheap (in fact debian OpenVPN server and pfsense VMs are very modest in resources – 512mb of RAM is enough for small network traffics)
  2. 10-20 times less payments to ISP
  3. no dependence on ISP whim, no need to ask about vpn passthrough for pptp, l2tp/ipsec (usually foreign mining/construction companies in Mongolia are contractors and very dependent on customer IT network (for example ETT becomes sub ISP for them), limited in options)
  4. flexibility. solution works in any IT network environment, thru any dummy router/modem; works thru ADSL, wifi, cellular, 3G, LTE, fiber, UTP and so on
  5. no need in real static IP for branch offices
  6. better security than pptp s2s vpn, and comparable with L2TP/ipsec.