Messages

That usually happens with me every time as well. I just log in again, when you see a blank screen after logging in again, hit enter and you will see the installer again depending on where it crashed. While annoying, it has never prevented me from getting through the install and I know the password pretty well after three or four times of having to log in.

Unrelated but useful is the fact that you can log in as root, set up all your interfaces, log out, log in as installer and install and it will install with the network set up the way you wanted, namely ip. This way you can log into the ip right away when it reboots via web browser. I never use 192.168.1.x as the lan network, some modems use 192.168.1.1 as their ip as well as other things, everyone can't be 192.168.1.1 and not everything uses DHCP by default.

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.

Enabling Sticky Outbound Nat seems to have fixed the problem.

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.

Had some issues with IPS/IDS enabled. There was a rule (or two) blocking wu. I would start there. Also try disabling IPS/IDS, see if this helps and to rule out IDS if it's not the case.

People are quick to jump on the IDS bandwagon when someone complains of routing problems in 18.1 because they assume everyone uses it which is very wrong not to mention that rules should not behave any differently on PFSense versus OPNsense much less 17.7 to 18.1 so put that to rest.

The installer usually crashes on me, I manually install making a mirror raid, when it crashes I simply log in again as installer, password opnsense and carry on, I usually get a few crashes I nurse my way through. Once partitioning is over it's smooth sailing.

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 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.

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!

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.

Does the TCP / UDP stream time out too?
Cheers,
Franco

Definitely does.

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:~ #

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

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.

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.