Implemented VPN Remote Access On pfSense
PreviousIntroductionNextImplemented Snort, MISP, Cowrie, and Machine Learning to bolster network security
Last updated
Was this helpful?
Last updated
Was this helpful?
This project focuses on implementing a secure remote access solution using pfSense and OpenVPN. By integrating centralized authentication via Active Directory with RADIUS, the solution ensures robust security and streamlined user management. Additionally, features like secure file sharing, remote system access, and access to internal web services make this implementation versatile and practical for a variety of purposes.
The primary objective of this project is to establish a reliable and secure VPN solution that enables remote users to access internal network resources safely and efficiently. Key goals include:
Ensuring secure authentication through centralized user management with Active Directory and RADIUS Server.
Enabling remote access to critical services, such as internal web servers, FTP file sharing, and Telnet-based systems.
Providing efficient and encrypted connections to internal systems using TightVNC for remote management.
Access control, ensuring users have permissions tailored to their responsibilities for simplified management and enhanced security.
WAN Address
192.168.31.249
Tunnel Net
10.3.201.0/24
LAN Subnet
10.3.0.0/24
LAN gateway
10.3.0.10
Internal Client
10.3.0.129
Internal Server
10.3.0.131
In this lab, I utilize three virtual machines: one dedicated to pfSense, another for the Active Directory (AD) server, and a third serving as the Internal Client (IC).
Using 2 Network Adapter, one for WAN and another for LAN
In this configuration, I use NAT solely for internet access, as it is not a critical component. The second network adapter is designated for the server within the LAN.
As explained above, the NAT setup is used exclusively for internet access, which is not a key focus. Similarly, the second network adapter connects the internal client to the LAN.
After a successful installation, the interface is configured as described above. For the VMware pfSense setup, I selected "Bridged" for the WAN interface. This allows the VM's IP to be in the same subnet as my real IP, enabling direct connection to the VM.
For the LAN interface, I have configured the IP address as 10.3.0.10, which serves as the gateway IP for routing traffic between the internal network and pfSense. This ensures that devices on the internal network use 10.3.0.10 as their default gateway to communicate with pfSense and access external networks.
I have already installed some packages as above.
Here, I am using Windows Server 2022. After completing the setup, I will proceed with implementing the described objectives, ensuring proper integration and functionality across the pfSense firewall, Active Directory, and internal client systems.
First, I installed the Active Directory Domain Services role on the server and promoted it to a Domain Controller (DC). This setup allows the server to manage domain-based user authentication and provide directory services for the network.
I have already created a root domain named vpn.lab, which serves as the central domain for managing and authenticating users within the network. This domain will be used for user access control and VPN authentication.
After setting up the domain, I added users to the Windows Server. I created a group called GroupVPN to manage user accounts specifically for VPN access. This group helps streamline VPN authentication and permissions. Within the Users directory, I created individual user accounts that will be used for logging into the VPN. This setup ensures centralized user management and secure access control.
First, I installed Network Policy Server (NPS) on the Active Directory server. By integrating NPS with Active Directory, I ensure that user credentials are securely validated against the domain's user accounts.
After completing the installation, I began the configuration process. I added a RADIUS Client with the IP address set to the LAN gateway (10.3.0.10). This client acts as an intermediary, forwarding authentication requests from VPN users to the RADIUS server for verification.
In the Network Policies section, I created a rule specifically for the GroupVPN group. This policy grants members of GroupVPN access to the LAN network, ensuring only authorized users can connect to internal resources.
In pfSense, I configured an Authentication Server, which is the Active Directory (AD) server. This setup allows the firewall to use the AD server for authenticating VPN users, ensuring secure and centralized credential verification.
Here, I tested the account to ensure it was authenticated successfully through the configured authentication server.
Here, I provide some proof of successful creation. The entire process will be documented in detail in the resource section.
The Certificate Authority (CA) is responsible for issuing and managing certificates, including the server certificate, to ensure secure communication and authentication.
The server certificate verifies the server's identity to clients and facilitates the establishment of a secure, encrypted connection. It ensures trustworthiness and protects data exchanged from eavesdropping or tampering.
This section outlines the configuration of OpenVPN servers. Detailed steps and settings are provided in the resource section for reference.
Some rules are created after successfully configuring the OpenVPN server.
After everything was successfully set up, I encountered an issue where I couldn't ping the local network. After several attempts, I found the solution by changing the outbound NAT from automatic to manual and creating a new NAT for it.
Here, I use IP address-based hostname resolution, so if I change my WAN address, I will need to export the certificate again.
Export successfully
First, I installed the IIS (Internet Information Services) Web Server to host a website and set up an FTP server.
Here, I set up two sites: one is a website, utilizing the default web server configuration, and the other is an ftp_site, a designated folder for file sharing between clients.
In the FTP server, I configured several settings as outlined below.
Here, I used Telnet to connect to the Internal Client (IC). On my device, I enabled the Telnet Client feature to establish a connection to the Telnet server. For the IC, I utilized Pragma Telnet Server as the Telnet server software.
TightVNC offers configurations for both clients and servers. It only requires installation and setup to run effectively.
First, I imported the certificate and entered the account details.
Login successfully
Ping to local successfully
If VPN is not connected, accessing the website will not be possible.
If connected to the VPN, I can access the website.
On the server, I have stored several files that are shared for access.
Connect to the shared folder and upload a file.
Verify the server and IC; both can access and view the uploaded file.
Access the Internal Client (IC) using the designated account credentials
Establishing the initial connection to the Internal Client (IC).
Log in by entering the account credentials.
Connect successfully
Input the IP address of the Internal Client (IC) to initiate the connection.
Provide authentication credentials to log in.
Connect successfully
To ensure secure and efficient access, I’ve assigned users to specific roles and groups based on their needs:
Dream: Can access web resources but is restricted from the FTP server.
Haochientin: Has limited access and cannot ping internal clients.
Walter Drake: Has full, unrestricted access to all resources.
For easier management, these roles are grouped:
Full Access Group: For users like Walter Drake, with unrestricted access.
Ping-Only Access Group: For limited access users like Haochientin.
Web-Access-Only Group: For web-only users like Dream.
On pfSense, I created three Client Specific Overrides for each user, assigning them specific IPs. This ensures that the correct rules are applied based on the user’s assigned IP.
In Active Directory Users and Computers, this setup streamlines permission management by assigning users to specific groups, enforcing secure and role-based access policies for each user based on their assigned group.
On the NPS, I replace old group is groupVPN with each new created group.
Web-Access-Only Group
For the Web-Access-Only Group, where user Dream is restricted from accessing the FTP server, I updated the configuration by changing the permissions from All Anonymous Users to Specified Roles or User Groups. This ensures that only authorized users can access FTP, effectively blocking Dream’s access as required.
With this configuration, users in other groups who want to access the FTP server must log in using their VPN account credentials. This is because both the VPN and FTP server authenticate using accounts created on the same Active Directory (AD). This unified authentication ensures consistency and security across both services.
In this demo, Dream can still access the website, but when attempting to log in to the FTP server, the connection is refused. This demonstrates how access controls effectively restrict Dream's FTP access while allowing web access.
After pressing the login button, if the account is not authorized, the system returns to the login interface, indicating that access has been denied.
Ping-Only Access Group
For the Ping-Only Access Group, I created two new rules on pfSense: one to block ping requests to the internal clients (IC) and another to prevent Telnet access to it.
The connection times out when pinging internal clients (IC) due to the pfSense rule rejecting ping requests for the Ping-Only Access group.
The telnet connection cannot be established.
This user can still log in to both the website and FTP server, as demonstrated in the previous image. I won’t repeat the details here.
Full Access Group
In the Full Access Group, the new configurations above do not affect the accounts in this group, so I won’t repeat the details here.
