pfSense

Description
After upgrading from 2.7.x to pfSense 2.8.0‑RELEASE (amd64) in a dual‑WAN, load‑balanced environment, source tracking entries are no longer populated in Status → System Logs → Routing / Source Tracking, even though "Use sticky connections" is enabled under System → Advanced → Miscellaneous. This appears to impact connection persistence, causing inconsistent outbound gateway assignments per source IP—behavior previously handled by source tracking.

1. Configure pfSense with two WAN interfaces, WAN1 and WAN2.
2. Set up a Gateway Group with both WANs at Tier 1 (load balancing).
3. Enable Use sticky connections in Advanced → Miscellaneous.
4. Generate traffic from internal clients—e.g., run ping, browse the web, stream, etc.
5. Go to Status → System Logs → Routing → Source Tracking and observe the table.

Expected Behavior
With sticky connections active, dfSense should maintain a source tracking table entry per source IP, mapping each internal client to its outbound gateway. The table should dynamically populate as traffic occurs.

Actual Behavior
Regardless of enabling/disabling sticky connections, the source tracking table remains empty.
Outbound gateway selection fluctuates—sessions may switch WAN interfaces and break applications relying on consistent source IP routing.

• pfSense version: 2.8.0-RELEASE (amd64)
• WAN links: WAN1 + WAN2
• Gateway Group configuration: Tier 1 on both WANs (load balance)
• Sticky connections: Enabled
• Outbound NAT: Automatic
• State Type: Interface‑bound
• Source tracking timeouts or custom settings: None applied
• Persistence: Issue survives reboots and interface resets

• Verified gateway group and policy routing unchanged since version upgrade.
• Tested toggling “Use sticky connections” off/on again.
• Checked logs and no relevant firewall rules or config overrides are present.
• Queried community—no existing forum posts or documented workarounds.
• Rebooted appliance and reset interfaces; issue persists.
• Fresh installation; issue persists.

• Affects all internal clients requiring session persistence across connections (e.g., VoIP, streaming, VPNs).
• Behavior was working as expected in earlier pfSense versions.