The company’s office network is protected with CheckPoint firewall. The remote user access VPN solution to the sites is possible with use of CheckPoint secure remote client only. Unfortunately, there is no good VPN client for Linux platform and new editions of Microsoft OSs (like 64bit Vista) that works with CheckPoint firewall, at least for the firewall version in use (NGX60).
The solution:
OpenVPN is a free open source solution. Source code can be compiled to run on virtually any OS.
On the server side, Pfsense firewall is installed in the office, one interface of which is connected to the ISP router and is statically using one of the assigned External IPs. The other interface is connected to the local network. The drawing below shows the described configuration:
The problems with the solution and the ways to work around:
1. Routing issue:
In the regular setup of Pfsense OpenVPN, an unused subnet is used for VPN clients and is routed to the main LAN network. As in our case the Pfsense firewall is not the main GW in the target network, the default gateway for any host in the network is set to be a network main router or the main firewall node if routing is on the firewall. Therefore, the VPN subnet clients won’t be able to access the internal networks as the internal hosts will route the response packets through their default routers and it will never get back to the Pfsense firewall.
Solution:
One of the ways to fix it is to set additional route on the main router or firewall to re-route traffic targeting the VPN network to Pfsence node. In case the LAN is part of a broader Site to Site VPN community and the VPN clients will need to reach other sites’ networks, the new VPN subnet would need to be configured on all firewalls and all routing devices across the community.
Here is my solution to the problem:
Step 1: As our VPN community comprises of number of sites I used bridged VPN connections, solution described in http://doc.pfsense.org/index.php/OpenVPN_Bridging.
That is actually the way to provide OpenVPN remote client the main LAN IPs from a specific range. As a result the clients are in the main LAN network and can reach any host in it. The routing issue does not exist as the traffic is local to the LAN subnet and thus no GW is involved.
Additional benefit of remote hosts having main LAN IPs is - the topology set for the main LAN is also valid for the remote OpenVPN clients. (Provided proper routes are set on the Pfsense FW). Meaning that traffic from VPN client will be allowed in the same way it is allowed for the regular LAN hosts, whereas If the remote hosts are assigned IPs from a separate subnet, which is not in use in any network of the VPN community, this subnet will need to be defined on all firewalls/routers to allow the same traffic.
Step 2: For the remote hosts to access other subnets, routing information should be added in two places (1st in Custom Option of OpenVPN server configurations; 2nd is the route in Pfsense static routes table ) :
1st: OpenVPN server configurations -> Custom options: Add “route <NETWORK> <MASK>”. If more than one option, separate with “;”.
2nd: System->Static Routes: Add new route with the following:
Interface – LAN
Destination network - <NETWORK> / <BIT COUNT> (according to the <MASK> above)
Gateway – The FW/router which can reroute to this network. In my case it is the main network firewall, the default GW for the main LAN.
Description – As required
2. Not all traffic passing over VPN tunnel:
The setup above will redirect traffic targeted to the main LAN and the routed subnets through the VPN tunnel. The rest of the traffic will keep going in its regular way. This means, it won’t be encrypted. To reroute all the traffic through the VPN tunnel, the following custom option should be used:
In OpenVPN server configurations -> Custom options: push "redirect-gateway def1". If more than one option, separate with “;”.
That will redirect all traffic through the Pfsense GW. It can slow things down as all the traffic will be encrypted and will pass through an extra hop - the Pfsense GW. On the other hand, that can provide additional security, especially important with unsecure and/or wireless networks.
Here is how the Custom Options Field looks like:
