• 0 Votes
    1 Posts
    5k Views
    No one has replied
  • What actions are triggered by gateway going down?

    2
    0 Votes
    2 Posts
    51 Views
    J

    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.

  • Traffic flows to wan not other subnet

    7
    0 Votes
    7 Posts
    130 Views
    chpalmerC

    @greatbush You have to route somewhere.. In my mind that appears like your switch "a" is in place to do that.

    Otherwise the pfsense box has to have a VLAN set up on the LAN interface that is connected to switch A so that it knows that subnet is there to route.

    Share your LAN settings of your pfsense box. All of them that are related. The forum crystal ball is broken.

    Screenshots are best.

  • VoWiFi slow failover when using GW Groups

    2
    0 Votes
    2 Posts
    58 Views
    J

    @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
    134 Views
    C

    @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.

  • Load balancing not actually balanced?

    2
    0 Votes
    2 Posts
    63 Views
    N

    @davidbak level devil in Load balancing not actually balanced?:

    I'm a new pfSense user and a new Netgate user - new 4200. I have successfully set up the firewall with Multi-WAN in a load-balancing configuration and both WANs are in fact getting hit and are active - but the balancing aspect seems very un-balanced.

    First WAN is a 2.5Gbps hardware link and 2Gbps purchased bandwidth (per my account there), the second WAN is a 1Gbps hardware link and same purchased bandwidth (per my account there). When connecting a separate machine directly to the two different modems I do get full bandwidth (2Gbps and 1Gbps) per standard speedtest websites.

    But when running torrent software on a capable machine - connected to the 4200 with a 2.5Gbps link - where the torrent software is limited to 260Mbps overall (due to an unfortunately slow disk) - the first WAN routinely gets a steady 35MBps flow in while the second WAN fluctuates highly but usually in the range 0.5MBps to 1.5MBps. Or, about a 10-to-1 ratio. Both WAN Gateways are set for weight == 1. All this is IPv4 only as I have IPv6 disabled (haven't figured it out yet).

    As, AFAIK, the torrent software is constantly creating, using, and taking down connections, over time, over a large number of separate torrents, load balancing should be working and with both set to weight == 1 I expect to see similar bandwidth to both WANs (since the total limit the torrent program is using is under 1Gbps).

    Am I right in that assumption? Is there something I should be looking at? I'd be happy to upload any configuration information or logs if that would help you answer my question. Or, I'm happy to just take hints of what to look at, how to do measurements, etc., including links to documentation or other information.

    You should double-check your pfSense load balancing configuration, especially the sticky connections, as pfSense typically balances on a per-connection basis rather than sharing the overall bandwidth evenly. Also, consider setting appropriate weights for each WAN bandwidth for a more accurate distribution ratio. Torrenting often creates many small connections, so uneven balancing can also be due to the number of connections not being large enough or some heavy connections being concentrated on the main WAN. You should also review the logs and gateway status to ensure there are no errors or dropped connections that affect the balancing. Netgate's Multi-WAN load balancing documentation and the pfSense forums have many detailed instructions to help you check and fine-tune your configuration.

  • Tailscale Mesh with a Twist

    2
    0 Votes
    2 Posts
    72 Views
    M

    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

    10
    0 Votes
    10 Posts
    199 Views
    V

    @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

    9
    0 Votes
    9 Posts
    170 Views
    N

    @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.

  • Intermittent Failover to Backup WAN – Unable to Reach Firewall GUI/SSH

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

    1
    0 Votes
    1 Posts
    56 Views
    No one has replied
  • Routing problem?

    1
    0 Votes
    1 Posts
    81 Views
    No one has replied
  • New PPPoE module (if_pppoe) causes high cpu usage and cause lagging

    9
    0 Votes
    9 Posts
    489 Views
    w0wW

    @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

    1
    0 Votes
    1 Posts
    99 Views
    No one has replied
  • Policy based routing via two IPSEC gateways.

    2
    0 Votes
    2 Posts
    90 Views
    D

    Resolved by implementing BGP peering over IPSEC.

  • Routing instead of NAT between sites

    6
    0 Votes
    6 Posts
    254 Views
    I

    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.

  • Multiple IPs for Monitor IP Under Gateways

    8
    0 Votes
    8 Posts
    579 Views
    M

    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.

  • Tailscale Connections

    2
    0 Votes
    2 Posts
    140 Views
    W

    OK, I think I just figured it out!! I didn't have the subnet enabled. Not sure how it happened, but it now seems to be working. I can open the printer's web page!!

    Now I can revisit things.

  • 0 Votes
    47 Posts
    3k Views
    stephenw10S

    Do you see errors on the parent interface?

    You can try the dtrace commands shown in this thread and see if you're hitting some error other than 55 (no buffers).

  • Truenas VLAN jellyfin return route wrong

    2
    0 Votes
    2 Posts
    116 Views
    4

    @4o4rh i am struggling to get policy based routing working on truenas scale.
    either i get the situation where non-media vlans can access the jellyfin server on the media vlan (but then the truenas/smb vlan is not accessible, or the truenas/smb vlan is accessible by not the jellyfin vlan (other than from a device on the vlan).

    It both cases the non-accessible vlan is appearing on the wrong pfsense interface.

    so, it seems truenas is returning via the default route rather than the desired return route

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