Environment

• Site A : pfSense CE 2.8.0
• IPsec Phase 1: IPv4
• Phase 2 (VTI):
• IPv4 VTI: works normally
• IPv6 VTI: fd00:1::2/64
• Site B: pfSense CE 2.7.0
• IPv6 VTI: fd00:1::1/64
• Both sides configured with:
• Phase 2 mode: Routed (VTI)
• Local/Remote networks: ::/0
• Firewall rules: allow all (for testing)

Summary
On pfSense 2.8‑CE, IPv6 gateway monitoring on VTI interfaces is broken. dpinger selects an incorrect IPv6 source address, causing all monitoring pings to fail. This results in:

1. The IPv6 VTI gateway being marked down
2. pfSense inserting an internal block rule (gateway monitoring (1000006961))
3. All IPv6 traffic on the VTI being blocked in one direction
4. Asymmetric IPv6 connectivity between the two sites
   This behaviour does not occur on pfSense 2.7‑CE.

Steps to Reproduce

1. Create an IPsec tunnel between pfSense 2.8‑CE and 2.7‑CE
2. Add two Phase 2 entries: * IPv4 VTI (works) * IPv6 VTI (::/0 → ::/0, Routed mode)
3. Assign IPv6 addresses to the VTI endpoints: * Site A (2.8‑CE): fd00:1::2/64 * Site B (2.7‑CE): fd00:1::1/64
4. Enable gateway monitoring on the IPv6 VTI gateway
5. Observe behaviour: * on the 2.8‑CE side IPv6 gateway is down * on the 2.7‑CE side IPv6 gateway is up

Actual Behaviour

1. dpinger fails to ping the remote IPv6 endpoint
   dpinger does not use the VTI interface address (fd00:1::2) as the source.
   It instead selects an incorrect or unspecified source address.
2. Gateway is marked DOWN
   The gateway immediately transitions to “Offline”.
3. pfSense inserts an internal block rule
   Firewall logs show:
   

   Block  OFFICELINK_IPSEC  gateway monitoring (1000006961)  fd00:1::2 → fd00:1::1  ICMPv6
   

   
   This rule is not user‑created and cannot be removed.
4. IPv6 traffic becomes one‑way
   - 2.7‑CE → 2.8‑CE: IPv6 ping works
   - 2.8‑CE → 2.7‑CE: IPv6 ping fails
   - All IPv6 traffic from 2.8‑CE is blocked by the internal rule
5. The GUI no longer provides a way to fix it
   In pfSense 2.8‑CE:
   - VTI interfaces cannot be manually assigned IPv6 addresses
   - VTI gateways are always “dynamic”
   - The dpinger Source Address field is removed
   - There is no supported way to force dpinger to use the correct IPv6 source
   This makes the regression unfixable through the GUI.

Expected Behaviour
- dpinger should automatically use the VTI interface’s IPv6 address as the source, or
- The GUI should allow specifying a dpinger source address for VTI gateways (as in 2.7‑CE)¶

Workarounds

1. Disable gateway monitoring
   This restores IPv6 connectivity but removes monitoring entirely.
2. Manually patch dpinger config (unsupported)
   Editing /var/etc/dpinger_*.conf to add:
   

   bind fd00:1::2
   

   
   …works temporarily but is overwritten by pfSense.
3. Use FRR (OSPFv3/BGP)
   Functional but overkill for simple VTI deployments.
   There is no supported GUI‑level workaround that restores correct behaviour.

Impact
This regression breaks:

• IPv6 VTI deployments
• IPv6 failover logic
• IPv6 routing stability
• Monitoring and alerting
• Any configuration relying on dpinger for IPv6 health checks
  It also creates confusing firewall behaviour due to internal block rules that users cannot modify.

Conclusion
This is a clear regression in pfSense 2.8‑CE affecting IPv6 VTI gateway monitoring.
The removal of the dpinger source‑address field for dynamic gateways, combined with incorrect automatic source selection, makes IPv6 VTI monitoring non‑functional.
A fix is needed to:

• restore correct dpinger source‑address selection for VTI interfaces
  or
• re‑enable the “Source Address” field for dynamic VTI gateways