Can access plex via my IOT vlan but not my inhouse vlan.
-
@johnpoz did the same again from settings above except now with port 32400 filtering. I run this while trying plex from that ip.
Yes the 192.168.10 is the interface i have selected (perslan)
00:08:56.076986 IP 192.168.31.12.59711 > 192.168.10.4.32400: tcp 0 00:08:56.233080 IP 192.168.31.12.59717 > 192.168.10.4.32400: tcp 0 00:08:56.357681 IP 192.168.31.12.59726 > 192.168.10.4.32400: tcp 0 00:08:56.357751 IP 192.168.31.12.59727 > 192.168.10.4.32400: tcp 0 00:08:57.079493 IP 192.168.31.12.59711 > 192.168.10.4.32400: tcp 0 00:08:57.233644 IP 192.168.31.12.59717 > 192.168.10.4.32400: tcp 0 00:08:57.505633 IP 192.168.31.12.59727 > 192.168.10.4.32400: tcp 0 00:08:57.505658 IP 192.168.31.12.59726 > 192.168.10.4.32400: tcp 0 00:08:58.089088 IP 192.168.31.12.59711 > 192.168.10.4.32400: tcp 0 00:08:58.233331 IP 192.168.31.12.59717 > 192.168.10.4.32400: tcp 0 00:08:58.553271 IP 192.168.31.12.59726 > 192.168.10.4.32400: tcp 0 00:08:58.553333 IP 192.168.31.12.59727 > 192.168.10.4.32400: tcp 0 00:08:59.081329 IP 192.168.31.12.59711 > 192.168.10.4.32400: tcp 0 00:08:59.251403 IP 192.168.31.12.59717 > 192.168.10.4.32400: tcp 0 00:08:59.364912 IP 192.168.31.12.59726 > 192.168.10.4.32400: tcp 0 00:08:59.364926 IP 192.168.31.12.59727 > 192.168.10.4.32400: tcp 0 00:09:00.081124 IP 192.168.31.12.59711 > 192.168.10.4.32400: tcp 0 00:09:00.240943 IP 192.168.31.12.59717 > 192.168.10.4.32400: tcp 0 00:09:00.377797 IP 192.168.31.12.59726 > 192.168.10.4.32400: tcp 0 00:09:00.377813 IP 192.168.31.12.59727 > 192.168.10.4.32400: tcp 0 -
@Nath2125 well so either plex is not running? Or you have a firewall on that host? Or that server is sending its response somewhere else..
here fired up a connection from my phone on the 192.168.2 network to my plex 192.168.9.10 doing a sniff on the 192.168.9 interface on pfsense. You can see it sends on the trafic from 2.198 to 9.10:32400 and there is a response sent back that pfsense sees.
If you see pfsense send on the traffic - then you know your firewall rules allow the traffic.. But pfsense has no control if the device is going to answer.
-
@johnpoz I can see what you mean by it sending it back. I can assure you plex is running and no seperate firewall is running. I run simply pfsense with omada gear switch and AP's and everything works fine on the other vlans i have running. Here below is a capture from the IOT vlan i have (192.168.40.x) and it looks to be responding back. So im still quite confused whats causing this.
00:17:08.202668 IP 192.168.40.41.58820 > 192.168.10.4.32400: tcp 1304 00:17:08.203080 IP 192.168.10.4.32400 > 192.168.40.41.58820: tcp 398 00:17:08.210906 IP 192.168.40.41.58820 > 192.168.10.4.32400: tcp 0 00:17:08.210915 IP 192.168.40.41.58820 > 192.168.10.4.32400: tcp 1354 00:17:08.216339 IP 192.168.10.4.32400 > 192.168.40.41.58237: tcp 380 00:17:08.219285 IP 192.168.10.4.32400 > 192.168.40.41.58820: tcp 953 00:17:08.219936 IP 192.168.40.41.58237 > 192.168.10.4.32400: tcp 0 00:17:08.223481 IP 192.168.40.41.58820 > 192.168.10.4.32400: tcp 0 00:17:10.146197 IP 192.168.10.4.32400 > 192.168.40.41.58237: tcp 831 00:17:10.388997 IP 192.168.10.4.32400 > 192.168.40.41.58237: tcp 831 00:17:10.636842 IP 192.168.10.4.32400 > 192.168.40.41.58237: tcp 831 00:17:10.868752 IP 192.168.40.41.58237 > 192.168.10.4.32400: tcp 0 00:17:10.868765 IP 192.168.40.41.58237 > 192.168.10.4.32400: tcp 0 00:17:10.950154 IP 192.168.10.4.32400 > 192.168.40.41.58237: tcp 25 00:17:10.969193 IP 192.168.40.41.58237 > 192.168.10.4.32400: tcp 0 00:17:10.970262 IP 192.168.40.41.58237 > 192.168.10.4.32400: tcp 29 00:17:10.970374 IP 192.168.10.4.32400 > 192.168.40.41.58237: tcp 0 00:17:12.060909 IP 192.168.40.41.58829 > 192.168.10.4.32400: tcp 649 00:17:12.061218 IP 192.168.10.4.32400 > 192.168.40.41.58829: tcp 398 00:17:12.061995 IP 192.168.40.41.58820 > 192.168.10.4.32400: tcp 649 00:17:12.062218 IP 192.168.10.4.32400 > 192.168.40.41.58820: tcp 398 00:17:12.065629 IP 192.168.40.41.58820 > 192.168.10.4.32400: tcp 0 00:17:12.065639 IP 192.168.40.41.58829 > 192.168.10.4.32400: tcp 0 00:17:12.068114 IP 192.168.40.41.58829 > 192.168.10.4.32400: tcp 691 00:17:12.068124 IP 192.168.40.41.58820 > 192.168.10.4.32400: tcp 691 00:17:12.068606 IP 192.168.10.4.32400 > 192.168.40.41.58820: tcp 310 00:17:12.068621 IP 192.168.10.4.32400 > 192.168.40.41.58829: tcp 309 00:17:12.068828 IP 192.168.10.4.32400 > 192.168.40.41.58829: tcp 1448 00:17:12.068841 IP 192.168.10.4.32400 > 192.168.40.41.58829: tcp 1448 00:17:12.068850 IP 192.168.10.4.32400 > 192.168.40.41.58829: tcp 1448 00:17:12.068859 IP 192.168.10.4.32400 > 192.168.40.41.58829: tcp 1448 00:17:12.068869 IP 192.168.10.4.32400 > 192.168.40.41.58820: tcp 1448 00:17:12.068879 IP 192.168.10.4.32400 > 192.168.40.41.58820: tcp 1448 00:17:12.068888 IP 192.168.10.4.32400 > 192.168.40.41.58820: tcp 1448 00:17:12.068898 IP 192.168.10.4.32400 > 192.168.40.41.58820: tcp 1448 00:17:12.068907 IP 192.168.10.4.32400 > 192.168.40.41.58829: tcp 1448 00:17:12.068915 IP 192.168.10.4.32400 > 192.168.40.41.58829: tcp 1448 00:17:12.068925 IP 192.168.10.4.32400 > 192.168.40.41.58829: tcp 1448 00:17:12.068942 IP 192.168.10.4.32400 > 192.168.40.41.58829: tcp 1448 00:17:12.068953 IP 192.168.10.4.32400 > 192.168.40.41.58820: tcp 1448 00:17:12.068963 IP 192.168.10.4.32400 > 192.168.40.41.58820: tcp 1448 00:17:12.068972 IP 192.168.10.4.32400 > 192.168.40.41.58820: tcp 1448 00:17:12.069002 IP 192.168.10.4.32400 > 192.168.40.41.58820: tcp 1448 00:17:12.069037 IP 192.168.10.4.32400 > 192.168.40.41.58820: tcp 1448 00:17:12.069048 IP 192.168.10.4.32400 > 192.168.40.41.58820: tcp 1448 00:17:12.069057 IP 192.168.10.4.32400 > 192.168.40.41.58820: tcp 1448 00:17:12.069589 IP 192.168.10.4.32400 > 192.168.40.41.58820: tcp 1448 00:17:12.069604 IP 192.168.10.4.32400 > 192.168.40.41.58820: tcp 1448 00:17:12.069615 IP 192.168.10.4.32400 > 192.168.40.41.58820: tcp 1448 00:17:12.069624 IP 192.168.10.4.32400 > 192.168.40.41.58820: tcp 1448 00:17:12.069638 IP 192.168.10.4.32400 > 192.168.40.41.58820: tcp 1448 00:17:12.069649 IP 192.168.10.4.32400 > 192.168.40.41.58820: tcp 1448 00:17:12.069657 IP 192.168.10.4.32400 > 192.168.40.41.58820: tcp 1448 00:17:12.069667 IP 192.168.10.4.32400 > 192.168.40.41.58820: tcp 1448 00:17:12.069680 IP 192.168.10.4.32400 > 192.168.40.41.58820: tcp 1448 00:17:12.069691 IP 192.168.10.4.32400 > 192.168.40.41.58820: tcp 1448 00:17:12.069700 IP 192.168.10.4.32400 > 192.168.40.41.58820: tcp 1448 00:17:12.069760 IP 192.168.10.4.32400 > 192.168.40.41.58820: tcp 1448 00:17:12.069774 IP 192.168.10.4.32400 > 192.168.40.41.58820: tcp 1448 00:17:12.069948 IP 192.168.10.4.32400 > 192.168.40.41.58829: tcp 1448 00:17:12.069960 IP 192.168.10.4.32400 > 192.168.40.41.58829: tcp 1448 00:17:12.069969 IP 192.168.10.4.32400 > 192.168.40.41.58829: tcp 1448 00:17:12.069979 IP 192.168.10.4.32400 > 192.168.40.41.58829: tcp 1448 00:17:12.070695 IP 192.168.10.4.32400 > 192.168.40.41.58820: tcp 1448 00:17:12.070709 IP 192.168.10.4.32400 > 192.168.40.41.58820: tcp 1448 00:17:12.070722 IP 192.168.10.4.32400 > 192.168.40.41.58820: tcp 1448 00:17:12.070733 IP 192.168.10.4.32400 > 192.168.40.41.58820: tcp 1448 00:17:12.070746 IP 192.168.10.4.32400 > 192.168.40.41.58820: tcp 1448 00:17:12.070756 IP 192.168.10.4.32400 > 192.168.40.41.58820: tcp 1448 00:17:12.070768 IP 192.168.10.4.32400 > 192.168.40.41.58820: tcp 1448 00:17:12.070778 IP 192.168.10.4.32400 > 192.168.40.41.58820: tcp 1448 00:17:12.070790 IP 192.168.10.4.32400 > 192.168.40.41.58820: tcp 1448 00:17:12.070802 IP 192.168.10.4.32400 > 192.168.40.41.58820: tcp 1448 00:17:12.071570 IP 192.168.10.4.32400 > 192.168.40.41.58820: tcp 1448 00:17:12.071583 IP 192.168.10.4.32400 > 192.168.40.41.58820: tcp 1448 00:17:12.071596 IP 192.168.10.4.32400 > 192.168.40.41.58820: tcp 1448 00:17:12.071607 IP 192.168.10.4.32400 > 192.168.40.41.58820: tcp 1448 00:17:12.071619 IP 192.168.10.4.32400 > 192.168.40.41.58820: tcp 1448 00:17:12.071630 IP 192.168.10.4.32400 > 192.168.40.41.58820: tcp 1448 00:17:12.071642 IP 192.168.10.4.32400 > 192.168.40.41.58820: tcp 1448 00:17:12.071653 IP 192.168.10.4.32400 > 192.168.40.41.58820: tcp 1448 00:17:12.071663 IP 192.168.10.4.32400 > 192.168.40.41.58820: tcp 1448 00:17:12.071676 IP 192.168.10.4.32400 > 192.168.40.41.58820: tcp 1448 00:17:12.071690 IP 192.168.10.4.32400 > 192.168.40.41.58820: tcp 1448 00:17:12.071703 IP 192.168.10.4.32400 > 192.168.40.41.58820: tcp 1448 00:17:12.071712 IP 192.168.10.4.32400 > 192.168.40.41.58820: tcp 1448 00:17:12.072842 IP 192.168.10.4.32400 > 192.168.40.41.58820: tcp 1448 00:17:12.072855 IP 192.168.10.4.32400 > 192.168.40.41.58820: tcp 1448 00:17:12.072866 IP 192.168.10.4.32400 > 192.168.40.41.58820: tcp 1448 00:17:12.072875 IP 192.168.10.4.32400 > 192.168.40.41.58820: tcp 1448 00:17:12.072884 IP 192.168.10.4.32400 > 192.168.40.41.58820: tcp 1448 00:17:12.072894 IP 192.168.10.4.32400 > 192.168.40.41.58820: tcp 1448 00:17:12.072902 IP 192.168.10.4.32400 > 192.168.40.41.58820: tcp 1448 00:17:12.072912 IP 192.168.10.4.32400 > 192.168.40.41.58820: tcp 1448 00:17:12.072921 IP 192.168.10.4.32400 > 192.168.40.41.58820: tcp 1448 00:17:12.072929 IP 192.168.10.4.32400 > 192.168.40.41.58820: tcp 1448 00:17:12.072939 IP 192.168.10.4.32400 > 192.168.40.41.58820: tcp 1448 00:17:12.072948 IP 192.168.10.4.32400 > 192.168.40.41.58820: tcp 1448 00:17:12.072959 IP 192.168.10.4.32400 > 192.168.40.41.58820: tcp 1448 00:17:12.073949 IP 192.168.10.4.32400 > 192.168.40.41.58820: tcp 1448 -
@Nath2125 well your going to have to look elsewhere pfsense is clearly sending it on.. I would do a sanity check that pfsense has the correct mac address for your plex as a place to start..
[23.05-RELEASE][admin@sg4860.local.lan]/root: arp -a | grep 192.168.9.10 i9-win.local.lan (192.168.9.100) at b0:4f:13:0b:fd:16 on igb0 expires in 725 seconds [ethernet] nas.local.lan (192.168.9.10) at 00:11:32:7b:29:7d on igb0 expires in 294 seconds [ethernet] [23.05-RELEASE][admin@sg4860.local.lan]/root:Then if I look on my nas where plex is running
ovs_eth0 Link encap:Ethernet HWaddr 00:11:32:7B:29:7D inet addr:192.168.9.10 Bcast:192.168.9.255 Mask:255.255.255.0Might want to sniff on your plex box and make sure the traffic is getting there.. We know pfsense is sending it - but are we sure its getting there?
So for example here I am sniffing on my nas were my plex is running.
ash-4.4# tcpdump -i eth0 host 192.168.2.198 and port 32400 -n tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes 09:26:01.679073 IP 192.168.9.10.32400 > 192.168.2.198.55744: Flags [P.], seq 821517552:821517576, ack 2065543933, win 270, options [nop,nop,TS val 3062781672 ecr 433390218], length 24 09:26:01.785781 IP 192.168.2.198.55744 > 192.168.9.10.32400: Flags [.], ack 24, win 2047, options [nop,nop,TS val 433410322 ecr 3062781672], length 0 09:26:04.680116 IP 192.168.9.10.32400 > 192.168.2.198.55744: Flags [F.], seq 24, ack 1, win 270, options [nop,nop,TS val 3062784673 ecr 433410322], length 0 09:26:04.755769 IP 192.168.2.198.55744 > 192.168.9.10.32400: Flags [.], ack 25, win 2047, options [nop,nop,TS val 433413291 ecr 3062784673], length 0 09:26:08.248735 IP 192.168.9.10.32400 > 192.168.2.198.52410: Flags [P.], seq 3374823080:3374823130, ack 827981877, win 251, options [nop,nop,TS val 3062788242 ecr 3451710269], length 50 -
@johnpoz I've looked into mac addressing and looks to be fine and matching. I don't know why its not responding back like the other vlans are. I just unraid with Plex and having changed network settings since they always used to work. But I'm unsure now. IL keep thinking about other possibility of what I can do.
Reading through those packet captures looks to be just my unraid server not responding on that IP address, although responds fine to the other vlans. I really can't see what's making this different from the others.
-
@Nath2125 possible mask problem.. I didn't look to what the other networks are.. But one thing that comes to mind where answers to some source IPs work and others don't - other than a firewall blocking access from source, or only allowing specific source would be a mask problem.
Where source IP X comes in and the plex thinks oh that is on my local network, do you have a mask other than /24 ? If the plex box thinks the source IP trying to talk to it is local to its own network it would never send answer back to its gateway (pfsense).
If you sniff on your plex box and see it come in, look to see if it arps for that IP right after, if its arping for it - it thinks its on the same local network. Or just look at the mask on the interface on your plex box.
Are you running plex as a docker, or just native.. Docker likes to do stuff behind a nat, etc.
-
@johnpoz every IP range for every VLAN is /24. Plex is run on docker, which is an integration with the unraid os. So pretty much docker. Trying to figure out the best how to sniff my unraid box atm.
-
@Nath2125 can't you just ssh to your unraid or console in and install tcpdump?
edit: horrible work around, but as a quick fix until you figure out what is going on.. you could always source nat on pfsense so traffic from that network looks like its coming from that 192.168.10.x interface on pfsense - so now when you talk to plex from that network, plex would think its just some client on its own network.
Could it be something as stupid as routing.. what does your routing table look like on the unraid box, I would think just a default route to pfsense IP? Is that unraid box multihomed?
-
@johnpoz what do you mean by multihomed sorry and yes its using the top default in the image which goes to the 192.168.10.1 which is pfsense.
Getting tcp dump on my unraid box atm.
-
@Nath2125 well this looks like a problem to me..
That 192.168.16.0/20 would include your 192.168.31 your trying to talk from..
192.168.16.0 - 192.168.31.255
Would be that network range - so yeah you have a mask/routing issue.. Where that box thinks to get to that 192.168.31.x address he should just use that br-2b99 whatever interface that is vs sending it to your default gateway 10.1
-
@johnpoz said in Can access plex via my IOT vlan but not my inhouse vlan.:
Would be that network range - so yeah you have a mask/routing issue.. Where that box thinks to get to that 192.168.31.x address he should just use that br-2b99 whatever interface that is vs sending it to your default gateway 10.1
Ok so i changed the vlan to a 192.168.32.x subnet and it seems to now be picking it up. So you are correct. I did try and delete it and or find out how it was created in the route table on my unraid server but it for some reason wont delete and I dont know where it has come from so thats for further investigation. But for now its picking up fine when i moved it out of the 192.168.16.0/20 range.
-
@Nath2125 I believe that 192.168.*.0/20 is a by design network - I think it tries to use networks that are not in use and then creates a network.. So I would guess for whatever reason, it didn't detect this network and picked 192.168.20/20 which causes your problem.
Simple fix is what you did and just use a different network outside that /20
Or you could dig into docker and have it use a different range that won't conflict with the other networks you want to use.
