@nafeasonto said in Can someone help me please? I can't udpate my packages on PFsense.: 2.5 of Pfsense. Ah, the bleeding edge technology. Probably not everything, but most of this page could be helpfull. edit : also : consider posting in the 2.5 Development forum.

This is a recent, clean install ? You use packages ? If so, what happens if you disable them all ?

@valentinius Yes, as i posted above the issue is resolved.

Had a moment to look in the logs more closely. I see this: miniupnpd 34231 setsockopt(udp, IPV6_RECVPKTINFO): Invalid argument It works, but... This happens on restart of miniupnpd after any config change.

Update - @Gertjan @johnpoz I think one of the problems (or the main one) was not a DNS blocking/limiting etc. but a static route to it set by pfsense because it was used as a monitoring IP etc. (read about it online). Since I'm never gonna use 4.2.2[1-6] for production DNS resolving, I decided to utilize them as monitor IPs for every gateway that is not the WAN itself or has no proper 'upstream' gateway to check against. Currently I'm happy with the solution below. I think the assumption mentioned in the screenshot is correct but we'll see what happens. [image: 1593508324504-screen-shot-2020-06-30-at-11.55.49.png] [image: 1593508333326-screen-shot-2020-06-30-at-11.56.06.png]

@rafamello If their SIP packets have the private IP encapsulated then they won't be able to stream back to you. I'm not sure which it would be but it's either ALG or the double NAT. SIP doesn't really work with either. When dealing with Cable operators in the USA (Spectrum and Comcast) there are 3 modes for the cable modems: RIP with NAT = Use when you are not providing a separate router. You would never use this with pfSense or any other customer provided firewall/router. RIP without NAT = Use when you have a static IP programmed in the router and the modem needs to be your Gateway. Bridge = Use when you don't have a static and are providing your own router. This puts the Public IP directly on your firewall.

@bmeeks I'll have to look at the packet capture to see what is going on at this point. I set everything up this morning again fresh with just the very basic default settings on the netgate box and this is what I have found. no netgate installed on my home network I can connect to my site with chrome and edge. put in the netgate and only edge will see my site. I tried to do a reinstall from the flash image and it gave me ad error not being able to read the drive. I followed the support link and used the program they suggested to image my flash drive and it did fine even it's test said it was fine. So I'm now looking for a new flash drive to retry to redo the image. I know you guys think I'm missing something simple because what I'm telling you just can't happen... Well if it can it will happen to me. I really can't tell you any more then what I have and I almost went through writing my last couple messages as I was doing it here at the house. I don't know how much more of a basic setup I can get. I'll shutup :-) once I'm able to get a new inage on my box to see if that has anything to do with something residule not being reset. But like you said, the browsers are supposed to be 100% agnostic. so something is going on here. if I can do a lookup and it comes back fine then why shouldn't both browsers act the same. Thank you for all your comments. I will do a packet capture and see what's going on. too weird.

yeah can not get nat 1:1 and ipsec with port forwards to work right.

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