🔐 Secure IKEv2 Remote Access VPN with pfSense & Splunk Project Overview
In this project, I designed and implemented a secure remote-access VPN environment using pfSense Community Edition, IKEv2/IPsec, Windows, Active Directory/DNS, SMB file sharing, and Splunk Enterprise.
My goal was not simply to establish a working VPN connection. I wanted to build a more realistic remote-access solution where a VPN user could securely access specific corporate resources without receiving unrestricted access to the entire internal network.
To accomplish this, I implemented network segmentation, split tunneling, least-privilege firewall rules, controlled SMB access, corporate DNS access, and centralized authentication monitoring with Splunk.
I also performed both positive and negative testing to verify that authorized services were reachable while unauthorized services remained blocked.
🏗️ Lab Architecture
I separated my environment into dedicated server, client, and VPN networks.
Remote Windows Client
VPN: 172.16.60.1
|
|
IKEv2 / IPsec
|
v
+----------+
| pfSense |
| Firewall |
+----+-----+
|
+---------------+---------------+
| |
v v
SERVER NETWORK CLIENT NETWORK
172.16.10.0/24 172.16.20.0/24
| |
+------+------+ |
| | | |
DC01 DC02 SPLUNK01 CLIENT01
.10 .11 .30 .101
| |
| DNS GuestShare
|
Active Directory Network Layout System / Network Address Purpose Server Network 172.16.10.0/24 Corporate infrastructure Client Network 172.16.20.0/24 Corporate workstations VPN Pool 172.16.60.0/24 Remote VPN clients DC01 172.16.10.10 Active Directory / DNS DC02 172.16.10.11 Secondary Domain Controller SPLUNK01 172.16.10.30 SIEM / monitoring CLIENT01 172.16.20.101 Authorized SMB resource VPN Client 172.16.60.1 Remote VPN endpoint 🎯 What I Wanted to Accomplish
I built this project to gain practical experience with:
Configuring an IKEv2/IPsec remote-access VPN Implementing EAP authentication Configuring strong IPsec cryptography Segmenting VPN users from internal systems Implementing split tunneling Creating least-privilege firewall policies Allowing corporate DNS through the VPN Providing controlled SMB file access Blocking unauthorized internal services Monitoring authentication activity with Splunk Troubleshooting VPN traffic across multiple network layers
- Configuring the IKEv2/IPsec VPN
I configured pfSense Community Edition as my VPN gateway and firewall.
For the IKEv2 tunnel, I configured:
IKE Version: IKEv2 Authentication: EAP-MSCHAPv2 Encryption: AES-256 Integrity: SHA-256 Diffie-Hellman Group: 14 IPsec Protocol: ESP
I then created two Phase 2 network selectors:
172.16.10.0/24 → Mobile Client 172.16.20.0/24 → Mobile Client
This allowed my remote VPN client to establish IPsec security associations for both the server and client networks.
My pfSense IPsec Configuration
- Configuring My Windows VPN Client
On my remote Windows system, I created an IKEv2 VPN connection named:
CORP Limited Guest VPN
I configured the connection to use:
Tunnel Type: IKEv2 Authentication: EAP Split Tunneling: Enabled
After completing the configuration, I successfully established the VPN tunnel.
Successful VPN Connection
I verified the connection using PowerShell:
Get-VpnConnection -Name "CORP Limited Guest VPN"
The output confirmed that the tunnel was connected using IKEv2 and EAP authentication.
- VPN IP Address Assignment
After connecting, my Windows VPN client received:
172.16.60.1
from my dedicated VPN address space:
172.16.60.0/24 VPN IP Assignment
I deliberately kept VPN clients on a separate network instead of placing them directly inside my server or client VLANs.
This allowed me to identify remote users by their source network and apply specific firewall policies to them.
- Implementing Split Tunneling
I enabled split tunneling on the Windows VPN connection.
Rather than sending all traffic through my VPN, I configured routes specifically for the corporate networks:
172.16.10.0/24 172.16.20.0/24
This meant that traffic intended for my lab environment could use the encrypted VPN tunnel while unrelated Internet traffic continued using the client's normal connection.
- Implementing Least-Privilege Firewall Rules
One of the most important parts of this project was ensuring that connecting to my VPN did not automatically provide unrestricted access to my internal environment.
I configured pfSense IPsec firewall rules that allowed only the services my VPN user required.
I permitted corporate DNS access to:
172.16.10.10:53
and SMB access to:
172.16.20.101:445
I then placed a blocking rule underneath those permissions to prevent other traffic from the VPN network from freely accessing corporate resources.
My IPsec Firewall Rules
My policy effectively became:
VPN USER | +-- DNS -> DC01:53 ALLOW | +-- SMB -> CLIENT01:445 ALLOW | +-- Other Corporate Access BLOCK
This allowed me to implement a least-privilege, default-deny approach to remote access.
- Testing Corporate DNS
I wanted my VPN user to use an explicitly authorized corporate infrastructure service without giving the user unrestricted server access.
I tested DNS resolution directly against DC01:
nslookup dc01.corp.local 172.16.10.10
The result was:
Server: DC01.corp.local Address: 172.16.10.10
Name: dc01.corp.local Address: 172.16.10.10 Successful Corporate DNS Test
This confirmed that my VPN client could successfully communicate with the corporate DNS service through the tunnel.
- Providing Controlled SMB File Access
I also wanted to simulate a realistic scenario where a remote user needed access to a corporate file resource.
I created and tested access to:
\172.16.20.101\GuestShare
hosted on CLIENT01.
I configured the necessary pfSense and Windows Firewall policies so that the VPN network could reach CLIENT01 using SMB over TCP port 445.
Successful Remote File Access
I successfully opened the share from the remote system while connected through the VPN.
This demonstrated the complete communication path:
My Remote Client 172.16.60.1 | | IKEv2/IPsec v pfSense | | TCP/445 explicitly permitted v CLIENT01 172.16.20.101 | v GuestShare 8. Testing Unauthorized Access
I did not want to test only what the VPN user could access. I also wanted to prove that my security controls prevented access to resources that the user was not supposed to reach.
I tested connectivity from the VPN client to SPLUNK01 on TCP port 9997:
Test-NetConnection 172.16.10.30 -Port 9997
The result was:
TcpTestSucceeded : False Blocked Unauthorized Access
This was an important validation of my firewall design.
My VPN tunnel was operational, but the VPN user still could not freely access unauthorized internal services.
- Monitoring VPN Authentication with Splunk
After getting the networking and security controls working, I wanted visibility into authentication activity.
I used Splunk Enterprise to create a dashboard panel called:
VPN Authentications Monitoring My Splunk Authentication Dashboard
My dashboard allows me to review information such as:
Authentication timestamps Source host VPN source IP Username Destination Successful authentication attempts Failed authentication attempts
This allowed me to move beyond simply asking:
"Is my VPN working?"
I could now investigate:
"Who attempted to authenticate, where did the connection originate, when did it happen, and did it succeed?"
This added a security monitoring and auditing layer to my VPN project.
🧪 How I Validated the Environment
I deliberately tested both allowed and denied behavior.
Test I Performed Expected Result Establish IKEv2 VPN Allowed ✅ PASS Authenticate using EAP Successful ✅ PASS Receive VPN address 172.16.60.x ✅ PASS Query corporate DNS Allowed ✅ PASS Resolve dc01.corp.local Successful ✅ PASS Connect to CLIENT01 TCP/445 Allowed ✅ PASS Open GuestShare Successful ✅ PASS Access SPLUNK01 TCP/9997 Blocked ✅ PASS View authentication activity in Splunk Visible ✅ PASS
Testing both sides of the policy was important to me.
A successful VPN connection alone would only prove connectivity. By also testing denied connections, I was able to verify that my access-control policy was actually being enforced.
🔧 Troubleshooting
Troubleshooting became one of the most valuable parts of this project.
I encountered issues involving:
IKEv2 connectivity Phase 2 selectors Split-tunnel routing pfSense firewall rules Windows Firewall SMB TCP/445 DNS resolution Routing between VPN and internal networks
I used PowerShell commands including:
Get-VpnConnection Get-NetIPConfiguration Get-NetTCPConnection Get-NetFirewallRule Test-NetConnection nslookup route print
I also examined pfSense firewall logs and packet captures to determine whether traffic was reaching the firewall and where it was being blocked.
Through troubleshooting, I learned to analyze the connection layer by layer:
VPN Tunnel ↓ Client Route ↓ IPsec Phase 2 ↓ pfSense Firewall ↓ Destination Firewall ↓ TCP/UDP Service ↓ Application
Instead of randomly changing settings when something failed, I learned to determine how far the packet was getting and investigate the next layer.
That was one of my biggest takeaways from this project.
🛡️ Security Concepts I Implemented Encryption
I used IKEv2/IPsec to protect communication between my remote endpoint and pfSense VPN gateway.
Network Segmentation
I isolated VPN clients inside:
172.16.60.0/24
rather than placing them directly inside an internal network.
Least Privilege
I granted my VPN user access only to the resources required for the scenario.
Default Deny
I blocked traffic that I had not explicitly authorized.
Split Tunneling
I routed only the required corporate networks through my VPN.
Centralized Monitoring
I used Splunk to gain visibility into authentication activity.
Positive and Negative Testing
I verified both permitted and prohibited connections rather than assuming my firewall rules worked.
Defense in Depth
Instead of relying on one security control, I combined:
Encryption + Authentication + Network Segmentation + Firewall Policies + Windows Firewall + Centralized Monitoring + Security Testing 🧰 Technologies I Used Technology How I Used It pfSense CE Firewall, routing and VPN gateway IKEv2/IPsec Secure remote-access tunnel Windows Remote VPN endpoint Windows Server Active Directory and DNS Active Directory Identity infrastructure DNS Corporate name resolution SMB Controlled remote file access Splunk Enterprise SIEM and authentication monitoring PowerShell Administration and troubleshooting VMware Virtualization platform 📚 Skills I Developed
Through this project, I SHOWED hands-on experience with:
IKEv2/IPsec pfSense administration VPN architecture EAP authentication Firewall policy design Network segmentation Split tunneling Least-privilege access Windows networking Active Directory DNS SMB Windows Firewall TCP/IP troubleshooting Packet analysis Splunk Enterprise SIEM dashboards Authentication monitoring Security validation Defense-in-depth design 🏁 Final Result
By the end of this project, I had built a working remote-access environment where my VPN user could:
✅ Establish an encrypted IKEv2/IPsec tunnel ✅ Authenticate using EAP ✅ Receive an isolated 172.16.60.x VPN address ✅ Query my corporate DNS server ✅ Resolve internal DNS records ✅ Access the authorized GuestShare
while being prevented from accessing unauthorized services:
❌ Unrestricted corporate network access ❌ SPLUNK01 TCP/9997 ❌ Services not explicitly permitted by my firewall policy
I also integrated the environment with Splunk so that I could monitor authentication activity from a centralized dashboard.
The biggest thing I learned from this project is that a VPN should not simply answer "who can connect?"
A secure remote-access design should also answer:
What can that user access after connecting, what should they be prevented from accessing, and how can I monitor their activity?
By combining IKEv2/IPsec, segmentation, least privilege, firewall enforcement, controlled resource access, negative testing, and SIEM monitoring, I built a small but realistic defense-in-depth remote-access environment.
🔒 Security Notice
I built this project entirely in a controlled lab environment.
I have intentionally excluded passwords, EAP secrets, private keys, certificate private material, and other sensitive authentication information from this repository.