Intermittent Problems Reaching Anything Beyond pfSense Firewall
-
@TangoOversway said in Intermittent Problems Reaching Anything Beyond pfSense Firewall:
I tried pinging. I could ping my firewall. I could ping the LAN side of the internet router. I could not ping beyond that
Can you reach the upstream ISP router ?
When you experience an outage, what do you see in the
System logs ?
DNS logs ?
DHCP log ?@TangoOversway said in Intermittent Problems Reaching Anything Beyond pfSense Firewall:
(I'd forward the DNS requests to Google's name servers, like 8.8.8.8.)
Not needed, except if you signed a contract with them like "here are all my private DNS requests".
During testing, switch to default DNS behaviour (works just fine for decades).No "help me" PM's please. Use the forum, the community will thank you.
Edit : and where are the logs ?? -
@TangoOversway said in Intermittent Problems Reaching Anything Beyond pfSense Firewall:
On the LAN side of the firewall, it's connected to an ethernet hub and our computers and devices are connected to that.
You're mentioning equipment that hasn't been upgraded in nearly a decade, so when you use the word ethernet hub here I'm thinking it might actually be a hub and not a misuse of words. Please double check and then triple check that this piece of equipment is actually a hub (not the same as a switch). If it is actually a hub, disconnect everything that is plugged into it and throw the hub in the garbage because that could definitely cause the problems you're describing. Replace it with any decent consumer grade gigabit SWITCH which are under $20 these days. Alternatively, you can try wifi instead of hardwiring those clients that went into the hub.
Raffi
-
A hub? Those started disappearing over 20 years ago. Switches started to become popular in the mid '90s. If it actually is a hub, he'd be limited to 10 Mb, half duplex, unless he has one of those rare 100 Mb hubs.
If I dig around through my junk closet, I may be able to find a 10 port hub.
-
@JKnott I hope I'm wrong. We somehow still had hubs in the office less than 10 years ago. If you find one in your junk closet, throw it out :)
Edit: We still have one in the office laying around :o
Dammit, I can't throw it out to help better the world because it's not mine. -
Outside of my closet, the last time I saw a hub was at work over 15 years ago. At the time, I was working for a really CHEAP company, where the network was a collection of consumer grade hubs and a couple of switches. The guy who was responsible for the network wasn't the brightest. He had a hub next to the server, and switches were closest to the users. He should have had one of them next to the server. When I tried telling the manager that, I was told the IT guy told her otherwise. At that time, I had already been a Novell CNA for a few years, but this guy apparently knew better.
-
On second thought, don't throw it out. It could be donated to a school. It could be good for instructional purposes to demonstrate traffic collisions on a network. Or donate it to a tech museum to help keep waste out of the landfill :)
-
After I stopped using it as a hub, I used it with Wireshark, to monitor traffic. However, that function has since been replaced with a managed switch configured for port monitoring. Plugging a 10 Mb hub into a Gb connection causes a bit of a performance hit.
BTW, you shouldn't be seeing collisions, unless someone misconfigured a switch or NIC to be half duplex.
-
Still catching up, but I realized I made a few mistakes and want to clarify those quickly.
I was posting with very little sleep over a good while, so I probably should fix a few points:
-
When we moved into the new house, in September, 2017, I used all new equipment. The whole house was wired with CAT5e (I wanted CAT6 - long story there) and thoroughly tested. Also, remember, this wiring has been in use that long without a problem like this. The only thing left was the old Soekris/pfSense firewall - something I was going to replace "next week" for that full 2 1/2 years.
-
It's a switch. Sorry, I know I said hub. And a newer one.
I'm still reading everything and will add more, but thought I should correct those points ASAP.
-
-
@TangoOversway said in Intermittent Problems Reaching Anything Beyond pfSense Firewall:
The whole house was wired with CAT5e (I wanted CAT6 - long story there)
CAT6 won't provide much benefit. Gb Ethernet was designed to work over 100 M (330') of CAT5, before there even was CAT5e. As I doubt you have many 100M runs in your house, it's even less of an issue.
I have plain CAT5 in my condo. It was installed¹ by my cable company when I got my cable modem, over 20 years ago.
- When the modem was installed, they had to run the coax from where it comes into my living room to my "office" at the other end of my unit. Since I didn't want cable stapled to the baseboards, around doors, etc., they sent 2 guys and they took about 3 hours to run it inside the walls, ceiling etc., so that it's completely hidden, except where it crosses over my laundry room ceiling, next to an air duct. I asked them to pull in a couple of runs of CAT5 (I provided) when they did that.
-
@JKnott said in Intermittent Problems Reaching Anything Beyond pfSense Firewall:
@TangoOversway said in Intermittent Problems Reaching Anything Beyond pfSense Firewall:
The whole house was wired with CAT5e (I wanted CAT6 - long story there)
CAT6 won't provide much benefit. Gb Ethernet was designed to work over 100 M (330') of CAT5, before there even was CAT5e. As I doubt you have many 100M runs in your house, it's even less of an issue.
Well, I do have a 500' run in this system - but that's underground fiber. Did it all myself, except for help with the electrician (who's also a friend) when we needed someone to pull and someone to feed. It was cool watching 500' of jetline zip into the black poly pipe when he turned on the shop vac on the other end! (And by, "Did it all myself," that includes running it under the house and barn/guest house foundations, 475' or so of 2' or deeper trenching, running it under our new roadway at the creek crossing, and running the ethernet cables from the converter locations to the switches in either building.)
I have plain CAT5 in my condo. It was installed¹ by my cable company when I got my cable modem, over 20 years ago.
- When the modem was installed, they had to run the coax from where it comes into my living room to my "office" at the other end of my unit. Since I didn't want cable stapled to the baseboards, around doors, etc., they sent 2 guys and they took about 3 hours to run it inside the walls, ceiling etc., so that it's completely hidden, except where it crosses over my laundry room ceiling, next to an air duct. I asked them to pull in a couple of runs of CAT5 (I provided) when they did that.
Did they use a cable gun? Those things are cool and I would have loved to have used one here, but they're just too expensive.
In my old house, I had done a lot of the AC rewiring on it in the 1990s. (The house was from the 1940s - WAY outdated!) I had to spend a lot of time in the attic and crawlspace. But that made it easy to run the ethernet cables in that house when it came time to do so. In this house, I had a great general contractor (also a friend) and closely supervised everything. I ran the HDMI, coax, and ethernet cables here and in the barn by myself.
-
@TangoOversway If you go to System/Routing/Gateways, what do you have set as the monitor IP for the primary WAN gateway? By default this is blank and will monitor your modem IP. I would suggest putting in something like google DNS (8.8.8.8 or 8.8.4.4) as a monitoring IP. This would give you a better understanding of your internet connection in the monitoring graphs and logs.
-
@Gertjan said in Intermittent Problems Reaching Anything Beyond pfSense Firewall:
@TangoOversway said in Intermittent Problems Reaching Anything Beyond pfSense Firewall:
I tried pinging. I could ping my firewall. I could ping the LAN side of the internet router. I could not ping beyond that
Can you reach the upstream ISP router ?
When you experience an outage, what do you see in the
System logs ?Nothing new in the system logs since March 10th.
DNS logs ?
At end of text.
DHCP log ?
Also at end.
Both these logs show that the services are extremely active and constantly doing something. Is this normal for a LAN that covers two buildings? Not many computers, but several mobile devices on wifi, plus a number of Sonos speakers and things like blu-ray players, Apple TVs, and so on.
@TangoOversway said in Intermittent Problems Reaching Anything Beyond pfSense Firewall:
(I'd forward the DNS requests to Google's name servers, like 8.8.8.8.)
Not needed, except if you signed a contract with them like "here are all my private DNS requests".
During testing, switch to default DNS behaviour (works just fine for decades).Sorry - in regards to my other note, I am operating on very little sleep and have been careless with my language. I'm using Google's name servers, specified under System/General Setup. Sloppy wording and sloppy way of thinking from exhaustion.
Would it help if I post a screenshot of DHCP or DNS Resolver settings?
DNS Resolver Log:
For recent entries - Is it supposed to be this active? The whole log only covered under 30 minutes, so there was no way of getting data from last night when we were testing everything. And, of course, with all intermittent issues, it's behaving right now.
Mar 13 15:14:04 pelorimts unbound: [56562:0] info: generate keytag query _ta-4f66. NULL IN
Mar 13 15:14:04 pelorimts unbound: [56562:0] info: service stopped (unbound 1.9.1).
Mar 13 15:14:04 pelorimts unbound: [56562:0] info: server stats for thread 0: 2 queries, 0 answers from cache, 2 recursions, 0 prefetch, 0 rejected by ip ratelimiting
Mar 13 15:14:04 pelorimts unbound: [56562:0] info: server stats for thread 0: requestlist max 6 avg 3 exceeded 0 jostled 0
Mar 13 15:14:04 pelorimts unbound: [56562:0] info: average recursion processing time 0.260167 sec
Mar 13 15:14:04 pelorimts unbound: [56562:0] info: histogram of recursion processing times
Mar 13 15:14:04 pelorimts unbound: [56562:0] info: [25%]=0 median[50%]=0 [75%]=0
Mar 13 15:14:04 pelorimts unbound: [56562:0] info: lower(secs) upper(secs) recursions
Mar 13 15:14:04 pelorimts unbound: [56562:0] info: 0.131072 0.262144 1
Mar 13 15:14:04 pelorimts unbound: [56562:0] info: 0.262144 0.524288 1
Mar 13 15:14:04 pelorimts unbound: [56562:0] info: server stats for thread 1: 1 queries, 0 answers from cache, 1 recursions, 0 prefetch, 0 rejected by ip ratelimiting
Mar 13 15:14:04 pelorimts unbound: [56562:0] info: server stats for thread 1: requestlist max 0 avg 0 exceeded 0 jostled 0
Mar 13 15:14:04 pelorimts unbound: [56562:0] info: average recursion processing time 0.484469 sec
Mar 13 15:14:04 pelorimts unbound: [56562:0] info: histogram of recursion processing times
Mar 13 15:14:04 pelorimts unbound: [56562:0] info: [25%]=0 median[50%]=0 [75%]=0
Mar 13 15:14:04 pelorimts unbound: [56562:0] info: lower(secs) upper(secs) recursions
Mar 13 15:14:04 pelorimts unbound: [56562:0] info: 0.262144 0.524288 1
Mar 13 15:14:04 pelorimts unbound: [56562:0] notice: Restart of unbound 1.9.1.
Mar 13 15:14:04 pelorimts unbound: [56562:0] notice: init module 0: validator
Mar 13 15:14:04 pelorimts unbound: [56562:0] notice: init module 1: iterator
Mar 13 15:14:04 pelorimts unbound: [56562:0] info: start of service (unbound 1.9.1).
Mar 13 15:14:05 pelorimts unbound: [56562:0] info: service stopped (unbound 1.9.1).
Mar 13 15:14:05 pelorimts unbound: [56562:0] info: server stats for thread 0: 0 queries, 0 answers from cache, 0 recursions, 0 prefetch, 0 rejected by ip ratelimiting
Mar 13 15:14:05 pelorimts unbound: [56562:0] info: server stats for thread 0: requestlist max 0 avg 0 exceeded 0 jostled 0
Mar 13 15:14:05 pelorimts unbound: [56562:0] info: server stats for thread 1: 0 queries, 0 answers from cache, 0 recursions, 0 prefetch, 0 rejected by ip ratelimiting
Mar 13 15:14:05 pelorimts unbound: [56562:0] info: server stats for thread 1: requestlist max 0 avg 0 exceeded 0 jostled 0
Mar 13 15:14:05 pelorimts unbound: [56562:0] notice: Restart of unbound 1.9.1.
Mar 13 15:14:05 pelorimts unbound: [56562:0] notice: init module 0: validator
Mar 13 15:14:05 pelorimts unbound: [56562:0] notice: init module 1: iterator
Mar 13 15:14:05 pelorimts unbound: [56562:0] info: start of service (unbound 1.9.1).
Mar 13 15:14:05 pelorimts unbound: [56562:0] info: service stopped (unbound 1.9.1).
Mar 13 15:14:05 pelorimts unbound: [56562:0] info: server stats for thread 0: 0 queries, 0 answers from cache, 0 recursions, 0 prefetch, 0 rejected by ip ratelimiting
Mar 13 15:14:05 pelorimts unbound: [56562:0] info: server stats for thread 0: requestlist max 0 avg 0 exceeded 0 jostled 0
Mar 13 15:14:05 pelorimts unbound: [56562:0] info: server stats for thread 1: 0 queries, 0 answers from cache, 0 recursions, 0 prefetch, 0 rejected by ip ratelimiting
Mar 13 15:14:05 pelorimts unbound: [56562:0] info: server stats for thread 1: requestlist max 0 avg 0 exceeded 0 jostled 0
Mar 13 15:14:05 pelorimts unbound: [56562:0] notice: Restart of unbound 1.9.1.
Mar 13 15:14:05 pelorimts unbound: [56562:0] notice: init module 0: validator
Mar 13 15:14:05 pelorimts unbound: [56562:0] notice: init module 1: iterator
Mar 13 15:14:05 pelorimts unbound: [56562:0] info: start of service (unbound 1.9.1).
Mar 13 15:14:08 pelorimts unbound: [56562:0] info: service stopped (unbound 1.9.1).
Mar 13 15:14:08 pelorimts unbound: [56562:0] info: server stats for thread 0: 0 queries, 0 answers from cache, 0 recursions, 0 prefetch, 0 rejected by ip ratelimiting
Mar 13 15:14:08 pelorimts unbound: [56562:0] info: server stats for thread 0: requestlist max 0 avg 0 exceeded 0 jostled 0
Mar 13 15:14:08 pelorimts unbound: [56562:0] info: server stats for thread 1: 0 queries, 0 answers from cache, 0 recursions, 0 prefetch, 0 rejected by ip ratelimiting
Mar 13 15:14:08 pelorimts unbound: [56562:0] info: server stats for thread 1: requestlist max 0 avg 0 exceeded 0 jostled 0
Mar 13 15:14:08 pelorimts unbound: [56562:0] notice: Restart of unbound 1.9.1.
Mar 13 15:14:08 pelorimts unbound: [56562:0] notice: init module 0: validator
Mar 13 15:14:08 pelorimts unbound: [56562:0] notice: init module 1: iterator
Mar 13 15:14:08 pelorimts unbound: [56562:0] info: start of service (unbound 1.9.1).
Mar 13 15:14:09 pelorimts unbound: [56562:0] info: service stopped (unbound 1.9.1).
Mar 13 15:14:09 pelorimts unbound: [56562:0] info: server stats for thread 0: 0 queries, 0 answers from cache, 0 recursions, 0 prefetch, 0 rejected by ip ratelimiting
Mar 13 15:14:09 pelorimts unbound: [56562:0] info: server stats for thread 0: requestlist max 0 avg 0 exceeded 0 jostled 0
Mar 13 15:14:09 pelorimts unbound: [56562:0] info: server stats for thread 1: 0 queries, 0 answers from cache, 0 recursions, 0 prefetch, 0 rejected by ip ratelimiting
Mar 13 15:14:09 pelorimts unbound: [56562:0] info: server stats for thread 1: requestlist max 0 avg 0 exceeded 0 jostled 0
Mar 13 15:14:09 pelorimts unbound: [56562:0] notice: Restart of unbound 1.9.1.
Mar 13 15:14:09 pelorimts unbound: [56562:0] notice: init module 0: validator
Mar 13 15:14:09 pelorimts unbound: [56562:0] notice: init module 1: iterator
DHCP Log:
Same as with DNS Resolver - so much going on not much time covered in the log. This is more recent.
Mar 13 15:29:11 pelorimts dhcpleases: Sending HUP signal to dns daemon(87942)
Mar 13 15:29:12 pelorimts dhcpd: DHCPREQUEST for 172.16.7.233 from c8:e0:eb:56:c0:71 (bagend-2) via mvneta0.4091
Mar 13 15:29:12 pelorimts dhcpd: DHCPACK on 172.16.7.233 to c8:e0:eb:56:c0:71 (bagend-2) via mvneta0.4091
Mar 13 15:29:12 pelorimts dhcpd: DHCPREQUEST for 172.16.7.16 from 78:7b:8a:c7:73:ec via mvneta0.4091
Mar 13 15:29:12 pelorimts dhcpd: DHCPACK on 172.16.7.16 to 78:7b:8a:c7:73:ec via mvneta0.4091
Mar 13 15:29:13 pelorimts dhcpleases: Sending HUP signal to dns daemon(87942)
Mar 13 15:29:15 pelorimts dhcpd: DHCPREQUEST for 172.16.7.226 from ac:87:a3:2b:39:f4 (Roseys-iMac-5) via mvneta0.4091
Mar 13 15:29:15 pelorimts dhcpd: DHCPACK on 172.16.7.226 to ac:87:a3:2b:39:f4 (Roseys-iMac-5) via mvneta0.4091
Mar 13 15:29:15 pelorimts dhcpleases: Sending HUP signal to dns daemon(87942)
Mar 13 15:29:16 pelorimts dhcpd: DHCPREQUEST for 172.16.7.224 from b8:09:8a:cc:2c:8b (Roseys-iMac-5) via mvneta0.4091
Mar 13 15:29:16 pelorimts dhcpd: DHCPACK on 172.16.7.224 to b8:09:8a:cc:2c:8b (Roseys-iMac-5) via mvneta0.4091
Mar 13 15:29:16 pelorimts dhcpleases: Sending HUP signal to dns daemon(87942)
Mar 13 15:29:19 pelorimts dhcpd: DHCPREQUEST for 172.16.7.187 from 48:a6:b8:a0:b6:dc (SonosZP) via mvneta0.4091
Mar 13 15:29:19 pelorimts dhcpd: DHCPACK on 172.16.7.187 to 48:a6:b8:a0:b6:dc (SonosZP) via mvneta0.4091
Mar 13 15:29:19 pelorimts dhcpleases: Sending HUP signal to dns daemon(87942)
Mar 13 15:29:21 pelorimts dhcpd: uid lease 172.16.7.238 for client 00:18:dd:07:8f:ec is duplicate on 172.16.7.0/24
Mar 13 15:29:21 pelorimts dhcpd: DHCPREQUEST for 172.16.7.246 (172.16.7.1) from 00:18:dd:07:8f:ec via mvneta0.4091
Mar 13 15:29:21 pelorimts dhcpd: DHCPACK on 172.16.7.246 to 00:18:dd:07:8f:ec via mvneta0.4091
Mar 13 15:29:21 pelorimts dhcpd: DHCPREQUEST for 172.16.7.236 from 78:28:ca:a1:73:4e (SonosZP) via mvneta0.4091
Mar 13 15:29:21 pelorimts dhcpd: DHCPACK on 172.16.7.236 to 78:28:ca:a1:73:4e (SonosZP) via mvneta0.4091
Mar 13 15:29:21 pelorimts dhcpd: DHCPREQUEST for 172.16.7.235 from 00:0e:58:fb:ce:a2 (SonosZP) via mvneta0.4091
Mar 13 15:29:21 pelorimts dhcpd: DHCPACK on 172.16.7.235 to 00:0e:58:fb:ce:a2 (SonosZP) via mvneta0.4091
Mar 13 15:29:21 pelorimts dhcpleases: Sending HUP signal to dns daemon(87942)
Mar 13 15:29:21 pelorimts dhcpleases: Sending HUP signal to dns daemon(87942)
Mar 13 15:29:22 pelorimts dhcpd: DHCPREQUEST for 172.16.7.245 (172.16.7.1) from 00:18:dd:07:8e:71 via mvneta0.4091
Mar 13 15:29:22 pelorimts dhcpd: DHCPACK on 172.16.7.245 to 00:18:dd:07:8e:71 via mvneta0.4091
Mar 13 15:29:22 pelorimts dhcpd: DHCPREQUEST for 172.16.7.231 from 00:0e:58:fa:2e:40 (SonosZP) via mvneta0.4091
Mar 13 15:29:22 pelorimts dhcpd: DHCPACK on 172.16.7.231 to 00:0e:58:fa:2e:40 (SonosZP) via mvneta0.4091
Mar 13 15:29:22 pelorimts dhcpleases: Sending HUP signal to dns daemon(87942)
Mar 13 15:29:24 pelorimts dhcpd: DHCPREQUEST for 172.16.7.244 from 00:21:b9:02:53:64 via mvneta0.4091
Mar 13 15:29:24 pelorimts dhcpd: DHCPACK on 172.16.7.244 to 00:21:b9:02:53:64 via mvneta0.4091
Mar 13 15:29:29 pelorimts dhcpd: DHCPREQUEST for 172.16.7.241 from e4:95:6e:42:f6:b3 via mvneta0.4091
Mar 13 15:29:29 pelorimts dhcpd: DHCPACK on 172.16.7.241 to e4:95:6e:42:f6:b3 via mvneta0.4091
Mar 13 15:29:32 pelorimts dhcpd: DHCPREQUEST for 172.16.7.4 from 84:39:be:6d:d1:7c via mvneta0.4091
Mar 13 15:29:32 pelorimts dhcpd: DHCPACK on 172.16.7.4 to 84:39:be:6d:d1:7c via mvneta0.4091
Mar 13 15:29:36 pelorimts dhcpd: DHCPREQUEST for 172.16.7.201 from 90:dd:5d
73:f0 (Barn-Cinema-ATV) via mvneta0.4091
Mar 13 15:29:36 pelorimts dhcpd: DHCPACK on 172.16.7.201 to 90:dd:5d73:f0 (Barn-Cinema-ATV) via mvneta0.4091
Mar 13 15:29:36 pelorimts dhcpleases: Sending HUP signal to dns daemon(87942)
Mar 13 15:29:40 pelorimts dhcpd: DHCPREQUEST for 172.16.7.189 from 34:7e:5c:7e:66:a0 (SonosZP) via mvneta0.4091
Mar 13 15:29:40 pelorimts dhcpd: DHCPACK on 172.16.7.189 to 34:7e:5c:7e:66:a0 (SonosZP) via mvneta0.4091
Mar 13 15:29:40 pelorimts dhcpleases: Sending HUP signal to dns daemon(87942)
Mar 13 15:29:41 pelorimts dhcpd: DHCPREQUEST for 172.16.7.185 from 28:ff:3c:b2:3e:4d (BarnBedroomATV) via mvneta0.4091
Mar 13 15:29:41 pelorimts dhcpd: DHCPACK on 172.16.7.185 to 28:ff:3c:b2:3e:4d (BarnBedroomATV) via mvneta0.4091
Mar 13 15:29:41 pelorimts dhcpleases: Sending HUP signal to dns daemon(87942)
Mar 13 15:29:43 pelorimts dhcpd: DHCPREQUEST for 172.16.7.213 from e4:9a:dc:60:3d:d3 (iPhone-Samwise) via mvneta0.4091
Mar 13 15:29:43 pelorimts dhcpd: DHCPACK on 172.16.7.213 to e4:9a:dc:60:3d:d3 (iPhone-Samwise) via mvneta0.4091
Mar 13 15:29:43 pelorimts dhcpleases: Sending HUP signal to dns daemon(87942)
Mar 13 15:29:45 pelorimts dhcpd: DHCPREQUEST for 172.16.7.195 from d8:0d:17:5c:a4:d0 (TL-SG1024DE) via mvneta0.4091
Mar 13 15:29:45 pelorimts dhcpd: DHCPACK on 172.16.7.195 to d8:0d:17:5c:a4:d0 (TL-SG1024DE) via mvneta0.4091
Mar 13 15:29:45 pelorimts dhcpd: DHCPREQUEST for 172.16.7.191 from 48:a6:b8:13:1a:9a (SonosZP) via mvneta0.4091
Mar 13 15:29:45 pelorimts dhcpd: DHCPACK on 172.16.7.191 to 48:a6:b8:13:1a:9a (SonosZP) via mvneta0.4091
Mar 13 15:29:45 pelorimts dhcpd: DHCPREQUEST for 172.16.7.190 from 78:28:ca:e7:d7:2e (SonosZP) via mvneta0.4091
-
@TangoOversway after you make the change to your monitor IP, keep an eye on your WAN gateway monitoring graphs when the problem comes up.
This is what those graphs looks like. A tiny bit of packet loss can be ignored like the ones seen in mine, but when you see the issue, the packet loss would increase if your connection to the web is the issue.
-
@Raffi_ said in Intermittent Problems Reaching Anything Beyond pfSense Firewall:
@TangoOversway If you go to System/Routing/Gateways, what do you have set as the monitor IP for the primary WAN gateway? By default this is blank and will monitor your modem IP. I would suggest putting in something like google DNS (8.8.8.8 or 8.8.4.4) as a monitoring IP. This would give you a better understanding of your internet connection in the monitoring graphs and logs.
Here's a screenshot of what I have in System/Routing/Gateways. Odd, but it still has the old firewall name there and I thought that was gone.
I have changed the Monitor IP for "WAN_DHCP (default)" to 8.8.8.8
Could you go more in depth on what you mean about monitoring? I see it mentioned in the docs, but not clearly explained. I would assume that pfSense pings the monitoring IP periodically to monitor the status of the connection and if it's working or down?
-
If you have anything under gateway you don't expect such as the old firewall you're mentioning, then it should probably be removed. Before changing anything though, save all your settings just in case. Go to Diagnostics/Backup & Restore, then hit the download configuration as xml button.
It may not be needed once you clean up the gateways, but I would still manually change the default IPV4 and IPV6 off of automatic and manually select the gateway you want being used. That removes any ambiguity with which gateway is being used.
Could you go more in depth on what you mean about monitoring? I see it mentioned in the docs, but not clearly explained. I would assume that pfSense pings the monitoring IP periodically to monitor the status of the connection and if it's working or down?
Yes, it pings the monitor ip twice a second by default. If the packet loss reaches a certain threshold (10% by default) it will mark the gateway as being down.
-
@Raffi_ said in Intermittent Problems Reaching Anything Beyond pfSense Firewall:
@TangoOversway after you make the change to your monitor IP, keep an eye on your WAN gateway monitoring graphs when the problem comes up.
This is what those graphs looks like. A tiny bit of packet loss can be ignored like the ones seen in mine, but when you're see the issue, the packet loss would increase if your connection to the web is the issue.
I had no idea the interface could be monitored like that. Blame that on lack of knowledge, but I also thought I knew the old system pretty well. I don't know if all this has been added in the past decade, or if I was just always a lot more ignorant of all the things pfSense can do!
Here's my graph for 24 hours. And over this time, I figure it was about 21:00 last night when my wife and I were running all the tests and couldn't get her computer t pull up much of anything. I don't see much going on at that time. I do see spikes in delays at 5:00, when I was trying to install Linux on a system that had just recently got messed up. I had a lot of problems then, with the Debian installer not being able to download files and I had to restart stages in the install a number of times. Another notable set of peaks about 7:45, which is when I had trouble downloading several files to install Channels DVR. The install script uses curl and wget a number of times to get the files it needs.
I checked back, just now, in my bash history, and found that it was during that install session, around 5:00 this morning, when I could not ping Google by using the IP address.
-
The monitoring graph as it is currently doesn't tell us a whole lot other than pfSense was able to ping your modem without issues. Going forward though, since the monitoring IP has been changed to something out on the web it should be more useful.
-
@Raffi_ said in Intermittent Problems Reaching Anything Beyond pfSense Firewall:
If you have anything under gateway you don't expect such as the old firewall you're mentioning, then it should probably be removed.
You're not talking physically, right? As in nearby or still hooked up, right? None of that. I did try to change the gateway name, but that's not allowed.
Before changing anything though, save all your settings just in case. Go to Diagnostics/Backup & Restore, then hit the download configuration as xml button.
I'm paranoid. I like backups! But thank you - I am spotty and there are things I know well, but I often miss basics.
It may not be needed once you clean up the gateways, but I would still manually change the default IPV4 and IPV6 off of automatic and manually select the gateway you want being used. That removes any ambiguity with which gateway is being used.
I'm assuming, by "clean up," you mean changing that name to what I'm using for everything else at this point (like the host name for the firewall) and changing the Monitor IP. But the system won't let me change the name of a gateway. I'm also not clear what you mean by changing them off automatic. Do you mean to specify to use one in particular (like not using DHCP6 at this point)?
-
I'm a little confused by that tiktok gateway. What is that? Is it an interface which provides web access?
-
@Raffi_ said in Intermittent Problems Reaching Anything Beyond pfSense Firewall:
The monitoring graph as it is currently doesn't tell us a whole lot other than pfSense was able to ping your modem without issues.
Then is it having delays while I was downloading a lot of data normal, since the interface was in use at that point?
Going forward though, since the monitoring IP has been changed to something out on the web it should be more useful.
I'm hoping it gives me something good. I take it that if it shows the gateway as down, or packet losses, or anything like that, that will prove it's the internet router and not something I've done wrong in the firewall?
