[SOLVED]18.1 will not route to some sites and services, 17.x works fine.

[dcol]

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.

[Davesworld]

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

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

Adding a selector for all shown properties of the log entry is not a large problem...

[franco]

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

[Davesworld]

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

Definitely does.

[franco]

Same is happening for me. At least the trace route. Cannot double-check against 17.7 ATM.


Cheers,
Franco

[dcol]

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.

[dcol]

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?

[franco]

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

[Davesworld]

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.

[franco]

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

[dcol]

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.

[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

[Davesworld]

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!

[dcol]

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