Intermittent connection issue

KOM

My point wasn't to specifically question everything around you. It was to point out that your ISP likely will, and you need to have your answers ready.

Which NIC are you pertaining to? pfsense's NIC?

Well yes, that's the only NIC that matters in this context. Test or temporarily replace everything that you can to rule out one thing after another. And even then your ISP won't believe you because they've been lied to by a thousand other customers who said they've tested and tried this & that. I, myself, tend to not believe my customers when they tell me they did this or that and I make them show me. So many times, what they told me wasn't true. Just like in these forums when people write down what they're doing and I tell them to post a screen of what they've done instead of a description of what they think they have done.

kevindd992002

Ok. I'm thinking there are really TCP/UDP packet losses when the issue happens. Would these pcap settings probably be a good first step to see if there are DNS packet losses?

When the issue happens, sometimes the records I test (www.google.com, www.speedtest.net, mail.yahoo.com, etc.) cannot be resolved at all and sometimes they are resolvable but start with RTO's (during ping) until they just magically respond. Here are some examples:

https://pastebin.com/revDQ50C
https://pastebin.com/XRex1AGm

KOM

That will capture DNS traffic but I don't know how useful it will be. If DNS isn't replying, the capture won't give you much other than no response, and the real reason could be a million different network things. Your detail level is probably higher than necessary.

Are you doing DNS over TLS or DNSSEC?

Btw, you can upload images here directly without having to use an external site like Imgur. In the Edit bar, the second icon from the right is Upload Image.

Raffi_

@kevindd992002 I'm not sure why you still suspect DNS issues? Based on your pings, you're not getting an IP resolution error, you're getting no ping response from google. As you said, it looks like packets are not getting through at times. Those packets could be DNS queries, ICMP pings, TCP/UDP, and anything in between.

When trying to prove it's not your equipment, the best way to do that is to remove as much of your equipment from the setup as possible. Make it as simple as possible. Plug a know working PC directly into the modem with a known good cable. Are you still having issues with pings being dropped? If so, then it's either the modem or the ISP's line. If you REALLY want to be sure. Try a second PC and a second good cable and repeat. Anything else is still going to raise questions about xyz in the setup wouldn't it?

kevindd992002

[@KOM said in Non-forwarding Resolver intermittent operation:

That will capture DNS traffic but I don't know how useful it will be. If DNS isn't replying, the capture won't give you much other than no response, and the real reason could be a million different network things. Your detail level is probably higher than necessary.

Are you doing DNS over TLS or DNSSEC?

Btw, you can upload images here directly without having to use an external site like Imgur. In the Edit bar, the second icon from the right is Upload Image.

I see. Well, I wasn't really trying to prove it is a DNS issue. I just thought that I would limit my capture to DNS because it is also working intermittently due to the fact, of course, of my suspicion of packets being lost along the way somehow. So I was thinking that any type of traffic, TPC or UDP, is included in the issue.

I don't have Enable SSL/TLS Service enabled but I do have Enable DNSSEC Support enabled.

I uploaded the image in my last post here. Are you probably pertaining to the pastebin texts that I linked?

@Raffi_ said in Non-forwarding Resolver intermittent operation:

@kevindd992002 I'm not sure why you still suspect DNS issues? Based on your pings, you're not getting an IP resolution error, you're getting no ping response from google. As you said, it looks like packets are not getting through at times. Those packets could be DNS queries, ICMP pings, TCP/UDP, and anything in between.

When trying to prove it's not your equipment, the best way to do that is to remove as much of your equipment from the setup as possible. Make it as simple as possible. Plug a know working PC directly into the modem with a known good cable. Are you still having issues with pings being dropped? If so, then it's either the modem or the ISP's line. If you REALLY want to be sure. Try a second PC and a second good cable and repeat. Anything else is still going to raise questions about xyz in the setup wouldn't it?

See my reply above regarding why I was trying to limit to DNS issues. But I guess it would make sense to just capture all (no value in port field)?

Ok, so when the ISP guys came to my house a few weeks ago, I was trying to prove to them that the issue is with their network. But what turned out is this. Let me first explain my setup.

one of the pfsense interfaces (WAN) connected to modem/ONU
one of the psense interfaces (LAN) connected to ASUS switch/access point (router as others call it, but it is acting as a switch/AP in my use case)

So it's a basic setup with the additional setup of having a site-to-site VPN to my other house. So when they were here, I tried to prove that even if one of my PC's is connected directly to the modem, the problem still persists. So I connected one of my PC's directly to the modem, and true enough the problem persisted. I was actually lucky that the problem was experienced during the time they were here. Like I said, this is an intermittent problem that is usually just happening during peak hours (weeknights and weekends).

So with two devices connected to their modem (pfsense and one of my PC's), they let me remove pfsense (as they don't know anything about it), and to my amusement the directly-connected PC just magically worked. So they concluded that somehow my pfsense is bringing down the network or something. Now I'm not yet fully convinced regarding this conclusion because even with pfsense in the mix, this issue just auto-resolves itself after a few minutes. Like you said, I have to test using the modem directly without any of my own equipment connected to it and observe for a few days.

But if say, pfsense is really causing a conflict, how would it be doing that? I really don't understand why when connecting pfsense to the modem, it bugs down the whole network. pfsense and the PC are both clients in the point of view of the modem. So if there's an issue with pfsense, it shouldn't affect the other clients connected to the same modem (i.e. my PC), would it? I checked for IP conflicts and there's really none.

While I was typing this, I encountered the issue again and here's the unfiltered packet capture if you guys can help me check on it real quick? While the packet capture is running, I ping'ed www.google.com and here's the results.

KOM

Nothing jumps out at me from your capture. Your ping requests are replied to. You tried to open a connection to something on tcp/443 that wasn't answered. You tried to talk to another web server and it told you to go away. There were some minor errors. There are references to OpenVPN. Do you have a VPN tunnel running?

kevindd992002

@KOM said in Non-forwarding Resolver intermittent operation:

Nothing jumps out at me from your capture. Your pin requests are replied to. You tried to open a connection to something on tcp/443 that wasn't answered. There are references to OpenVPN. Do you have a VPN tunnel running?

That's weird. If they were all replied to, why do I have a lot of RTO's in the ping results?

Yes, for some reason I just started having issues with the pfsense webgui when accessing it through firefox but works just fine with chrome and edge. Error is:

Certificate key usage is inadequate for attempted operation. Error code: SEC_ERROR_INADEQUATE_KEY_USAGE.

This is the first time I've encountered this error with the gui.

Yes, I have a site-to-site VPN to my other home'a network through openvpn.

johnpoz

@kevindd992002 said in Non-forwarding Resolver intermittent operation:

RTO's in the ping results?

Ping is not the same as NS not answering a query.

What cert are you using on pfsense gui, the self generated self signed, your own, acme?

What is the extended key usage set on the cert? That error points to this not being called out, or wrong for what your trying to do with the cert.
"A certificate has a key usage extension that does not assert a required usage"

Here is what is listed on my created certs I use for pfsense web gui, via the Cert Manager, and created CA.
Not Critical
TLS Web Server Authentication (1.3.6.1.5.5.7.3.1)
1.3.6.1.5.5.8.2.2

Maybe your trying to use a user vs a server cert?

kevindd992002

@johnpoz said in Non-forwarding Resolver intermittent operation:

@kevindd992002 said in Non-forwarding Resolver intermittent operation:

RTO's in the ping results?

Ping is not the same as NS not answering a query.

What cert are you using on pfsense gui, the self generated self signed, your own, acme?

What is the extended key usage set on the cert? That error points to this not being called out, or wrong for what your trying to do with the cert.
"A certificate has a key usage extension that does not assert a required usage"

Here is what is listed on my created certs I use for pfsense web gui, via the Cert Manager, and created CA.
Not Critical
TLS Web Server Authentication (1.3.6.1.5.5.7.3.1)
1.3.6.1.5.5.8.2.2

Maybe your trying to use a user vs a server cert?

Yes, I know DNS queries aren't same as ping (ICMP) packets. I was trying check earlier if DNS query packets are also getting lost along the way, and then I showed the ping results as additional information for troubleshooting.

The CA I have in there is the self-signed FreeRADIUS CA which is used to sign the FreeRADIUS cert. The certs I have under the Certificates tab are:

WebConfigurator default (self-signed)
Signature Digest: RSA-SHA256
KU: Digital Signature, Key Encipherment
EKU: TLS Web Server Authentication, IP Security IKE Intermediate
FreeRADIUS Server Cert (signed by FreeRADISU CA)
Serial: 1
Signature Digest: RSA-SHA256
KU: Digital Signature, Key Encipherment
EKU: TLS Web Server Authentication, IP Security IKE Intermediate

Weird thing is that I have another pfsense box (the one at the other end of the openvpn tunnel) that I can access just fine with Firefox and it has the same cert structure and EKU's.

KOM

@kevindd992002 said in Non-forwarding Resolver intermittent operation:

If they were all replied to, why do I have a lot of RTO's in the ping results?

Your cap only shows 3 pings within 1.5 seconds, all replied to. There are no pings that go out and don't echo back.

kevindd992002

@KOM said in Non-forwarding Resolver intermittent operation:

@kevindd992002 said in Non-forwarding Resolver intermittent operation:

If they were all replied to, why do I have a lot of RTO's in the ping results?

Your cap only shows 3 pings within 1.5 seconds, all replied to. There are no pings that go out and don't echo back.

Ok, does that tell us that it'a a client issue? Pings not reaching the default gateway (pfsense). I doubt it because when the issue happens, even then ping diagnostic tool of pfsense has this issue.

KOM

It doesn't tell you much at all,unfortunately. I might throw it back to your ISP at this point and see what they say.

johnpoz

You say its intermittent, just because it didn't happen when you removed pfsense doesn't mean it wasn't just not happening at that time.. Doesn't prove that the issues is pfsense.

I could see maybe if pfsense was generating a shit ton of traffic or something that could bring down your network, or its interface was spewing out garbage packets or something?

But there is really nothing in that sniff that shows anything out of the ordinary at all..

Are you saying without pfsense connected it works fine for days? And then the second you connect pfsense it crashes? Keep in mind if your problem is dns related.. Is your client also resolving like pfsense does, or does it just forward?

When the issue happens your other direct connect client also stops working, or just the clients behind pfsense?

Raffi_

@kevindd992002 said in Non-forwarding Resolver intermittent operation:

So when they were here, I tried to prove that even if one of my PC's is connected directly to the modem, the problem still persists. So I connected one of my PC's directly to the modem, and true enough the problem persisted. I was actually lucky that the problem was experienced during the time they were here. Like I said, this is an intermittent problem that is usually just happening during peak hours (weeknights and weekends).

So with two devices connected to their modem (pfsense and one of my PC's), they let me remove pfsense (as they don't know anything about it), and to my amusement the directly-connected PC just magically worked. So they concluded that somehow my pfsense is bringing down the network or something. Now I'm not yet fully convinced regarding this conclusion because even with pfsense in the mix, this issue just auto-resolves itself after a few minutes. Like you said, I have to test using the modem directly without any of my own equipment connected to it and observe for a few days.

I'm reading two conflicting paragraphs. The first paragraph says you were able to reproduce the problem in front of the service tech with only a PC directly connected to the modem. The second paragraph says you were not able to reproduce the problem again with only a PC connected to the modem. It sounds like you let the service tech off the hook too easily. Once you proved in front of them that the direct PC was not working, that is their issue. Why was any additional testing needed? Did the tech ask you to hook pfSense back up? How can they conclude that pfSense is the issue when it wasn't even connected in that first scenario? I'm I misunderstanding something?

Raffi

kevindd992002

@johnpoz said in Non-forwarding Resolver intermittent operation:

You say its intermittent, just because it didn't happen when you removed pfsense doesn't mean it wasn't just not happening at that time.. Doesn't prove that the issues is pfsense.

I could see maybe if pfsense was generating a shit ton of traffic or something that could bring down your network, or its interface was spewing out garbage packets or something?

But there is really nothing in that sniff that shows anything out of the ordinary at all..

Are you saying without pfsense connected it works fine for days? And then the second you connect pfsense it crashes? Keep in mind if your problem is dns related.. Is your client also resolving like pfsense does, or does it just forward?

When the issue happens your other direct connect client also stops working, or just the clients behind pfsense?

No, I'm not saying that. Running without pfsense for a few days would be my next step. And no, it just looks like that the second I remove pfsense from the mix, the ping goes through and the problem resolves itself. But then again, it could just be a coincidence since I need to be able to reproduce it consistently.

Like I mentioned though, I don't think my problem is DNS-related. It's packet loss related for all type of packets. So when unbound tries to resolve through root hints, the packets get lossed (sometimes) and so it returns with failed queries, which in itself looks like a DNS issue.

What do you mean by my client resolving like pfsense does or does it just forward? It's a Windows client with the pfsense LAN IP configured as its DNS server to ask queries from?

When the issue happens, as long as pfsense is connected to the modem, all clients (behind pfsense or directly connected to the modem) experience the issue.

@Raffi_ said in Non-forwarding Resolver intermittent operation:

@kevindd992002 said in Non-forwarding Resolver intermittent operation:

So when they were here, I tried to prove that even if one of my PC's is connected directly to the modem, the problem still persists. So I connected one of my PC's directly to the modem, and true enough the problem persisted. I was actually lucky that the problem was experienced during the time they were here. Like I said, this is an intermittent problem that is usually just happening during peak hours (weeknights and weekends).

So with two devices connected to their modem (pfsense and one of my PC's), they let me remove pfsense (as they don't know anything about it), and to my amusement the directly-connected PC just magically worked. So they concluded that somehow my pfsense is bringing down the network or something. Now I'm not yet fully convinced regarding this conclusion because even with pfsense in the mix, this issue just auto-resolves itself after a few minutes. Like you said, I have to test using the modem directly without any of my own equipment connected to it and observe for a few days.

I'm reading two conflicting paragraphs. The first paragraph says you were able to reproduce the problem in front of the service tech with only a PC directly connected to the modem. The second paragraph says you were not able to reproduce the problem again with only a PC connected to the modem. It sounds like you let the service tech off the hook too easily. Once you proved in front of them that the direct PC was not working, that is their issue. Why was any additional testing needed? Did the tech ask you to hook pfSense back up? How can they conclude that pfSense is the issue when it wasn't even connected in that first scenario? I'm I misunderstanding something?

Raffi

The first paragraph "assumes" that pfsense is still connected to the modem, which is why the directly-connected PC experiences the same problem. The second paragraph says there were to clients to the modem (pfsense and directly-connected PC) and when I removed pfsense the continuous ping of the direclty-connected PC worked. So no conflicts in those paragraphs as they're two different scenarios.

I do think that I let the service tech off the hook easily. I must admit that I wasn't prepared to show all possible tests that time because I was in a hurry. But I'll be prepared next time which is why I'm try to pick your brains off.

They just wanted to try and remove pfsense because they didn't know anything about it. You know how incompetent service tech goes sometimes. As long as they don't know a certain software/hardware, they grow suspicious of it. I gave in because I didn't think that that would do anything to the result, but to my surprise it did. Yes, the tech asked me to hook pfsense back up and the problem repeated all over again.

Again, pfsense was connected in the first paragraph test above. It was only disconnected in the second paragraph.

Raffi_

@kevindd992002 Thanks for clearing that up. I was definitely misunderstanding it then. In that first statement, to me a PC directly connected to the modem is...
ISP ==> Modem ==> PC.

But you're saying the first scenario was actually,
ISP ==> Modem ==> pfSense ==> PC.

That first scenario had the problem so you then did this,
ISP ==> Modem ==> PC

And the problem went away. I can understand then why the tech assumed pfSense. I would have also :)

As you said, it will require more testing without pfSense to know for sure. This is easier said than done. I'm sure the very smart people on here know of ways to troubleshoot this further without removing pfSense. Personally though, if it is an option, I would put in any off the shelf router you have sitting around and see if it behaves the same over time. This would not tell you for sure if the problem is pfSense or not, but it could help as a simple sanity check. This test is not as ideal as a PC directly connected to the modem scenario (ISP ==> Modem ==> PC), but that isn't something you can realistically do for long periods of time.

I agree with others that the captures and pings provided are not adding up. The pings are going to google.com resolving to IP (216.58.200.228). The captures show pings to google's primary DNS server (8.8.8.8). Are you sure this capture was done at the same time? If so, then it looks like those pings to 216.58.200.228 are never getting to pfSense.
In fact, I even double checked this. Open up wireshark and put in the filter, ip.addr == 216.58.200.228. That IP didn't get a single hit. I would start looking at the devices or cables between the PC and pfSense on the LAN side. It could also be that PC. Try the same test from another one. See if that ping ever reaches pfSense.

Edit again after I thought about this,

Start the ping test to google.com from the PC.
Start the pfSense capture on the LAN side.
Use Wireshark filter, ip.addr == <IP google resolved to>. Is the IP for google.com coming up in the capture on the LAN side?
If not, check what I said above. The problem is not pfSense unless it is the LAN NIC on the pfSense machine.
If so, keep the ping test going from the PC.
Start the pfSense capture on the WAN side.
Use Wireshark filter, ip.addr == <IP google resolved to>. Is the IP for google.com coming up in the capture on the WAN side?

I think you get where this is going.

kevindd992002

@Raffi_ said in Non-forwarding Resolver intermittent operation:

@kevindd992002 Thanks for clearing that up. I was definitely misunderstanding it then. In that first statement, to me a PC directly connected to the modem is...
ISP ==> Modem ==> PC.

But you're saying the first scenario was actually,
ISP ==> Modem ==> pfSense ==> PC.

That first scenario had the problem so you then did this,
ISP ==> Modem ==> PC

And the problem went away. I can understand then why the tech assumed pfSense. I would have also :)

As you said, it will require more testing without pfSense to know for sure. This is easier said than done. I'm sure the very smart people on here know of ways to troubleshoot this further without removing pfSense. Personally though, if it is an option, I would put in any off the shelf router you have sitting around and see if it behaves the same over time. This would not tell you for sure if the problem is pfSense or not, but it could help as a simple sanity check. This test is not as ideal as a PC directly connected to the modem scenario (ISP ==> Modem ==> PC), but that isn't something you can realistically do for long periods of time.

I agree with others that the captures and pings provided are not adding up. The pings are going to google.com resolving to IP (216.58.200.228). The captures show pings to google's primary DNS server (8.8.8.8). Are you sure this capture was done at the same time? If so, then it looks like those pings to 216.58.200.228 are never getting to pfSense.
In fact, I even double checked this. Open up wireshark and put in the filter, ip.addr == 216.58.200.228. That IP didn't get a single hit. I would start looking at the devices or cables between the PC and pfSense on the LAN side. It could also be that PC. Try the same test from another one. See if that ping ever reaches pfSense.

Edit again after I thought about this,

Start the ping test to google.com from the PC.

Start the pfSense capture on the LAN side.

Use Wireshark filter, ip.addr == <IP google resolved to>. Is the IP for google.com coming up in the capture on the LAN side?

If not, check what I said above. The problem is not pfSense unless it is the LAN NIC on the pfSense machine.

If so, keep the ping test going from the PC.

Start the pfSense capture on the WAN side.

Use Wireshark filter, ip.addr == <IP google resolved to>. Is the IP for google.com coming up in the capture on the WAN side?

I think you get where this is going.

@Raffi_ You kinda got half of it right, sorry for not explaining better.

Scenario 1 is:

ISP -> modem -> PC (client1)
modem -> pfsense -> switch -> PC (client2)

Scenario 2 is:

ISP -> modem -> PC (client1)

So in scenario 1, I started pinging to www.google.com and the issue happens. I then removed pfsense in scenario 2 so that only client1 is seen by the modem and the problem went away.

Yes, I was sure the capture and the ping were done at the same time. And yes, the only explanations for the ping not reaching the WAN interface of the pfsense are either:

Packets from client1 not reaching the pfsense gateway somehow. I highly doubt this because when the issue happens, I also use the ping diagnostic tool from pfsense's webgui and get the same issue. I also test from another PC and get the same result so it's not isolated to just one client.
NAT issue from LAN to WAN
Default route issue from LAN to WAN

Either way, I have to do some digging myself and I'll post back with more conclusive results. Thanks to all for your help so far.

kevindd992002

All, here's another WAN packet capture when I was trying to ping to google.com (172.217.160.110):

https://www.dropbox.com/s/tp0cmy1smv1mmxv/packetcapture.cap?dl=0

You can clearly see that the first handful of echo requests where not replied to and then responses suddenly started coming. Isn't this enough proof yet the issue is at least on their network (anywhere in between modem to ISP routers)?

Raffi_

@kevindd992002 said in Non-forwarding Resolver intermittent operation:

All, here's another WAN packet capture when I was trying to ping to google.com (172.217.160.110):

https://www.dropbox.com/s/tp0cmy1smv1mmxv/packetcapture.cap?dl=0

You can clearly see that the first handful of echo requests where not replied to and then responses suddenly started coming. Isn't this enough proof yet the issue is at least on their network (anywhere in between modem to ISP routers)?

@kevindd992002 that's a good sample of data. 192.168.100.2 is the WAN address provided by the ISP? If you filter for "icmp" without the quotes, you'll see a bunch of pings never get responses. It's hit or miss and that definitely doesn't look good. It looks like you had pings going out to several different IP's and that's actually good. That tells you it's not just one server that's being moody and doesn't feel like responding to ping. A bunch of them are not responding.

My opinion in order of most likely to least likely, this points to an ISP issue/the modem itself, the cable between the modem pfSense, the WAN NIC on pfSense. The only way to rule out the last two would be to replace them.

Just to be sure, are all the stats on the Dashboard OK when this is happening? Nothing unusual like memory, CPU, state table or anything else.

Raffi

johnpoz

What is the gateway here.. 192.168.100.1? That is what device?