tofubl

OSMC on a rpi3 with a hifiberry+ has served me well for many years. Most things just work, even passthrough TV remote over i2c if the TV supports it (brand name for the implementation varies by TV manufacturer I think). My setup has been really slow in recent months, but I probably just need a new sd card... Streaming service integration in kodi isn't perfect but e.g. Netflix works well enough.

It's a bit of tinkering to get it just the way you want it, but not too much and then it's great with a lot of flexibility. I have slapped an IR LED onto a GPIO, for example, and I have a service running that checks for audio output and turns my old hifi system on and off accordingly.

Son of a gun!!! Thank you so much! I spent HOURS changing every setting except this one and actually came to the conclusion that it must be something to do with my ISP's modem or DNS or something.

The rule is the "associated filter rule" OPNsense automatically creates (interfaces are WAN and LAN) and it triggers as a "pass" just fine when I send a request. (I'm attaching another screenshot from the live log below.)

You don't happen to have a clue WHY this rule breaks everything?

Associated filter rule

Live log with associated filter rule active (leads to curl: (56) Recv failure: Connection reset by peer)

Please take a look at my updated original post. I have added some information and a tcpdump.

And I'm happy to see what sticks!

Pointing DNS to 192.168.0.1 doesn't change anything, and I'm anyway able to talk out from behind the firewall to the 192.168 net, so that would mean that address resolution works in that direction, no?

I do agree, though, that it seems like the responses are not making their way back correctly, as I can see the requests coming in and replied to in the apache logs.

I wrote it in reply to another comment, but the traffic reaches the service on 10.0.0.22:8888. The problem seems to be with the return path, ~~i.e. Hairpin NAT~~, but I don't know what it is.

edit: scratch that, it's not hairpinning.

I appreciate you taking a look. It does indeed have standard rules to drop private networks (192.168, 10.0 and so on), but I have them disabled.

The forward specifies range 8888-8888 and translates it to 8888.

Do you mean these options under Interfaces > WAN? I have them disabled after they did show up as a block in the log.

Further digging: The request reaches the docker container, which returns 200 OK.

my-apache-app | 2024-02-09T12:53:22.925676854Z 192.168.0.123 - - [09/Feb/2024:12:53:22 +0000] "GET / HTTP/1.1" 200 161

What is going on here? Do I need some rules in the other direction, on top of "Automatic outbound NAT rule generation"?

And here's what this request looks like in the firewall log:

Can you please elaborate? Who's restricting 192.168.0.x? It's not actually WAN, right? It's just a local network I connected the firewall to.

Like this?

~$ curl 192.168.0.136:8888
curl: (56) Recv failure: Connection reset by peer

Here's some more: From behind the firewall (i.e. from a 10.0.0.x IP) the port forward works (which would be a reflection, I suppose?).

From in front of the firewall, I get "connection reset", which I interpret as somewhat working but then breaking somewhere else. Does that make sense?