@viragomann yes, thank you. assign separately .

@johnpoz Well Just figured it out. It was UNRAID SERVER Problem .. So for people using UNRAID and having pfsense in VM and sharing a folder. PFSENSE has nothing to do with it you need to configure your unraid and then map your address where the sharing folder exists. For instance in windows I had to map the drive for example: \200.200.1.30 (unraid server addy) (this is not my real address but you get the picture) and boom you get access to that folder you wanted to share. OMG 5 hrs later found easy solution but thanks for clearin up the pfblocker has nothing to do with it..

@stephenw10 It seems that it doesn't work. Probably I would have to cancel my contract.

@dennypage I tracked the issue down to Sony TV having a shitty AirPlay implementation. I have another LG branded TV which works with no issue.

You might be able to use the ix0/1 SFP ports with an appropriate module. Otherwise using an expansion card.

@dr21 said in PFsense Router Slow Web Interface Response - "swap_pager: indefinite wait buffer" Error in Logs: I'm running PFsense version 2.7.2 on a mini PC with an Intel Core i3-7020U and 8GB of RAM. The dashboard widgets show 16% RAM usage and 3% SWAP usage, and these values remain stable. I also don’t have any additional packages installed. With no extra packages installed, then I agree with others here who suspect a faulty disk. Odd that you are using any swap space, though. Typically that should show 0% swap usage.

There have been a number of updates in the monthly newsletter and also in the development section here. But essentially, yes, the addition of significant new functionality required more time over the usual release schedule.

Can you ping that IP? It feels like a server block on your public IP TBH.

@phoenixz2 You want to write your own script ? Have a look at this file, the last lines : /etc/inc/notices.inc So you can use notify_via_telegram($msg); in your own scripts (this is PHP btw) if you have set up Telegram.

Quite old but also still relevant as it hasnt changed from the cloud providers pint of view and the thread is misleading from a modern context. The above thread has a misconception of routable vs link local. Routable means that the ip block is propagated via routing protocols or made reachable via the router itself to anything connected to it. ie a client on a lan segment being able to reach a 169.254.0.0/16 address via the router not its own broadcast discovery over its local interface/ This is not the same as having a 169.254.0.0 /30 subnet on a vti interface. Only the two routers in the tunnel could see these addresses so it is therefore arguably compatible with rfc3927 as it is entirely on link. After all a vti interface is just a NIC, its just a virtual one over a tunnel vs a physical one. More still it is a better address space to use than the CGNAT netblocks as these can still clash on internal networks especially when multiple organizations are at play, where as rfc3927 addresses could not clash unless the same address spaces were used on the same router. This would obviously be trivial to fix and totally preventable

@SteveITS If hardcoded DNS is giving you issues needing more than expected/desired to be whitelisted, it may be worth checking out this blog on Labzilla. It was wrote with Pihole in mind alongside pfSense, so the term Pihole can be replaced with pfBlockerNG to make more sense. The trick for hardcoded is making DNS replies answer back looking like the answers come from the intended/hardcoded DNS server and not coming from an unknown source/pfSense/Pihole, using the few NAT rules described in the Labzilla blog goes another couple steps further than what Netgates documentation has for just redirecting DNS, these additional NAT rules will mask where DNS replies are answered back from: administrator@desktop:~$ nslookup www.google.com 8.8.8.8 Server: 8.8.8.8 Address: 8.8.8.8#53 Name: www.google.com Address: 10.10.10.69

@jrey Yes, thanks a lot.

@stephenw10 This is the only thing i see prior Oct 11 20:16:00 nyc-fw1-inet sshguard[69504]: Exiting on signal. Oct 11 20:16:00 nyc-fw1-inet sshguard[77474]: Now monitoring attacks. Oct 11 20:35:30 nyc-fw1-inet check_reload_status[666]: Linkup starting $e6000sw0port3 Oct 11 20:35:30 nyc-fw1-inet kernel: e6000sw0port3: link state changed to DOWN Oct 11 20:35:31 nyc-fw1-inet php-fpm[20159]: /rc.linkup: Hotplug event detected for WAN(wan) dynamic IP address (4: dhcp) Oct 11 20:35:31 nyc-fw1-inet php-fpm[20159]: /rc.linkup: DEVD Ethernet detached event for wan Oct 11 20:35:33 nyc-fw1-inet syslogd: sendto: Network is down Oct 11 20:35:33 nyc-fw1-inet syslogd: sendto: Network is down Oct 11 20:35:33 nyc-fw1-inet syslogd: sendto: Network is down Oct 11 20:35:33 nyc-fw1-inet syslogd: sendto: Network is down Oct 11 20:35:33 nyc-fw1-inet syslogd: sendto: Network is down Oct 11 20:35:33 nyc-fw1-inet syslogd: sendto: Network is down Oct 11 20:35:33 nyc-fw1-inet syslogd: sendto: Network is down Oct 11 20:35:33 nyc-fw1-inet syslogd: sendto: Network is down Oct 11 20:35:33 nyc-fw1-inet syslogd: sendto: Network is down Oct 11 20:35:33 nyc-fw1-inet syslogd: sendto: Network is down I do see that the LAN side had a Hotplug event as well. Looking at the timestamps the LAN side event happened more or less at the same time as the WAN side. To me this indicates either As part of any link-status event, pfSense restarts the internal switch ports There was some weird failure on both LAN and WAN side which i honestly don't see happening. Other cause not yet known. ][admin@nyc-fw1-inet.moore.lan]/var/log: cat system.log | grep "Hotplug" Oct 11 20:35:31 nyc-fw1-inet php-fpm[20159]: /rc.linkup: Hotplug event detected for WAN(wan) dynamic IP address (4: dhcp) Oct 11 20:35:38 nyc-fw1-inet php-fpm[55571]: /rc.linkup: Hotplug event detected for LAN(lan) dynamic IP address (4: 192.168.70.254, 6: track6) Oct 11 20:35:39 nyc-fw1-inet php-fpm[17116]: /rc.linkup: Hotplug event detected for WAN(wan) dynamic IP address (4: dhcp) Oct 11 20:35:54 nyc-fw1-inet php-fpm[20159]: /rc.linkup: Hotplug event detected for LAN(lan) dynamic IP address (4: 192.168.70.254, 6: track6)

@frodet You don’t need to reinstall to revert the configuration, it’s on the Diagnostics menu somewhere. Re: not save, there’s a path through interface reassignment where if you don’t click Save before you click Apply it doesn’t save…not sure if that applies here.

@Diggy then it’s out of beta apparently…! https://docs.netgate.com/pfsense/en/latest/install/netinstaller.html

Yes you can certainly separate the ports by VLANs on the 2100. So you can have all traffic from the TP-Link on one interface and all other traffic on a different interface. You just can't separate wired and wireless traffic from the TP-Link or wireless traffic on different SSIDs unless it specifically supports that.

It probably is a value from the CPU cores. But that depends on having the cpu temp available. Try adding the thermal sensors widget and it will show you. You can enable an appropriate CPU core sensor driver in Sys > Adv > MIsc. Steve

Could simply be a firewall rule blocking it. Check the states. Check the firewall log.

@jmaynard Back in the day I was the MIS for a lawfirm in Dallas. When we moved facilities I did all the wiring for an Arcnet token ring. Boy that does take me back. Phizix