@getcom said in console command to restart pppoe session: What are the advantages of the new driver? It faster. Potentially a lot faster depending on your system. It should be able t use CPU cores more efficiently. But if not if should use less CPU. It's a much cleaner implementation. But it is new and PPPoE has a lot of edge cases. Try it if you can.

Ah, yeah that's an ugly error in 24.11 but should not prevent actually upgrading.

You can have the same SSID on both sites but you can't have the same subnet unless they are bridged. Since both sides would have a local interface in 192.168.54.0/24 a route to it over the tunnel would conflict. Generally bridging a single layer 2 between sites is a bad idea but it can work if the latency is low. I would avoid it if at all possible though.

Aha, nice!

@the-other , Thank you for your answer, and sorry for the late response. I have just finished some experiments with firewall rules. Based on your advice, I moved all rules from the generic OpenVPN tab to the OVPN1 tab, leaving no rules at that tab. Everything works in the same way compared to the previous configuration. I also read that page in the pfSense manual you shared before I raised my post, but I did not fully understand. After reading your example, it became clearer, and after the mentioned experiments with rules, it is fully clear. Hopefully, all my findings are correct: Rules on the OpenVPN tab have priority over the OVPN1 tab (=> In case an incoming packet matches some OpenVPN tab rule, OVPN1 rules are ignored => Rules on the OpenVPN tab are meant to be generic and common for all OpenVPN servers.) If there are no rules on the OpenVPN tab, there is a default message saying "No rules are currently defined for this interface All incoming connections on this interface will be blocked until pass rules are added. Click the button to add a new rule". This confused me. I was convinced that a state without any rule is fully equivalent to a state with a "block all" rule (IPv4+IPv6, any protocol, any IP, any port, etc.). But at least for the OpenVPN tab, this is not true, as I tested that in case there are no rules on the OpenVPN tab, rules from OVPN1 are applied, and everything just works. I just tried to add a "block all" rule on the OpenVPN tab, and remote clients lost connection. So the mentioned message is quite confusing in this case. Because if that message was correct, remote clients would not have had a connection. Thanks, Jan

Ill give it a try- From post.txt above.. Hi, PfSense Plataform: CE 2.8.0 and 2.8.1 The generated list by the Status/IPsec/Leases page appears to be including clients with null IP addresses in the calculation of online clients (command line output below), when only those with real assigned IP addresses are listed on the page. This leads to a very large discrepancy between the clients considered online and all established IKE SAs, output of the command swanctl --list-sas | grep ESTABLISHED | wc -l If the null IPs listed as online are excluded from the listing, the listing will be consistent with the list shown on the page, more realistic and practically identical to that of the established IKE Security Associations (SAs). swanctl --list-pools --leases | more (null) online 'gustav' (null) online 'gustav' 192.168.100.226 online 'johnk' Comparison: Status/IPsec/Leases page output: 200 leases on line swanctl --list-pools --leases | grep online | wc -l 200 swanctl --list-pools --leases | grep online | grep -v null | wc -l 119 swanctl --list-sas | grep ESTABLISHED | wc -l 121 Thanks, Geovane

@johnpoz said in how to stop logging blocked LAN IGMP?: If there is nothing pfsense is going to do with it, and it cluttering up your logs anyway.. Why would you not just block it an be done.. And just prevent it from going any further up that stack that nothing is going to happen with anyway. A good deal of home gear supports IGMP snooping these days, and some have it enabled by default now. Almost all smb gear support snooping. As noted previously, if snooping is enabled and you block IGMP, some important things are not going to work correctly. mDNS is a shining example. VRRP and CARP are also good examples. It's true that a lot of home users don't run redundant setups needing VRRP or CARP, but smb certainly does. Again going to stress that multicast for sure has lots of benefit and uses - if your using it.. But more likely than not typical home user or smb is going to have little use for it. No, almost every home or smb user depends heavily on upon multicast, whether they know it or not. mDNS has become a critical network service for just about everything related to discovery or interoperability on the local network. Printing, file sharing, audio, home automation, etc. -- they all depend upon multicast. There's a lot of desire out there to segregate various systems in to trusted and untrusted network segments, usually for good reason. When you segment like this, you also need to be able to route multicast between the segments or things break. This is where things like mdns-bridge and mcast-bridge become necessary.

@marcosm said in transferred from Redmine -Bug #16341 Updating repositories metadata" returned error code 1 -- &/or Bug #15097: We are working on improving the license stuff. FWIW I tested the issue and it did not result in an unbootable system. @marcosm ---Thanks for the Follow-Up It would be great to be able to manage NICs flexibly on a NGFW, which is the "heart" of such a system. I have learned a lot about the relationship between NDI and MACs over the past few days. :) Kris is a great guy at TAC. I missed out a bit on this NDI and Plus license thing, but as I explained above, as soon as the added NIC created a new MAC, this license became invalid (so far, so good) and the firewall immediately threw up the error messages described in Bug #16341. After rebooting, it wouldn't start up again, and I had to continue from a snapshot. Now I understand that this is not directly related to the Bug #16341.

Clearing my browser cache did the trick. I'm OK now. Thanks to everyone for their feedback.

Simplifying this question, as I think it must be simple. Netgate 6100. Connected to Juniper router on WAN2. Juniper router port is a trunk port for VLAN. VLAN port is assigned 10.1.71.4. Physical port is WAN2. Attempting to tracert from a LAN address to the VLAN address works: Tracing route to 10.1.71.4 over a maximum of 30 hops 1 <1 ms <1 ms <1 ms 10.1.71.4 Trace complete. But trying to get to another address in that subnet, through the VLAN port, does not: Tracing route to 10.1.71.1 over a maximum of 30 hops 1 <1 ms <1 ms <1 ms LLL-GATEWAY.lll.lll.lll.org [10.0.0.196] 2 * * * Request timed out. The VLAN port itself can ping 10.1.71.1, so it is not a matter of firewalls at the far end. I have a rule on the VLAN port to allow any traffic from anywhere and of any type. So, do these routes look correct? I will include them all, just in case there is another issue. 10.0.0.196 link#10 UHS 10 16384 lo0 10.1.71.0/29 link#14 U 1 1500 ix2.71 10.1.71.4 link#10 UHS 6 16384 lo0 123.456.789.160/27 link#8 U 7 1500 ix3 123.456.789.162 link#10 UHS 8 16384 lo0 123.456.789.163 link#10 UHS 8 16384 lo0 123.456.789.172 link#10 UHS 8 16384 lo0 123.456.789.179 link#10 UHS 8 16384 lo0 123.456.789.185 link#10 UHS 8 16384 lo0 127.0.0.1 link#10 UH 5 16384 lo0 172.16.0.0/24 link#3 U 13 1500 igc2 172.16.0.1 link#10 UHS 14 16384 lo0 172.16.222.0 link#10 UHS 18 16384 lo0 172.16.222.0/31 link#13 U 17 1420 tun_wg0 172.19.71.0/24 link#4 U 15 1500 igc3 172.19.71.1 link#10 UHS 16 16384 lo0 192.168.2.0/24 172.16.0.2 UGS 3 1500 igc2 192.168.44.0/24 10.1.71.1 UGS 4 1500 ix2.71 192.168.68.0/22 link#2 U 11 1500 igc1 192.168.68.10 link#10 UHS 12 16384 lo0 192.168.125.0/24 172.16.222.1 UGS 19 1420 tun_wg0 Thanks!

Here. I think. Referenced as "github.com: vendor-provided URL vendor-advisory" in your link.

.... or zap the legacy 127.0.0.1 and embrase the future : ::1 ** ** some restrictions may apply.

Hi again, @Gertjan Quick update, looks like the following config will do what I want: 'loggers' => [ [ 'name' => 'kea-dhcp4', 'output_options' => [[ 'output' => 'syslog' ]], 'severity' => config_get_path('kea/loglevel', 'INFO') ], [ 'name' => 'kea-dhcp4.leases', 'output_options' => [[ 'output' => '/var/log/kea-dhcp4.log', 'maxsize' => 512000, 'maxver' => 7 ]], 'severity' => config_get_path('kea/loglevel', 'INFO') ] ], Thanks again for your help! :)

Ok, I don't know if it is the action of turning off "Use if_pppoe kernel module for PPPoE client", or the subsequent required reboot, but afterwards IPv6 is working as expected. All my interface with enabled IPv6 are getting assigned IPv6 addresses and the "readjusting of services" only happens when I change a rule on the firewall or pfBlockerNG reloads on it's schedule.

Looks like this works now with KEA in 25.07.1 .

@johnpoz said in Alias hostname expansion containing CNAME records: What exactly are you wanting to do with yahoo IPs - are you wanting to allow specific services to talk to you, or for you to talk to them? Normally you can find such lists googling for your service and say like firewall rules or IPs, etc. My use case is to use policy based routing with specific vpn's for respective imap servers accessed from the same client. IE use vpn A for yahoo, vpn B for microsoft, vpn C for gmail.

@barnettd Thanks for the fix! I was running into the exact same issue. Like @kmp, the pkg utility also had to be downgraded: pkg: 2.2.2_2 → 1.21.3_5 [pfSense] The following packages were reinstalled: pfSense-repo-25.07.1 [pfSense] pfSense-upgrade-1.3.11 [pfSense] snmpd starts up and everything appears to be working after a reboot.