Akeem Jenkins - Security & Privacy Professional

Before LLMs and Cursor, I wouldn't have even thought twice about diving into such a large repository as pfSense. The idea of navigating through thousands of lines of PHP code, understanding complex networking logic, and tracing execution paths seemed overwhelming. But here's the thing: with modern AI-assisted development tools, I was able to solve my problem in under 30 minutes while looking directly at the source code.

This is a story about how LLMs are democratizing open source contribution and making previously intimidating codebases approachable.

The Problem: Dynamic DNS Updating to Cloudflare Failing on Netgate 6100

TL;DR: Comcast's upstream gateway blocks ICMP traffic, causing pfSense's gateway monitoring to report the interface as "down" despite being fully functional, which breaks Dynamic DNS services.

The Journey: From Error Message to Root Cause

Initial Error

/services_dyndns_edit.php: Dynamic DNS (@.myhome.local) There was an error trying to determine the public IP for interface - wan (igc3)

Key Prompts That Led to Discovery

"How does the php script determine the public IP address of the WAN interface?"
- Led to discovering the dyndnsCheckIP() function in services.inc
"igc3 is not the default WAN port. This is a 10G port on a Netgate 6100. Check the logic for making sure that there isn't a specific setting that needs to be set in order to make sure the interface WAN default is changed"
- Revealed the interface assignment was correct, pointing to deeper IP detection issues
"Where does that monitoring IP come from?"
- Uncovered the gateway monitoring system and ICMP dependency

The Code Deep Dive

1. The Gateway Status Check (The Root Cause)

File: src/etc/inc/services.inc (Lines 4600-4605)

if (!empty($interface_gateway)) {
    // Bail early if the gateway is down.
    $gateways_status = return_gateways_status(true);
    if (array_get_path($gateways_status, "{$interface_gateway}/status", '') != 'online') {
        return false;  // ← This was returning false!
    }
}

The Problem: This function returns false if the gateway status is not "online", which breaks Dynamic DNS even when the interface is working perfectly.

2. Gateway Monitoring Logic

File: src/etc/inc/gwlb.inc (Lines 313-319)

if (empty($gateway['monitor']) || !is_ipaddr($gateway['monitor'])) {
    if (is_ipaddr($gateway['gateway'])) {
        $gateways_arr[$gwname]['monitor'] = $gateway['gateway'];  // ← Uses gateway IP as monitor
    } else {
        continue;
    }
}

The Issue: For DHCP interfaces, pfSense automatically uses the gateway IP as the monitor IP, but many ISPs (like Comcast) block ICMP to their gateways.

3. The Gateway Status Array

File: src/etc/inc/gwlb.inc (Lines 762-763)

$status[$target]['monitorip'] = $dpinger_status['targetip'];
$status[$target]['srcip'] = $dpinger_status['srcip'];

The Result: When we checked the gateway status, we saw:

Array
(
    [WAN_DHCP] => Array
    (
        [monitorip] => 192.168.1.55
        [srcip] => 192.168.1.1
        [name] => WAN_DHCP
        [delay] => 0ms
        [stddev] => 0ms
        [loss] => 100%        // ← 100% packet loss!
        [status] => down      // ← Marked as down
        [substatus] => highloss
    )
)

4. The Dynamic DNS Check

File: src/etc/inc/dyndns.class (Line 422)

$this->_dnsRequestIfIP = get_request_source_address($this->_dnsRequestIf, $request_source_af);

The Chain: This calls get_request_source_address() → checks gateway status → returns false because gateway is "down" → Dynamic DNS fails.

The Solution

Quick Fix (What We Did)

Changed Monitor IP: Set gateway monitor IP to 8.8.8.8 instead of the ISP gateway
Result: Gateway shows as "online" → Dynamic DNS works

Potential Code Fix (Pull Request Opportunity)

File: src/etc/inc/services.inc

// Current problematic code:
if (array_get_path($gateways_status, "{$interface_gateway}/status", '') != 'online') {
    return false;
}

// Proposed fix - add fallback for interface IP when gateway monitoring fails:
if (array_get_path($gateways_status, "{$interface_gateway}/status", '') != 'online') {
    // If gateway monitoring fails but interface has a valid IP, use it anyway
    $interface_ip = get_interface_ip($interface);
    if (is_ipaddrv4($interface_ip) && !is_private_ip($interface_ip)) {
        return $interface_ip;  // Use interface IP as fallback
    }
    return false;
}

The LLM Advantage: Why This Was Possible

Before LLMs: The Intimidation Factor

The Reality: Large open source projects like pfSense are intimidating. With over 2 million lines of code across thousands of files, the barrier to entry is massive:

Complex Architecture: Understanding how different components interact
Language Barriers: PHP, C, shell scripts, and configuration files
Domain Knowledge: Networking, firewall rules, gateway monitoring
Time Investment: Hours of reading documentation and code
Fear of Breaking Things: Modifying critical infrastructure code

The Result: Most developers would either:

Give up and find workarounds
Spend days in forums searching for similar issues
Never attempt to understand the root cause

With LLMs + Cursor: The 30-Minute Solution

What Changed: AI-assisted development tools fundamentally altered the equation:

1. Semantic Code Understanding

"Show me how Dynamic DNS determines the public IP" → Direct path to relevant functions
"Find where gateway monitoring is implemented" → Instant navigation to core logic
"Why would the interface show as down when it's working?" → Contextual analysis of the problem

2. Rapid Code Navigation

Before: Hours of grep searches and manual file exploration
After: Natural language queries that understand intent and context

3. Contextual Problem Solving

Before: Surface-level solutions from forums
After: Deep understanding of the execution flow from error to root cause

4. Confidence to Contribute

Before: Fear of breaking critical infrastructure
After: Understanding the codebase well enough to propose meaningful fixes

Key Prompts That Unlocked the Solution

"How does pfSense determine the public IP address for the WAN interface in Dynamic DNS?"
"Where does that monitoring IP come from?"
"Check the logic for making sure that there isn't a specific setting that needs to be set"
"Why isn't the script detecting my IPV4 address despite having a valid IPV4 address on the interface?"

Each prompt led directly to the relevant code sections, building understanding incrementally until the root cause was clear.

The Bigger Picture: Democratizing Open Source

This case study demonstrates how LLMs are democratizing open source contribution:

Complex Codebases Become Approachable

Previously intimidating projects like pfSense become navigable
Natural language queries replace complex search patterns
Contextual understanding replaces rote memorization

Rapid Debugging Becomes Reality

From error message to root cause in minutes, not hours
Direct code analysis replaces forum searching
Understanding execution flow becomes intuitive

Contribution Becomes Accessible

Identified a potential fix that could be submitted as a PR
Deep enough understanding to propose meaningful improvements
Confidence to engage with complex codebases

Technical Details

Files Modified/Examined

src/etc/inc/services.inc - Main Dynamic DNS logic
src/etc/inc/gwlb.inc - Gateway monitoring and status
src/etc/inc/dyndns.class - Dynamic DNS service implementation
src/usr/local/www/services_dyndns_edit.php - Web interface

Key Functions

dyndnsCheckIP() - Main IP detection function
get_request_source_address() - Interface IP determination
return_gateways_status() - Gateway monitoring status
setup_gateways_monitor() - Gateway monitoring setup

Debugging Commands Used

# Check gateway status
/usr/local/bin/php -r "require_once('/etc/inc/gwlb.inc'); print_r(return_gateways_status(true));"

# Check interface IP
/usr/local/bin/php -r "require_once('/etc/inc/interfaces.inc'); echo get_interface_ip('wan');"

# Test get_request_source_address
/usr/local/bin/php -r "require_once('/etc/inc/services.inc'); var_dump(get_request_source_address('wan', AF_INET));"

The 30-Minute Miracle

What made this possible in 30 minutes?

Instant Code Navigation: "Show me the Dynamic DNS logic" → Direct path to relevant functions
Contextual Understanding: "Why would this fail?" → AI explains the gateway monitoring dependency
Semantic Search: "Find gateway monitoring code" → Locates the exact implementation
Root Cause Analysis: "What's causing the 100% packet loss?" → Identifies ICMP blocking issue
Solution Discovery: "How can I fix this?" → Suggests changing monitor IP

The old way: Hours of forum searching, trial-and-error configuration changes, and surface-level solutions.

The new way: Direct code analysis, semantic understanding, and root cause discovery in minutes.

Conclusion: The Future of Open Source Contribution

This debugging session showcases the power of modern AI-assisted development tools. What would have taken hours of forum searching and trial-and-error configuration changes was resolved in minutes through direct code analysis and semantic understanding.

The ability to quickly navigate complex codebases and understand the flow of execution from error message to root cause represents a fundamental shift in how developers can approach open source projects.

The identified potential fix could be submitted as a pull request to improve pfSense's robustness when dealing with ISPs that block ICMP traffic, benefiting the entire community.

Most importantly: This experience demonstrates that with LLMs and tools like Cursor, developers no longer need to be intimidated by large, complex codebases. The barrier to meaningful contribution has been dramatically lowered, opening up open source projects to a much broader range of developers.

The future of open source isn't just about having more contributors—it's about having contributors who can quickly understand, debug, and improve complex systems that were previously accessible only to domain experts with years of experience.

This is how we democratize open source contribution.