Thought I would post an update. It has been months since I started this thread, with our friend COVID in town and everyone online, bringing the Internet down makes me very unpopular. Back on April 10, I rolled back to my old hardware. It was running v2.3.5-RELEASE-p2. From April 10 until today (June 28) it has worked perfectly. Never a glitch. Today the family went out, so I took the opportunity to try switching hardware again. I made a fresh backup of my v2.3.5-RELEASE-p2 that was running. I see there has been a new release of PFSense, so I downloaded v2.4.5-RELEASE-p1 and installed it on my new box. Restored the backup and everything is running perfectly. No packet loss every 15 minutes. I looked at the release notes for 2.4.5-p1 and don't see anything that jumps out at me. Guess I will never know what the true cause of the problem was, but glad to have my new hardward back in place without any packet loss as my old hardware could was limiting my connection speeds.

SOLVED Just a quick thank you for all your contributions but an especial thanks to netblues for this "Well, this is straight and clear. The isp is asking the client to drop and reconnect ppp so isp provisioning (most probably radius) can also assign the route for the added network." That paragraph really opened my eyes and allowed be to proceed and get the public ip routed to opt1 interface. Thanks again

ok guys telegram is integrated in 2.5.0-DEVELOPMENT today's build. as of initial test, works as expected. thank you guys

@stephenw10 - 5 days and no crash. I think the NIC driver patch fixed it. Thanks for all your help. I think I learned my lesson, Intel NIC's from here on out.

@bingo600 said in DNS Not Working with Static WAN IP: Why 1480 as MTU , VDSL or ??? Good question. That value was needed, way back. It goes with my tunnel.he.net IPv6 ISP. I have to re experiment with it. edit : done. ping www.yahoo.com -f -l 1474 -4 and higher = fragmented. ping www.yahoo.com -f -l 1472 -4 It's a pass. 1472 it will be.

db:0:kdb.enter.default> bt Tracing pid 348 tid 100193 td 0xfffff8000b866620 kdb_enter() at kdb_enter+0x3b/frame 0xfffffe010fbfd420 vpanic() at vpanic+0x19b/frame 0xfffffe010fbfd480 panic() at panic+0x43/frame 0xfffffe010fbfd4e0 trap_pfault() at trap_pfault/frame 0xfffffe010fbfd530 trap_pfault() at trap_pfault+0x49/frame 0xfffffe010fbfd590 trap() at trap+0x29d/frame 0xfffffe010fbfd6a0 calltrap() at calltrap+0x8/frame 0xfffffe010fbfd6a0 --- trap 0xc, rip = 0xffffffff8125815e, rsp = 0xfffffe010fbfd770, rbp = 0xfffffe010fbfd770 --- copyout() at copyout+0x3e/frame 0xfffffe010fbfd770 uiomove_faultflag() at uiomove_faultflag+0xf4/frame 0xfffffe010fbfd7b0 pipe_read() at pipe_read+0x203/frame 0xfffffe010fbfd820 dofileread() at dofileread+0xba/frame 0xfffffe010fbfd860 kern_readv() at kern_readv+0x68/frame 0xfffffe010fbfd8b0 sys_read() at sys_read+0x84/frame 0xfffffe010fbfd900 amd64_syscall() at amd64_syscall+0xa86/frame 0xfffffe010fbfda30 fast_syscall_common() at fast_syscall_common+0x101/frame 0xfffffe010fbfda30 --- syscall (3, FreeBSD ELF64, sys_read), rip = 0x80096af4a, rsp = 0x7fffffffe728, rbp = 0x7fffffffe740 --- Fatal trap 12: page fault while in kernel mode cpuid = 2; apic id = 12 fault virtual address = 0x800e29000 fault code = supervisor write data, page not present instruction pointer = 0x20:0xffffffff8125815e stack pointer = 0x28:0xfffffe010fbfd770 frame pointer = 0x28:0xfffffe010fbfd770 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 348 (logger) trap number = 12 panic: page fault cpuid = 2 KDB: enter: panic Looks like a storage or filesystem problem to me. Reboot into single user mode and run fsck -y / no less than 5 times (until it neither finds problems or fixes problems), then reboot and see if it's better. Though given the nature of the backtrace I'm more inclined to think it's a storage/disk failure or maybe disk controller/cable failure.

Hi, Do you have to [image: 1593066048605-86f1a177-bbb8-4daa-98ec-92b9b954bcac-image.png] to [image: 1593066063590-ba11379d-6616-4b1b-b2d2-2e2a909bb1dd-image.png] ? ( this only involves a certain privacy issue, not a technical one ) Working with the default Resolver mode would make DNSSEC possible. Is you upstream ISP a modem ? Or a router ? How is you WAN setup ? What are the WAN events when your ISP device goes 'reboot' ? Btw : NAT is only important for incoming connections. You wouldn't care, as you even can't go out. If your LAN is 192.168.1.0/24, then what is this ? [image: 1593066409266-8f950c4b-ed8e-487c-9f38-44d5fa5b417b-image.png] 192.168.1.0/24 non destinatedfor pfSEnse will never been seen by the pfSense LAN interface. Observe : [image: 1593066596778-edf1fafd-7c88-4b7a-8d0a-33842c115da4-image.png] Rule number 6 (making the pfSense GUI accessible on WAN) : Ok if you do this for yourself - but ou shouldn't show it on a public forum

You're kind of hitting a few things here and unfortunately, all of these won't have much to do with pfSense. I've personally used ATT gigapower fiber in the past and bypassed it, and used pfSense as a primary router on the ATT service. There are many guides on how to bypass the ATT equipment on dslreports forums, I would suggest starting there and getting a better understanding of what you'll need. In my case, I had two switches. A "smart" switch with a VLAN configured on 3 ports that allowed the ATT gateway to authenticate the fiber port, and then I unplugged the ATT gateway and plugged in the WAN port of the pfSense router. This was simple but, required manual intervention if the fiber jack was ever power cycled (I keep all this stuff on a battery backup, so not an issue there). The second switch is just what you'll use for the stuff on your internal LAN, including any WiFi access points that you want to add in. Some people have gone to great lengths to extract the ATT certificate and have scripted the authentication process natively to happen if the firewall reboots or if the fiber jack reboots. This is a much slicker and automated setup but, requires a bit more effort and frankly the switch bypass method worked so well I never pursued the certificate extraction method. I haven't had ATT fiber for a few years now so I'm not sure if they've changed anything on their more recent installs. Given the activity on the forums, it seems quite a few people are still able to get the bypass working via a number of methods. This thread should get you going: https://www.dslreports.com/forum/r32295765-AT-T-Fiber-Any-way-to-bypass-att-modem-using-ASUS-GT-AC5300~start=240 If you do decide to use the wpa_suplicant method then you may have some more pfSense specific questions that some people here may help with. But personally, I would try the switch bypass method first as it's much simpler and easier to troubleshoot if you don't have a detailed background in this stuff.

So you either have to forward the bittorrent ports from WAN or activate UPnP, depending on what your client prefers.

@JKnott said in difference between pfsense and an antivirus?: AV software is pretty much install & run. However, a firewall/router often requires some configuration and it is possible to make mistakes if you don't know what you're doing. Okay, I'd better get someone to set this up for me when the time comes. I'll learn by then.

I've seen behavior like this with MTU problems. Consider sending pings of different sizes through the tunnel and see what happens maybe?

So step one, can you see me . org great site for testing.. Sniff while doing that on your wan.. If pfsense does not see that traffic, then no it can not forward.. Until you validate traffic you want to forward is actually getting to pfsense, anything else you do is just spinning your wheels if its not there to forward. step 1 in troubleshooting port forwarding after you have double checked your settings for stupid mistakes is actually validate the traffic is getting to pfsense.. Doesn't matter if you have forwarded or not, if wrong dest IP behind, etc.. validation that the traffic actually gets to you is key.. I run plex on a different port.. But here is simple test that 32400 can get to my wan [image: 1592910608866-gottowan.jpg] Until you actually validate that - zero point in doing anything else. edit: step 2 would be to validate your firerwall rules on wan are in the correct order and nothing above your rule that allows your port forward blocking.. Rules are evaluated top down, first rule to trigger wins, no other rules are evaluated. So its great the port forward auto adds the rule to allow your port forward to work.. but if you have something above that blocking - it not going to work.. So vs you showing the detail of the firewall rule.. You need to show all the rules on your wan interface, and any rules on floating to see if you have something that would prevent the forward from working. example of this could be a pfblocker auto rule blocking countries, etc.

@GabriellePeake said in how to block download mp3/mp4: solve that problem ? The thing is, when people take this road : @stephenw10 said in how to block download mp3/mp4: You you need full SSL interception to do so for https. there are not many that come back to reports, or show or how-to's. Doing some serious MITM is hard.

So, if anyone is interested. After digging around I managed to find https://redmine.pfsense.org/issues/3686 So in NPS if you set the condition to the string you can find in Wireshark as the NAS-Identifier you can handle things on a per service request. Typical that you search for weeks for an answer but you find it only after you post online for help. It would be great if this appeared somewhere in the manual, or maybe it already does and I am blind?

I need to change my signature to show the latest release that I am running. A quick search shows that I now may need 5 thumbs up to change my signature. So would 5 people be so kind as to give me 5 thumbs up for getting my pfSense back up and running? Thank you in advance.

Thank you for your help. It seems like Telekom added the route today and it is working now. traceroute6 to files01.netgate.com (2607:ee80:10::119:40) from 2003:a:6f26:6400:3eec:efff:fe43:bc4c, 64 hops max, 20 byte packets 1 2003:0:1303:a428::1 (2003:0:1303:a428::1) 12.648 ms 12.707 ms 12.710 ms 2 2003:0:1303:a420::2 (2003:0:1303:a420::2) 12.743 ms 13.076 ms 13.237 ms 3 2003:0:f600:d::1 (2003:0:f600:d::1) 24.753 ms 24.711 ms 24.737 ms 4 2003:0:f600:d::2 (2003:0:f600:d::2) 24.482 ms 25.486 ms 24.487 ms 5 ae4.cs3.lhr11.uk.eth.zayo.com (2001:438:ffff::407d:1cc2) 94.355 ms 93.986 ms 94.120 ms 6 ae5.cs1.lhr11.uk.eth.zayo.com (2001:438:ffff::407d:1d7e) 92.245 ms 92.605 ms 91.240 ms 7 ae2.mpr2.ewr1.us.zip.zayo.com (2001:438:ffff::407d:1d87) 90.741 ms 90.916 ms 90.743 ms 8 ae5.mpr1.ewr4.us.zip.zayo.com (2001:438:ffff::407d:1feb) 93.492 ms 93.446 ms 93.244 ms 9 2001:438:fffe::1b96 (2001:438:fffe::1b96) 102.487 ms 123.473 ms 123.992 ms 10 cs99-cs90.nyinternet.net (2610:1c1::1802) 91.492 ms 91.687 ms 91.498 ms 11 2607:ee80:10::119:40 (2607:ee80:10::119:40) 91.486 ms 91.558 ms 91.502 ms