OPNsense Forum
Archive => 18.1 Legacy Series => Topic started by: Davesworld on February 12, 2018, 12:44:22 am
-
I noticed after I upgraded to the 18.1 series, that I could no longer stream video reliably from Amazon Prime, Vudu and others over my Roku. Cell phones also would not reliably work while connecting via wifi. I tried the Roku with WLAN and LAN with the same result. Netflix would work but it took a slight while to find it's way but was at least usable.
I tried switching ADSL modems and even using a second ADSL line that I have to no avail. I tried doing a clean install with the same result. Subsequent updates did not improve anything. I then resinstalled IPCop which is at the end of it's life and everything worked again. I then installed OPNSense 17.5 and imported the same config I had been using in 18.2, well now everything works again.
It should be noted that I noticed the degradation as soon as I updated to 18.1 ands second guessed myself as surely 18.1 could not be that much different but there is something inherent.
It should be noted that when I had my cellphone connected to 18.1 via wifi, Android updates were a struggle and woud often fail. The search function of of Roku itself would not work and if I could get into Amazon and others at all after many tries the images were spotty loading. What could have changed? I'm afraid to update to the 18.1 series at this point.
Although minor, with 18.1 clicking on updates from the lobby, it would go to the updates page and time out, it would work when I click on Check For Updates once on the Firmware page after it failed the first time.
I just upgraded again, yes, the upgrade to the 18 series messed it up so it is not my ISP. Now as to why?
-
Here is my Roku Ultra talking to Amazon Streaming:
tcp In 192.168.6.16:41984 54.148.50.235:443 FIN_WAIT_2:ESTABLISHED
-
And my Wan trying to talk to Amazon Streaming.
tcp Out 104.235.165.41:43466 54.148.50.235:443 ESTABLISHED:FIN_WAIT_2
I've decided not to redact my WAN ip, it's dynamic and I get a few thousand scans a day anyway.
-
Looking at PF States, Netflix does not use SSL just port 80.
-
I went through almost all possible updates, beginning with 17.5, continuing with development builds, ending up with 18.1.2
My Nvidia Shield connects to streaming services instantly, I hardly ever see any progress icons.
My wifi APs (separate devices) also work fine.
Strange...
-
For the time being I reinstalled 17.x and upgraded to 17.7.12 and have unfettered internet access. I will start poking through GIT and see if I can find something. Yes it is strange.
-
If you did not update to 18.1.2 then that could be the problem. There are known NAT issues with 18.1 that were quickly resolved with a patch.
-
I stream via Plex to many folks, Amazon Prime and Netflix. Currently running at 18.1.2 and noticed no issues.
I have a TorGuard VPN going for some traffic along with a OpenVPN for Home access with traffic shaping as well.
I haven't noticed anything not working with NAT at this point.
-
If you did not update to 18.1.2 then that could be the problem. There are known NAT issues with 18.1 that were quickly resolved with a patch.
I did update to 18.2 in three separate sessions, the original gui update from my system that had been running for months, my fresh install after that and another 17.x install with gui updates to 18.2.
-
I don't have Roku, but streaming does not seem to be an issue for me in 18.1.2
-
I don't have Roku, but streaming does not seem to be an issue for me in 18.1.2
It happens on two different rokus, two different smart phones and one laptop. It's not just streaming, the cell phones fall flat on their faces when trying to do android upgrades as well and other things are pretty bad too.
-
Disable IDS and see if that helps. At least you can eliminate it as a suspect.
Anything unusual in the system logs?
-
Disable IDS and see if that helps. At least you can eliminate it as a suspect.
Anything unusual in the system logs?
I'm back up to the latest patch. I do not use IDS at this time anyway but that's a whole different subject. I'm looking at firewall logs as I try to start movies, I might as well dedicate the rest of today trying to find this.
-
This is interesting and from my roku.
WLAN Feb 12 13:53:01 192.168.6.16:59387 13.32.253.65:80 tcp Default deny rule 
WLAN Feb 12 13:53:00 192.168.6.16:59387 13.32.253.65:80 tcp Default deny rule 
WLAN Feb 12 13:52:59 192.168.6.16:59387 13.32.253.65:80 tcp Default deny rule 
WLAN Feb 12 13:52:59 192.168.6.16:59385 13.32.253.65:80 tcp Default deny rule 
WLAN Feb 12 13:52:59 192.168.6.16:59387 13.32.253.65:80 tcp Default deny rule
-
Default deny usually means state tracking failure. Try adding a separate rule for sloppy or no state tracking (under advanced) to see if these go away.
Cheers,
Franco
-
I have also seen Default state rules that should have passed. I was assuming that these were RST or FIN packets that were retried and passed. The firewall log view no longer shows the TCP flags. Need to put that back. Along with adding an allow rule. Or just bring back the Normal log as an additional option. I like the live view, but I miss the normal view.
-
Default deny usually means state tracking failure. Try adding a separate rule for sloppy or no state tracking (under advanced) to see if these go away.
Cheers,
Franco
I added what you described and set my original rule to allow outgoing to any rule to log and added a sloppy state rule and set it for logging. The sloppy rule never gets used that I can see but here is a traceroute to one of the ips used by Amazon streaming from the firewall itself, it ran for five minutes before finishing.
root@phaedra:~ # traceroute 54.239.29.128
traceroute to 54.239.29.128 (54.239.29.128), 64 hops max, 40 byte packets
1 50.34.160.1 (50.34.160.1) 5.276 ms 5.211 ms 4.985 ms
2 ae3---0.car01.evrt.wa.frontiernet.net (74.40.70.5) 5.224 ms 5.323 ms 5.468 ms
3 ae3---0.cor02.sttl.wa.frontiernet.net (74.40.1.101) 50.752 ms 50.928 ms 50.760 ms
4 xe--11-0-0---0.cor01.mond.mn.frontiernet.net (74.40.5.45) 61.673 ms 52.924 ms 52.794 ms
5 ae0---0.cor01.lkvl.mn.frontiernet.net (74.40.5.53) 53.462 ms 54.006 ms 53.164 ms
6 ae4---0.cor01.chcg.il.frontiernet.net (74.40.5.50) 51.688 ms 51.450 ms 51.440 ms
7 ae0---0.cbr01.chcg.il.frontiernet.net (74.40.4.138) 52.323 ms 53.121 ms 52.298 ms
8 static-74-43-96-134.fnd.frontiernet.net (74.43.96.134) 50.299 ms 49.924 ms 51.189 ms
9 52.95.62.120 (52.95.62.120) 61.930 ms
52.95.62.136 (52.95.62.136) 62.922 ms
52.95.62.104 (52.95.62.104) 63.246 ms
10 52.95.62.45 (52.95.62.45) 50.231 ms
52.95.62.113 (52.95.62.113) 54.130 ms
52.95.62.61 (52.95.62.61) 50.145 ms
11 54.239.42.59 (54.239.42.59) 69.174 ms
54.239.43.211 (54.239.43.211) 70.853 ms
52.95.62.153 (52.95.62.153) 70.381 ms
12 54.239.42.69 (54.239.42.69) 72.160 ms
54.239.43.30 (54.239.43.30) 71.427 ms *
13 * * *
14 * * *
15 * * 54.240.229.182 (54.240.229.182) 77.946 ms
16 52.93.25.28 (52.93.25.28) 90.474 ms
54.239.108.48 (54.239.108.48) 85.348 ms
52.93.25.30 (52.93.25.30) 98.087 ms
17 54.239.43.158 (54.239.43.158) 71.053 ms
52.93.24.118 (52.93.24.118) 70.998 ms
205.251.244.23 (205.251.244.23) 71.826 ms
18 54.239.109.168 (54.239.109.168) 101.428 ms * *
19 205.251.244.61 (205.251.244.61) 71.181 ms *
54.239.108.252 (54.239.108.252) 90.869 ms
20 * * *
21 52.93.27.199 (52.93.27.199) 84.696 ms *
52.93.24.104 (52.93.24.104) 72.831 ms
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
31 * * *
32 * * *
33 * * *
34 * * *
35 * * *
36 * * *
37 * * *
38 * * *
39 * * *
40 * * *
41 * * *
42 * * *
43 * * *
44 * * *
45 * * *
46 * * *
47 * * *
48 * * *
49 * * *
50 * * *
51 * * *
52 * * *
53 * * *
54 * * *
55 * * *
56 * * *
57 * * *
58 * * *
59 * * *
60 * * *
61 * * *
62 * * *
63 * * *
64 * * *
root@phaedra:~ #
-
I have also seen Default state rules that should have passed. I was assuming that these were RST or FIN packets that were retried and passed. The firewall log view no longer shows the TCP flags. Need to put that back. Along with adding an allow rule. Or just bring back the Normal log as an additional option. I like the live view, but I miss the normal view.
Adding a selector for all shown properties of the log entry is not a large problem...
-
It only finished tracing because TTL was depleted, which means the route was not found even though it bumped around for a bit. This could be a NAT side-effect or a problem with the tracing. Does the TCP / UDP stream time out too?
Cheers,
Franco
-
Does the TCP / UDP stream time out too?
Cheers,
Franco
Definitely does.
-
Same is happening for me. At least the trace route. Cannot double-check against 17.7 ATM.
Cheers,
Franco
-
I would hope that NAT is not being used for port 80 and 443 streaming. That is what Roku, Amazon, Netflix, etc use. Disable NAT and see if streaming improves.
I suspect that NAT may be the issue because the way NAT is handled seems to have changed starting with version 18.1. Correct me if I am wrong Franco. Try disabling NAT altogether. Put it back later if you need it for other things.
And if you want better help, post your firewall and NAT configuration. Use Aliases to hide IP's.
More than likely a configuration issue since no one else has complained about streaming.
-
I have also seen Default state rules that should have passed. I was assuming that these were RST or FIN packets that were retried and passed. The firewall log view no longer shows the TCP flags. Need to put that back. Along with adding an allow rule. Or just bring back the Normal log as an additional option. I like the live view, but I miss the normal view.
Adding a selector for all shown properties of the log entry is not a large problem...
Do you mean for the devs to add the selector, or does this exist now?
-
Do you mean for the devs to add the selector, or does this exist now?
Data is pushed through, but the columns are not rendered. We should add all columns (most of them hidden by default) and add a selector to tweak the live log. Details show all in any case. Added a ticket already:
https://github.com/opnsense/core/issues/2195
-
Disable NAT and see if streaming improves.
I suspect that NAT may be the issue because the way NAT is handled seems to have changed starting with version 18.1. Correct me if I am wrong Franco. Try disabling NAT altogether. Put it back later if you need it for other things.
And if you want better help, post your firewall and NAT configuration. Use Aliases to hide IP's.
More than likely a configuration issue since no one else has complained about streaming.
Disabling NAT made no difference, I never messed with NAT to begin with at any step along the initial install and upgrade path. As far as config, assigned interfaces, added outgoing rules to WLAN as well as static DHCP entries, of course I have the same streaming issue over lan as well. I do have the proxy enabled and acl downloaded and streamlined but I am not running proxy in transparent, I have to manually direct the browser to use the proxy. I added a second IP on WAN and a gateway to it so I could access the DSL modem which is in bridge mode. I already tried removing the second ip and gateway for the modem and that made no difference.
As far as the nobody else is complaining, it does not mean it is not happening.
-
Could be NAT, yes, but need to figure out if kernel side or rules side is changing this for the worse.
I know FreeBSD poked pf ICMP NAT behaviour a while back, maybe 11.1 is not perfect yet...
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201519
https://lists.freebsd.org/pipermail/freebsd-pf/2017-February/008383.html
Better try this and skip pf, but make sure you are connected via console (not SSH) to issue the enable:
# pfctl -d
Test stuff...
# pfctl -e
Back to normal
-
As far as the nobody else is complaining, it does not mean it is not happening.
That is totally correct. Your setup is definitely different than mine.
Never had much luck with ADSL, but then the copper here is 50+ years old.
Maybe have the ISP run a connectivity test just to rule it out.
-
As far as the nobody else is complaining, it does not mean it is not happening.
I don't think that's what anybody was implying. I confirmed your traceroute issue, but around 12:52 a.m. I have no way to sanely verify it against an older version. :)
Cheers,
Franco
-
As far as the nobody else is complaining, it does not mean it is not happening.
I don't think that's what anybody was implying. I confirmed your traceroute issue, but around 12:52 a.m. I have no way to sanely verify it against an older version. :)
Cheers,
Franco
Definitely do not want to keep you up. Thanks for confirming this. I definitely do like some things about 18.x otherwise. Thanks again!
-
Default deny usually means state tracking failure. Try adding a separate rule for sloppy or no state tracking (under advanced) to see if these go away.
Cheers,
Franco
Do you mean clone the LAN pass rule, but add sloppy or no state tracking?
I am getting a lot of these, but the ports are actually working which means to me that there is probably a RST or FIN flag set. Take a look at the pics. You will see I have a LAN2 rule, but the firewall log shows that traffic as a default deny rule. LAN2 is 192.168.10.1/24
-
Referring to the previous post,
And here are more examples of default deny rules that have a matching pass rule.
How can I tell if these are legit or just fragmentation?
Added a cloned LAN2 sloppy rule.
How do I get rid of fragmented packets in the logs? Or do I even need to. They seem to appear mostly after a reboot and slowly disappear after a while.
-
I noticed that they seem to fade out after a time. I am watching the live view. This of course seems to be totally unrelated to my problem that I started this thread with. I've been following GIT to watch the changes.
-
That's fragmentation which eventually goes away, mostly.
That's why I want to see flags in the firewall view.
-
I had a chance to do a traceroute to the same IP as I showed before as well as a different one to another streaming service with 17.7.12, 18.1.2_2 as well as a firewall running IPCop, they time out about the same, the only difference is that OPNsense waited a lot longer before completely timing out and returning to the command prompt. The IPCop firewall is on a different ADSL connection but the same ISP CO and all that. This was just chasing a ghost however even tracerouting to both firewalls using yahoo.com times out after 10 steps followed by rows of double asterisks. Google makes it to 8 hops and finishes properly so I think I'm finished with tracerouting for now.
17.7.12 still works well but 18.1.2_2 does not so this remains. I really like the live view in the firewall logs much better in 18.x though as it is cleaner and you can isolate to one ip and only watch that if wanted. I just got up and don't have a few cups of coffee in me yet.
-
I am running 18.1.3 which while much nicer to work with did not solve the problem nor is it creating it. I rebooted to the old 11.0 kernel and everything works fine. I began to wonder about the 11.1 kernel. It is completely usable for me with 18.1.x and the 11.0 kernel from 17.7. I marked it as semi-solved since at least I know where the problem actually is.
-
Enabling Sticky Outbound Nat seems to have fixed the problem.
-
Also here for reference, can you try this patch instead? https://github.com/opnsense/core/commit/7a823c56a
# opnsense-patch 7a823c56a
All testing and feedback welcome.
Cheers,
Franco
-
I also applied the patch. All good here :)
-
Should be a NOP for WANs with only a single IP. The question is if the folks with VIPs on WAN have a better life with this in place. :)
Cheers,
Franco
-
I have VIP's on one box with 3 external static IP's. Did an Android update via 5G WiFi and streamed a couple of Amazon movies via the Samsung TV app with no issues. Did not apply the patch yet. Should I? Willing to test anything you need
This box does not use any NAT 1:1 or PF rules to the LAN net. I like to avoid NAT 1:1 rules when possible. Has manual Outbound NAT rules with one auto created rule on the 192.168.1.1 LAN net.
-
Oh, ok. Reversed :d But it worked well anyway :D
-
I also applied the patch. All good here :)
Just tried the patch and disabled sticky NAT, streaming DirecTVnow steady as a rock. Like I stated on the git ticket, I'm going to flog this firewall this weekend, I'm optimistic that the patch fixed it.
-
Hi All,
I have a new opnsense install, just moved over from pfsense (4+ years). I found this thread and it looks like I maybe having some of the same problems.
I applied the above patch, but I'm still having issues. Setup is basic, with an openVPN client setup as a gateway. Whenever the openVPN client is active, DNS goes down, even on the lan side with local clients. I can still ping the ip addresses of local and external clients like 8.8.8.8.
I found if I made a firewall rule allowing local clients to send DNS packets to the firewall, it will resolve the names. But there are still almost random requests being denied with "default deny rule".
Anyone else having these issues?
They are only present when I have the openVPN client active.
When I deactivate it, everything works as normal.
Check the attached photos for an idea of what it looks like.
Appreciate any ideas or help any of you may have.
Thanks!
PS-love what you guys are doing with opnsense, was frustrated with the last pfsense 2.4 release, the web GUI is horrible.
-
Here are the other two photos of my setup:
-
Does not look like the problem described previously, which was addressed in a patch that is queued up for inclusion in 18.1.6.
Default deny usually means state tracking was too aggressive, which could be the case due to retransmits, switch gear, network loops, asymmetric traffic, etc. You can try to set your OpenVPN gateway rule to "slopply" or "none" state tracking and see if that helps.
Cheers,
Franco
-
Hi Franco,
Thanks for the help. Sloppy didn't work, but "none" does on the default LAN firewall rule.
You have any suggestions on where to start troubleshooting what could be wrong with my network?
I didn't have this problem till the upgrade from PFsense 2.3 to 2.4. I then moved to Opnsense to see if it was any better.
Have been getting it on both platforms.
Could this be due to the FreeBSD update from 10.3 to 11.1?
If its set to "none" doesn't that disable packet inspection?
Thanks again for your help.
-
Does not look like the problem described previously, which was addressed in a patch that is queued up for inclusion in 18.1.6.
Default deny usually means state tracking was too aggressive, which could be the case due to retransmits, switch gear, network loops, asymmetric traffic, etc. You can try to set your OpenVPN gateway rule to "slopply" or "none" state tracking and see if that helps.
Cheers,
Franco
OK, I missed the part about it not being included until 18.1.6. I would guess it would be best to uninstall the patch just prior to 18.1.6 when it comes?
-
Yes, 18.1.6 due to an extra round if testing. No need to do anything when it hits. Manual patches to core files are overwritten on firmware updates for consistency. You don't have to revert it again, only check whether the incoming updates (all of them) include the fix you want and skip or reapply the patch in the meantime. :)
Cheers,
Franco