Categories

  • 375 Topics
    1k Posts
    fractal_boyF
    @gigabitguru What TNSR version do you run? This bugs were fixed on TNSR 23.11. Here is the details: https://docs.netgate.com/tnsr/en/latest/releases/release-notes-23.11.html#vrrp
  • 122k Topics
    779k Posts
    D
    Hello everyone, I am trying to apply a limiter in a pfSense multi-WAN environment and I would like to know whether this is a known limitation, a configuration issue on my side, or possibly a bug. My setup is: Two WANs Oi is the default gateway Vivo (PPPoE) is a non-default gateway I want to limit the upload speed of only two specific hosts running qBittorrent, without affecting the rest of the network What I tried: I first tried applying the limiter directly on LAN rules, assigning those hosts to the Vivo gateway. It did not work. Then I switched to a tag + floating rule approach, since NAT is involved once traffic leaves through the WAN. I created a specific tag for the qBittorrent hosts and applied that tag both on the LAN outbound rules and on the NAT / port forward related rules. I created a floating rule on the Vivo interface, direction out, using the Vivo gateway and dedicated limiter pipes. I tested multiple variations of that floating rule, including different source settings, upload pipe plus auxiliary download pipe, resetting states, and re-importing the config. Even so, the traffic is still not being limited. qBittorrent upload continues to leave through Vivo normally, and the limiter is simply not enforced. What makes this scenario tricky is that it combines several factors at once: multi-WAN non-default gateway PPPoE port forwards for qBittorrent limiter through floating rules traffic classification using tags In practice, the configuration is accepted, the rules appear to be correct, but the actual behavior does not match the expected result. My question is: Is this scenario officially supported and expected to work, or is there some known limitation or bug involving limiters + floating rules + multi-WAN with a non-default gateway? Also, in your opinion, would the better approach here be to stop trying to do this per-host and instead move these clients into a dedicated VLAN routed exclusively through Vivo? Any guidance would be appreciated. Olá, pessoal. Estou tentando aplicar limiter em um ambiente pfSense com multi-WAN e gostaria de entender se isso é uma limitação conhecida, algum erro de configuração da minha parte ou até um possível bug. Meu cenário é este: Duas WANs Oi como gateway padrão Vivo (PPPoE) como gateway não-padrão Quero limitar a velocidade de upload de apenas dois hosts específicos que rodam qBittorrent, sem afetar o restante da rede O que eu já tentei: Primeiro tentei aplicar o limiter diretamente nas regras da LAN, associando esses hosts ao gateway da Vivo. Não funcionou. Depois passei para uma abordagem com tag + floating rule, já que o NAT entra em jogo quando o tráfego sai pela WAN. Criei uma tag específica para os hosts do qBittorrent e apliquei essa tag tanto nas regras de saída da LAN quanto nas regras relacionadas ao NAT / port forward. Criei uma floating rule na interface da Vivo, direção out, usando o gateway da Vivo e pipes dedicados de limiter. Testei várias variações dessa floating rule, incluindo mudanças no source, uso de pipe de upload junto com pipe auxiliar de download, reset de states e reimportação da configuração. Mesmo assim, o tráfego continua não sendo limitado. O upload do qBittorrent continua saindo normalmente pela Vivo, e o limiter simplesmente não é respeitado. O que torna esse cenário mais complicado é a combinação de vários fatores ao mesmo tempo: multi-WAN gateway não-padrão PPPoE port forwards para qBittorrent limiter via floating rules classificação de tráfego usando tags Na prática, a configuração é aceita, as regras aparentam estar corretas, mas o comportamento final não corresponde ao esperado. Minha dúvida é: Esse cenário é oficialmente suportado e deveria funcionar, ou existe alguma limitação conhecida ou bug envolvendo limiters + floating rules + multi-WAN com gateway não-padrão? Além disso, na opinião de vocês, o melhor caminho aqui seria parar de tentar fazer isso por host e mover esses clientes para uma VLAN dedicada, roteada exclusivamente pela Vivo? Qualquer orientação será muito bem-vinda.
  • 20k Topics
    130k Posts
    M
    Reporting back on my issue. I am running a script that kills states for the IPv6 GUA when the PPPoE reconnect occurs. This consistently fixes my issue. While understanding and accepting that using a dns name based "static" setup on a dynamic IP is not the intended usecase for wireguard, I am still wondering about the underlying behavior: why is there a stale state for my IPv6 GUA remaining after a PPPoE reconnect. Some states seem to be killed during the reconnect: Mar 29 10:51:53 pfSense php-cgi[82387]: rc.kill_states: rc.kill_states: Removing states for IP fe80::be24:11ff:fe6f:74c8%pppoe1/32 Mar 29 10:51:53 pfSense php-cgi[82387]: rc.kill_states: rc.kill_states: Removing states for interface pppoe1 But old GUA-related states seem to staying on somehow: Mar 29 10:53:00 pfSense killstatescript[50247]: 2026-03-29 10:53:00 [wg-ipv6-watch] IPv6 changed on pppoe1: 2a01:....:....:6275:aaaa:bbbb:cccc:dddd -> 2a01:....:....:6a2:aaaa:bbbb:cccc:dddd Mar 29 10:53:00 pfSense killstatescript[53030]: 2026-03-29 10:53:00 [wg-ipv6-watch] Executed: pfctl -k 2a01:....:....:6275:aaaa:bbbb:cccc:dddd Mar 29 10:53:00 pfSense killstatescript[52180]: 2026-03-29 10:53:00 [wg-ipv6-watch] pfctl output: killed 7 states from 1 sources and 0 destinations Summing it up: using a scheduled script that kills the GUA related states upon PPPoE reconnection made my setup reliably stable with both wireguard endpoints on a dynamic connections using dns names as endpoint definitions combined with DDNS registration.
  • 43k Topics
    267k Posts
    micneuM
    @d4rkw4rden hast du mal einen grafischen netzwerkplan für dein setup (kann helfen beim verständnis) Warum brauchst du die Fritzbox vor der sense? Was ist das für ein Internet zugang (GLASFASER, *DSL)? Ich hatte Früher bevor ich GLASFASER hatte VDSL und hatte direkt ein Draytek Modem angeschloßen. Hier mein Aktuelles Setup ┌──────────────────────────┐ ┌──────────────────────────┐ │ WAN / Internet (PPPoE) │ │ WAN2 / Internet (ETH) │ │ Willy.tel │ │ 300/100Mbit/s 5G Telekom │ │ 1000/250Mbit/s Glasfaser │ │ gl-inet Mudi 7 │ │ (DualStack) │ │GEPLANT/warte auf Hardware│ │ │ │ │ └──────────────────────┬───┘ └──────┬───────────────────┘ ─ ─ ─ ─ ─ ─ ─ ─WAN─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┼ ─ ─ ─ ─ ─ ─│─ ─ ─ ─ ─ WAN ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ │ │ ┌────────────────┐ ┌────────────────┐ ╔═════════════╩════════════╩════════ pfSense+ ═══╗ │ TrueNAS SCALE │ │ Switch │ ║ Netgate 6100║ Stand: ─ ─ ┐ │ ORICO CF56 Pro ├───┤ USW-Flex-XG ├────╣ Netzwerk Block: 172.30.0.0/19║ │ │ │ │ │ ║ LAN Block: 172.30.0.0/20║ 17.03.2026 │ └────────────────┘ └───┬─┬──┬───────┘ ║ VPN Block: 172.30.16.0/20║ │ ┌────────────────┐ │ │ │ ║ LAN: 172.30.3.0/24║ ─ ─ ─ ─ ─ ─ ┘ │ UBNT │ │ │ │ ║ Gäste (W)LAN (VLAN2): 172.30.2.0/24║ │UniFI AP AC Pro ├───────┘ │ │ ║ IoT WLAN (VLAN4): 172.30.4.0/24║ │ │ │ │ ║ DynDNS über deSEC.io mit eigener Domain║ └────────────────┘ │ │ ║ VPN's:║ ┌────────────────┐ │ │ ║ 1 x S2S WireGuard FB 7490 (172.30.20.0/24)║ │ Proxmox │ │ │ ║ 1 x S2S WireGuard FB 6591 (172.30.19.0/24)║ │ Intel NUC ├─────────┘ │ ║ 1 x pfSense S2S (Netgate 6100) IPSec║ │BNUC11TNHV50L00 │ │ ║ 1 x OpenVPN Road Warrior DCO (172.30.16.0/24)║ └────────────────┘ │ ║ 1 x WireGuard RA Hetzner (172.30.17.0/24)║ │ ║ 1 x WireGuard Road Warrior (172.30.18.0/24)║ │ ╚════════════════════════════════════════════════╝ ┌────────────────┐ ┌────────┴───────────┐ ┌────────────────────┐ ┌──────────────────┐ │ Fritzbox 7490 │ │ Switch │ │ Switch │ │ UBNT │ │ IPClient ├───┤ USW Pro Max 16 PoE ├─┤ USW Pro XG 8 PoE ├─┤ UniFi AP-Flex-HD │ │ (Nur VoIP) │ │ │ │ │ │ │ └────────────────┘ └────┬───────────────┘ └──┬─────────────────┘ └──────────────────┘ ┌────────────────┐ │ │ ┌───────────┐ │ UBNT │ │ │ │ │ │UniFI AP AC Pro ├────────┘ └────┤ Clients │ │ │ │ │ └────────────────┘ └───────────┘
  • Information about hardware available from Netgate

    3k Topics
    21k Posts
    publictoiletbowlP
    @stephenw10 yes that 25.11.1
  • Information about hardware available from Netgate

    44 Topics
    211 Posts
    AriKellyA
    It looks like unified web management could be coming soon. It would be great if it means easier control and management of all web services in one place. Let's see if any companies announce more details about it!
  • Feel free to talk about anything and everything here

    4k Topics
    19k Posts
    BBcan177B
    There are alias deny for blocking and using that option the events will show in the Deny Stats. Alias Native doesn't use any deduplication. Alias Permit/Match should be selected if they are destined for a permit or match rule.
Copyright 2026 Rubicon Communications LLC (Netgate). All rights reserved.

Looks like your connection to Netgate Forum was lost, please wait while we try to reconnect.