SOLVED: Accessing the web server

[TheDreadPirate]

And you have NOT made any changes to Jellyfin's network config?

For testing, can you bring down your wireguard interface and then restart Jellyfin? After it finishes starting, can you check the log to see if it found any interfaces? "Filtered interface addresses".

I don't THINK that should matter. Plenty of other people running wireguard, or other VPNs on top of wireguard, and Jellyfin would find both the physical interface and VPN interface.

---

Didn't see your post before submitting.

Are you able to access Jellyfin via the WG or LAN IP now? Is port 8096 open on the host?

[ArbitraryRenaissance]

Sorry for the sporadic posts. I thought that the undetected interface addresses might have had something to do with me explicitly defining the bind address to 0.0.0.0 in the Jellyfin network settings, which I undid later.

Anyway, no -- I'm not able to access Jellyfin via the LAN IP now. As for port 8096 being open, I thought the Jellyfin service did that automatically. The output of sudo ss -tulpn is

Code:

Netid   State    Recv-Q   Send-Q                           Local Address:Port        Peer Address:Port   Process
udp     UNCONN   0        0                                      0.0.0.0:5353             0.0.0.0:*       users:(("systemd-resolve",pid=496,fd=15))
udp     UNCONN   0        0                                      0.0.0.0:5355             0.0.0.0:*       users:(("systemd-resolve",pid=496,fd=11))
udp     UNCONN   0        0                                      0.0.0.0:7359             0.0.0.0:*       users:(("jellyfin",pid=17862,fd=437))
udp     UNCONN   0        0                                   127.0.0.54:53               0.0.0.0:*       users:(("systemd-resolve",pid=496,fd=22))
udp     UNCONN   0        0                                127.0.0.53%lo:53               0.0.0.0:*       users:(("systemd-resolve",pid=496,fd=20))
udp     UNCONN   0        0                                      0.0.0.0:32920            0.0.0.0:*
udp     UNCONN   0        0                                         [::]:5353                [::]:*       users:(("systemd-resolve",pid=496,fd=16))
udp     UNCONN   0        0                                         [::]:5355                [::]:*       users:(("systemd-resolve",pid=496,fd=13))
udp     UNCONN   0        0                                         [::]:32920               [::]:*
udp     UNCONN   0        0          [fe80::b28b:ef2d:b148:1963]%enp42s0:546                 [::]:*       users:(("NetworkManager",pid=736,fd=28))
tcp     LISTEN   0        4096                                   0.0.0.0:5355             0.0.0.0:*       users:(("systemd-resolve",pid=496,fd=12))
tcp     LISTEN   0        512                                    0.0.0.0:8096             0.0.0.0:*       users:(("jellyfin",pid=17862,fd=466))
tcp     LISTEN   0        128                               192.168.1.23:22               0.0.0.0:*       users:(("sshd",pid=837,fd=8))
tcp     LISTEN   0        128                               10.100.100.3:22               0.0.0.0:*       users:(("sshd",pid=837,fd=7))
tcp     LISTEN   0        4096                                127.0.0.54:53               0.0.0.0:*       users:(("systemd-resolve",pid=496,fd=23))
tcp     LISTEN   0        4096                             127.0.0.53%lo:53               0.0.0.0:*       users:(("systemd-resolve",pid=496,fd=21))
tcp     LISTEN   0        4096                                      [::]:5355                [::]:*       users:(("systemd-resolve",pid=496,fd=14))

I also have a firewall rule in place in ufw that allows 8096 to be open:

Code:

(# ufw status numbered)
     To                         Action      From
     --                         ------      ----
[ 1] 22/tcp                     ALLOW IN    Anywhere
[ 2] 8096                       ALLOW IN    Anywhere
[ 3] 22/tcp (v6)                ALLOW IN    Anywhere (v6)
[ 4] 8096 (v6)                  ALLOW IN    Anywhere (v6)

I may need a similar rule in place on my OPNsense router, but I wouldn't know why, since I don't remember needing one for SSH.

[TheDreadPirate]

The UFW rule is what I'm looking for. Jellyfin does not open the host firewall automatically on Linux (it does on Windows during install). The "Automatic port mapping" is for creating a uPnP rule on your router. Which would be used for remote access.

What is the output of "sudo ufw status verbose"? Did you set any additional UFW restrictions? Like default deny on outgoing traffic? I'm assuming no based on your current rules, but I have to ask.

I also don't know what your network topology is like. Sounds like it is more complex than a typical user's "flat" (single VLAN) network. Are your server and clients on the same VLAN?

[ArbitraryRenaissance]

Code:

(# ufw status verbose)
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To                        Action      From
--                        ------      ----
22/tcp                    ALLOW IN    Anywhere
8096                      ALLOW IN    Anywhere
22/tcp (v6)                ALLOW IN    Anywhere (v6)
8096 (v6)                  ALLOW IN    Anywhere (v6)

If my network topology is more complex than a typical user's network, it's not by intention.  As I said in my initial post, I have a road warrior setup through wireguard, which I built using the OPNsense documentation as a guide.  Here's the link, which will spell out the interfaces and firewall rules that I would have on my system associated with this: https://docs.opnsense.org/manual/how-tos...lient.html

In addition to this, I've installed a gateway to Mullvad's VPN servers, which I built using a guide spelled out on the OPNsense forums: https://forum.opnsense.org/index.php?topic=38550.0

In order to get SSH working, I had to introduce one extra rule to force local traffic to bypass this gateway.  I'll include a picture of the table that includes the floating rules in my firewall.  "Moles" is an alias of devices (identified with the wg0 interface) for which WAN traffic is meant to be tunneled through Mullvad first.  This at the moment includes my NAS (which holds the Jellyfin server) and my main computer (which is trying to access it).  HomeVPN is the more descriptive name for wg0.

[TheDreadPirate]

Can you add a rule for Jellyfin in the same manor as your ssh rule?

[ArbitraryRenaissance]

I'm not entirely sure what you mean. I didn't directly place an SSH rule into my firewall. All I did with SSH was edit /etc/ssh/sshd_config, and I think it automatically added the TCP rule over port 22 in the iptables.

[TheDreadPirate]

I'm not familiar with OPNSense nor the guides you've linked. But if your HOST firewall is open on port 8096 and Jellyfin is running, but you're still not able to access it this tells me something about how your router is configured is preventing the connection attempts.

I don't know enough about OPNSense or your setup to get more specific than that.

[ArbitraryRenaissance]

The frustrating thing is that when I look at the firewall logs on my router, they are explicitly permitting these connection attempts when I attempt to make a connection over wireguard. When I attempt to connect over LAN, however, the logs are silent. I guess I'll keep doing some troubleshooting. Maybe I can try tracing the path of a connection attempt to see where it gets refused.

[ArbitraryRenaissance]

I don't know if this is helpful information, but I figured doing a tcpdump might point to some clues. The following command was run on my NAS, with the output below -- each line wiht at timestamp corresponds to when I hit the refresh button on my browser when trying to connect to my jellyfin server on my main computer:

Code:

[arby@Nash ~]$ sudo tcpdump -i any port 8096
tcpdump: WARNING: any: That device doesn't support promiscuous mode
(Promiscuous mode not supported on the "any" device)
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
14:39:33.764714 enp42s0 In  IP 192.168.1.112.41594 > Nash.8096: Flags [S], seq 2269463872, win 64240, options [mss 1460,sackOK,TS val 303552957 ecr 0,nop,wscale 7], length 0
14:39:43.088673 enp42s0 In  IP 192.168.1.112.35156 > Nash.8096: Flags [S], seq 3055431730, win 64240, options [mss 1460,sackOK,TS val 303562281 ecr 0,nop,wscale 7], length 0
14:39:43.995989 enp42s0 In  IP 192.168.1.112.52606 > Nash.8096: Flags [S], seq 3005522015, win 64240, options [mss 1460,sackOK,TS val 303563188 ecr 0,nop,wscale 7], length 0
14:39:44.776940 enp42s0 In  IP 192.168.1.112.52612 > Nash.8096: Flags [S], seq 3852564276, win 64240, options [mss 1460,sackOK,TS val 303563969 ecr 0,nop,wscale 7], length 0
14:39:45.434303 enp42s0 In  IP 192.168.1.112.52626 > Nash.8096: Flags [S], seq 3468579809, win 64240, options [mss 1460,sackOK,TS val 303564626 ecr 0,nop,wscale 7], length 0

So my NAS is receiving the connection request. It just doesn't seem to be responding to it.

[TheDreadPirate]

Try specifying the interface. Based on the warning at the beginning, I'm wondering if it isn't capturing the responses in the non-promiscuous mode it is running in. When I do a tcpdump I am seeing the responses.