• 0 Votes
    1 Posts
    5k Views
    No one has replied
  • 0 Votes
    1 Posts
    13 Views
    No one has replied
  • External leased /24 class

    3 days ago
    0 Votes
    1 Posts
    57 Views
    No one has replied
  • Traffic flows to wan not other subnet

    25 days ago
    0 Votes
    9 Posts
    202 Views

    @greatbush while I have about 3 minutes here
    do you realize that windows machines by default will not allow pings and such from outside their own subnet to come in? Just trying to rule out any issues that you might have with Windows firewall on those machines..

  • 0 Votes
    8 Posts
    148 Views

    @ThePowerPig
    So add an additional rule to allow access to internal subnets (best to create an RFC 1918 alias for this purpose), but at least for the IPs you want to access from the device in question, and move this rule up above of the policy routing rule.

  • Load balancing not actually balanced?

    18 days ago
    0 Votes
    3 Posts
    126 Views

    @Nicholas97 Sticky connections are not enabled. Gateway status is fine. Weights for each LAN are set to 1 which should be fine for 2x gigabit connections and total bandwidth used of less than 1gbps. Will look at the logs but will have to figure out what I'm looking for ... will report back.

    I have read the multiwan load balancing docs pretty well and searched the forums here before posting this originally. Unless there are other pfsense forums you're referring to?

  • What actions are triggered by gateway going down?

    14 days ago
    0 Votes
    2 Posts
    80 Views

    It would seem the answer to my question is "/etc/rc.gateway_alarm" is run.

    Nothing in there for DHCP leases from what I see. More about restarting VPN sessions and flushing states.

  • VoWiFi slow failover when using GW Groups

    25 days ago
    0 Votes
    2 Posts
    88 Views

    @Proton retro bowl said in VoWiFi slow failover when using GW Groups:

    I have theese GW groups:
    e947b6a3-6853-4534-a448-05e780e72965-image.png
    I have a statis route for Mullvad GW to exit through starlink:
    ebd2ec98-90a0-4646-9af4-8ddfd609bb32-image.png
    On both Mullvad GW i have:
    8f24a410-ce6b-430f-acb9-ce97a7ff84b0-image.png
    The same for DOME GW.

    Default Gateway is group :
    adb3cbe1-1276-48a2-a07b-e29b797d6610-image.png

    and the othe rgroup lookes like this:
    5cfa03be-dd61-4bb0-b562-c4fc9dc6c5b9-image.png ,

    I have also set:
    ea0c1c09-dd93-4722-9479-dc0f019f06ea-image.png

    And i have my floating rules like this:
    a86219e7-b85f-4fb0-a8df-374beaeb0f04-image.png

    Including QOS settings.

    The idea is that when the boat is near land the DOME GW is avtive and is top priority. VoWifi also exit there if possible.
    So - when we only have Starlink - i force all VoWiFi traffic through WG GWs to always have VoWiFi work even then starlink has exit node abroad (get norwegian ip = allowed ViWiFi).

    So to my question:

    When both Dome and starlink is online, i can call using VoWiFi, no issues. But when Dome failes, it takes several minutes (5-6) before the mobile again can call. or get a call.
    Why is this?

    I know we are using UDP trffic and STATES here and that a cell phone can have a delay before he checks and reestablishes VoWiFi again, but is there something i can do to make the transition to WG GWs through starlink faster?
    How can i kill the STATES faster?

    I have also tried sloppy states and state timeout set to 25, but with same result.

    Suggestions?

    THX!

    You can try implementing a script that automatically flushes states when it detects a Gateway change, as this will significantly reduce the switching delay. The problem you are experiencing is that VoWiFi UDP connections still hold the old state, so the device takes time to check and reset. When the state is refreshed immediately, VoWiFi will reconnect faster and avoid the current 5-6 minute wait. Additionally, you can also consider reducing the state timeout value further or enabling the flush states on gateway down feature if your system supports it.

  • 0 Votes
    3 Posts
    170 Views

    @E-I Chill Guy Clicker said in pfSense 2.8.0: Sticky Connections in Dual-WAN Setup Not Maintaining Source Tracking:

    Hello Community,

    After recently upgrading to pfSense 2.8.0, I've encountered an issue related to source tracking entries in a dual WAN configuration.

    Under System > Advanced > Miscellaneous, the "Use sticky connections" option is enabled (though I've also tested with it disabled and re-enabled), but I am noticing that source tracking entries are not being maintained as expected. In previous versions, enabling sticky connections ensured consistent outbound gateway selection per source IP, with source tracking entries reflecting this behavior.

    Current Behavior:

    With or without "Use sticky connections" enabled, source tracking table is empty. This affects connection consistency across WAN interfaces, potentially impacting applications sensitive to IP changes. I have verified that my policy routing and gateway group configuration remain unchanged since the upgrade. The issue appears to persist across reboots and interface resets.

    Environment Details:

    fSense version: 2.8.0-RELEASE (amd64) Dual WAN (WAN1 + WAN2) with Gateway Group for load balancing (both Tier 1) "Use sticky connections": Checked Outbound NAT: Automatic State Policy: Interface Bound States No custom modifications to source tracking timeouts

    I'd appreciate any insights or recommendations for troubleshooting further or confirming whether this is a bug.

    Thank you in advance!

    This certainly sounds like an unintended change or bug in the source tracking mechanism introduced in pfSense 2.8.0. Since your configuration has not changed and the problem persists even after trying toggling sticky connections on/off, rebooting and resetting the interface, a misconfiguration can be ruled out. The fact that the source tracking table is always empty suggests that the sticky connection mechanism may not be working as expected. You should consider filing a bug report or checking to see if other users are experiencing the same problem on the Netgate forums or Redmine bug tracking system.

  • Tailscale Mesh with a Twist

    18 days ago
    0 Votes
    2 Posts
    89 Views

    To clarify what does work:

    What works is that from either site, a client device with an IP of 10.40.x.x is able to traverse the tailscale tunel to the other site by using the 10.65.x.x addresses. However, no device in this 10.40.x.x subnet can get to a 10.40.x.x IP at the other end.

    I realise that I am NATing the outbound connections rather than directly routing them due to the limitations of pfsense, so I am thinking I need to translate the 10.40.x.x subnet on the way out of the site, but nothing I have tried seems to work so far.

  • splitting a subnet, moving from LAN to WAN

    22 days ago
    0 Votes
    10 Posts
    237 Views

    @sgw said in splitting a subnet, moving from LAN to WAN:

    When I try to ping an IP that has not been used before and in the LAN-part (10.96.25.128/25) from "upstream"/"outside", it gets logged on the pfsense as blocked by the firewall (which is OK in terms of fw-rules).

    So the pfsense seems to take over traffic pointed to these IPs.

    Could I modify NAT-rules maybe? Is that related to Outbound NAT? Could I somehow exclude

    It seems that the lower IP range ist routed to pfSense WAN address. If so, you can do nothing. You cannot use the same IP outside pfSense, because pfSense was not able to route the traffic to the VM, since the subnet is defined on the LAN.

    You only option would be to use an IP of the upper /25 on the VM and forward it on pfSense. But note that doing this also requires an outbound NAT rule (masquerading) for the forwarded traffic.

  • sticky connections ignored

    21 days ago
    0 Votes
    9 Posts
    206 Views

    @pwood999 Indeed.

    I also run dual fiber links (on different physical fibers, with different building entry points)
    for resilience, not speed.

    Plain failover is enough for me too.

    But issues are issues and should nevertheless be fixed.

  • 0 Votes
    1 Posts
    28 Views
    No one has replied
  • Load Balancing with Multiple ISP

    22 days ago
    0 Votes
    1 Posts
    66 Views
    No one has replied
  • Routing problem?

    27 days ago
    0 Votes
    1 Posts
    93 Views
    No one has replied
  • 0 Votes
    9 Posts
    535 Views

    @cust
    You don't need to wait anything.
    You can apply this patch via system patches package, just use commit id 62b1bc8b4b2606d3b20a48a853ef373ff1d71e26

  • Ubiquiti Wave Pro Routing

    28 days ago
    0 Votes
    1 Posts
    114 Views
    No one has replied
  • 0 Votes
    2 Posts
    103 Views

    Resolved by implementing BGP peering over IPSEC.

  • 0 Votes
    6 Posts
    284 Views

    Thanks again for the video. It solved my problem.

    If anyone bumps into this thread in the future, the static route showed in a screenshot above here was correct, however here's what I did wrong:

    On site2 I had set "IPv4 Upstream gateway" in the interface config to the gateway on site1. This makes pfsense NAT the traffic instead of routing it. Here's a timestamped link to the video where this is explained.

  • 0 Votes
    8 Posts
    613 Views

    I really wish I could do the same here. I get some false positive failovers because the single IP monitor becomes offline, but the gateway is working fine...

    Gateway 1 monitor 8.8.8.8
    Gateway 1 monitor 1.1.1.1

    Gateway 2 monitor 8.8.4.4
    Gateway 2 monitor 1.0.0.1

    Gateway 3

    Then prioritize them and route following this order.

Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.