pfsense router behind a ZTE H1600
-
Hello
I have recently set up a local network running on a ZTE H1600 which I operate in passthrough mode. Wifi is disabled on the modem and a patch cable connects to a pfsense box to do all the routing and WIFI via a Ubiquiti AP. Since phone service is VOIP based with my provider, I assume that's the only option I have.
Setup works fine for the most part but experience occasional drops which last for a few seconds at a time. Since I don't know if those drops come from my internet provider, I thought I'd try to rule out any possible problem with my pfsense setup.
Please note I have only 2 interfaces assigned, WAN and LAN so nothing overly complicated and an OpenVPN server which I only use for remote accessing my LAN(works fine).
I have set pfsense to do PPPoE call using my provider's credentials and have also disabled Gateway Monitoring as per advice on other threads. DNS servers have also been edited to use my providers ones' with Google 8.8.8.8 and 8.8.4.4 as a backup.
Is three anything else I could double check with my setup or perhaps a few tweaks that I'm missing?
Any advice will be much appreciated!
-
J jimp moved this topic from Problems Installing or Upgrading pfSense Software on
-
Better to disable the gateway monitoring action but niot the actual monitoring. Otherwise you have no monitoring data for situations like this.
How do the 'drops' present? Unable to access external sites? Existing connections fail? Unable to access local resources?
Steve
-
@stephenw10 said in pfsense router behind a ZTE H1600:
Better to disable the gateway monitoring action but niot the actual monitoring. Otherwise you have no monitoring data for situations like this.
How do the 'drops' present? Unable to access external sites? Existing connections fail? Unable to access local resources?
Steve
Hi Steve and thank you so much for your help.
I disabled monitoring action as you suggested.
There's no problem with accessing local resources (I have a tv server and plays fines with any client in my network)
The drops are evident only when I try to reach external websites - random websites. At first I thought it had to do with DNS resolving but now I think it's something different. For example I notice youtube buffering that lasts a few seconds.
Then again it isn't too bad but if there's any fault related to my provider, I would rather submit a support ticket with them. -
Ok, well first thing is to gather some data with the monitoring enabled and see if that shows any packet loss or latency when it happens.
You should also check the system logs when it does for any event at all at that time.
Steve
-
@stephenw10 said in pfsense router behind a ZTE H1600:
Ok, well first thing is to gather some data with the monitoring enabled and see if that shows any packet loss or latency when it happens.
You should also check the system logs when it does for any event at all at that time.
Steve
After disabling monitoring action, I haven't noticed any problem so far. I don't know if that's coincidental or perhaps it actually helped?
Will gather some info and logs and report back if the problem re-appears!
Thanks Steve!
-
@stephenw10 said in pfsense router behind a ZTE H1600:
Ok, well first thing is to gather some data with the monitoring enabled and see if that shows any packet loss or latency when it happens.
You should also check the system logs when it does for any event at all at that time.
Steve
Well Steve I got the following error.
I have hided the WAN IP but the Gateway logs look like this:Oct 17 21:47:52 dpinger 93309 WAN_PPPOE **.***.***.***: sendto error: 65 Oct 17 21:47:52 dpinger 93309 WAN_PPPOE **.***.***.***: sendto error: 65 Oct 17 21:47:53 dpinger 93309 WAN_PPPOE **.***.***.***: sendto error: 65 Oct 17 21:47:53 dpinger 93309 WAN_PPPOE **.***.***.***: sendto error: 65 Oct 17 21:47:54 dpinger 93309 WAN_PPPOE **.***.***.***: sendto error: 65 **.***.***.*** dpinger 93309 WAN_PPPOE **.***.***.***: sendto error: 65 Oct 17 21:47:55 dpinger 93309 WAN_PPPOE **.***.***.***: sendto error: 65 Oct 17 21:47:55 dpinger 93309 WAN_PPPOE **.***.***.***: sendto error: 65 code_text -
That's the WAN IP or the gateway IP?
https://docs.netgate.com/pfsense/en/latest/troubleshooting/gateway-errors.html#sendto-error-65What IP are you using for monitoring?
Do the ppp or system logs show anything at that time?
Does it start responding again after than without intervention?
Steve
-
@stephenw10 said in pfsense router behind a ZTE H1600:
That's the WAN IP or the gateway IP?
https://docs.netgate.com/pfsense/en/latest/troubleshooting/gateway-errors.html#sendto-error-65What IP are you using for monitoring?
Do the ppp or system logs show anything at that time?
Does it start responding again after than without intervention?
Steve
It's the gateway IP indeed. My mistake.It's the gateway IP indeed. My mistake.
I can't see any errors under system logs or PPP. It starts responding again without myself doing anything.
With regards to what IP I'm using for monitoring, if I understand the question correctly, it's a local 192.168.2.X assigned by pfsense DHCP server to my laptop.
Could it be an authentication problem related to the username and password under WAN PPPoE settings?
The format of the username and password I entered are:
Username: ysp
PASSWORD: mb_m2
(I have obviously changed/hidden characters but that's how they look like.)Shouldn't the username be in a format with a domain extention?
For example:
ys*p@otenet.gr -
The WAN monitoring IP by default is the upstream gateway IP as shown in the logs there. However you can change that in System > Routing > Gateways, edit the WAN.
It's usually more useful to monitor something further upstream like 8.8.8.8. That way if your ISP has some connectivity issue you see it even if the link between you and them remains up.
So I would do that first and make sure it's logging the monitoring data for the gateway.That sendto error implies it's lost a route to the gateway which I would only expect to happen when the PPPoE session reconnects. That would be in the ppp log though.
It's not an authentication issue. It would never connect at all if it was.
Steve
-
@stephenw10 said in pfsense router behind a ZTE H1600:
The WAN monitoring IP by default is the upstream gateway IP as shown in the logs there. However you can change that in System > Routing > Gateways, edit the WAN.
It's usually more useful to monitor something further upstream like 8.8.8.8. That way if your ISP has some connectivity issue you see it even if the link between you and them remains up.
So I would do that first and make sure it's logging the monitoring data for the gateway.hat sendto error implies it's lost a route to the gateway which I would only expect to happen when the PPPoE session reconnects. That would be in the ppp log though.
It's not an authentication issue. It would never connect at all if it was.
Steve
Got it.
I will edit the monitoring IP to Google 8.8.8.8 and see what the logs report back. Then I will post my findings.Thank you so much Steve.
-
@stephenw10 said in pfsense router behind a ZTE H1600:
The WAN monitoring IP by default is the upstream gateway IP as shown in the logs there. However you can change that in System > Routing > Gateways, edit the WAN.
It's usually more useful to monitor something further upstream like 8.8.8.8. That way if your ISP has some connectivity issue you see it even if the link between you and them remains up.
So I would do that first and make sure it's logging the monitoring data for the gateway.That sendto error implies it's lost a route to the gateway which I would only expect to happen when the PPPoE session reconnects. That would be in the ppp log though.
It's not an authentication issue. It would never connect at all if it was.
Steve
Hey Steve,
Here are some of my Gateway logs
Oct 19 12:30:36 dpinger 19498 WAN_PPPOE 8.8.8.8: Alarm latency 42752us stddev 9438us loss 21% Oct 19 13:11:33 dpinger 19498 WAN_PPPOE 8.8.8.8: Alarm latency 44275us stddev 16872us loss 21% Oct 19 13:25:11 dpinger 19498 WAN_PPPOE 8.8.8.8: Alarm latency 57022us stddev 27156us loss 21% Oct 19 13:23:22 dpinger 19498 WAN_PPPOE 8.8.8.8: Alarm latency 58050us stddev 22253us loss 21% Oct 19 13:14:02 dpinger 19498 WAN_PPPOE 8.8.8.8: Alarm latency 61951us stddev 22204us loss 21% Oct 19 12:23:24 dpinger 4156 WAN_PPPOE 8.8.8.8: Alarm latency 68757us stddev 6234us loss 21% Oct 19 12:21:29 dpinger 4156 WAN_PPPOE 8.8.8.8: Alarm latency 73096us stddev 33525us loss 21% Oct 19 12:31:33 dpinger 19498 WAN_PPPOE 8.8.8.8: Clear latency 42567us stddev 8611us loss 5% Oct 19 13:20:57 dpinger 19498 WAN_PPPOE 8.8.8.8: Clear latency 45311us stddev 30738us loss 10% Oct 19 13:24:20 dpinger 19498 WAN_PPPOE 8.8.8.8: Clear latency 50155us stddev 18800us loss code_text -
Looks like those logs are not in time order but that looks like real latency on the WAN though.
Check the Status > Monitoring graphs to see how it varies over time.
-
@stephenw10 said in pfsense router behind a ZTE H1600:
Looks like those logs are not in time order but that looks like real latency on the WAN though.
Check the Status > Monitoring graphs to see how it varies over time.
Hey Steve. Thought I'd report back about my issue.
It looks like that ''double NAT'' was causing that latency problem.
I disabled VDSL NAT within ZTE settings leaving pfsense to do the job. I think I haven't had any problem ever since I changed that.Could that be what was causing the problem?
-
Hmm, I wouldn't expect that to introduce any significant latency to be honest. Unless it was hitting some limit in the ZTE router. Commonly that can be a state limit with low end routers but I wouldn;t expect that to hit gateway monitoring as it's one of the first states created.
Steve
-
@stephenw10 said in pfsense router behind a ZTE H1600:
Hmm, I wouldn't expect that to introduce any significant latency to be honest. Unless it was hitting some limit in the ZTE router. Commonly that can be a state limit with low end routers but I wouldn;t expect that to hit gateway monitoring as it's one of the first states created.
Steve
I was expecting / hoping that was the problem. :(
I will keep an eye out if the problem's still there in the next few hours. -
It could be you are bypassing some other features in the ZTE router by passing the connection through. It might have some traffic shaping for example.
-
Hi Steve,
Just wanted to update my situation.
An electrician came in to check the line and wiring and also changed the phone socket however nothing's changed unfortunately. It might be slightly better but I'm still getting latency alerts here and there.Would a roll-back to a previous depreciated pfsense version help my situation? There's a video on youtube on which the user ended going back to 2.4.4 - that helped to mitigate the problem.
-
I would not expect it to. And it's almost impossible to recommend doing something like that from a security stand point. Except maybe purely as a test.
Steve
