Getting Plex to play nice with firewall rules

hobbes1069 · Sun Apr 22, 2018 6:08 pm

I've been working for hours this morning to get Plex available from the internet. I've googled a ton, and what I figured out is that even with NAT working correctly some packets are being dropped that it needs to work.

I briefly had success when I added a rule for connection-nat-state=dstnat in front of my drop invalid packets rule but can't seem to recreate it.

I changed the standard "Accept established connection packets" rule from input->forward which I also think was part of the solution but everything got really slow (I assume forward is much more CPU intensive than input) and had to change it back.

I can see a packet in the NAT rule which I tell Plex to attempt RETRY and a few packets hit my connection-nat-state=dstnat rule but it doesn't succeed.

I'm going cross-eyed looking at all the forum messages and wiki entries with variations of a theme...

RouterOS 6.41

> /ip firewall filter print 
Flags: X - disabled, I - invalid, D - dynamic 
 0    ;;; Drop new connections from internet which are not dst-natted
      chain=forward action=drop connection-state=new connection-nat-state=!dstnat in-interface=ether24-wan log=no log-prefix="" 

 1    ;;; Accept packets for dst-nat connections
      chain=forward action=accept connection-state="" connection-nat-state=dstnat protocol=tcp in-interface=ether24-wan log=no log-prefix="" 

 2    ;;; Drop invalid connection packets
      chain=input action=drop connection-state=invalid log=no log-prefix="" 

 3    ;;; Drop external DHCP requests
      chain=input action=drop protocol=udp dst-port=68 log=no log-prefix="" 

 4    ;;; Detect and drop port scan attempts
      chain=input action=drop protocol=tcp psd=21,3s,3,1 log=no log-prefix="" 

 5    ;;; Detect DoS attack
      chain=input action=add-src-to-address-list connection-limit=10,32 protocol=tcp address-list=black_list address-list-timeout=23h59m log=no log-prefix="" 

 6    ;;; Supress DoS attacks
      chain=input action=tarpit connection-limit=3,32 protocol=tcp src-address-list=black_list log=no log-prefix="" 

 7    ;;; Block incoming DNS requests (udp)
      chain=input action=drop protocol=udp in-interface=ether24-wan dst-port=53 log=no log-prefix="" 

 8    ;;; Block incoming DNS requests (tcp)
      chain=input action=drop protocol=tcp in-interface=ether24-wan dst-port=53 log=no log-prefix="" 

 9    ;;; Accept established connection packets
      chain=input action=accept connection-state=established log=no log-prefix="" 

10    ;;; Accept related connection packets
      chain=forward action=accept connection-state=related log=no log-prefix="" 

11    ;;; Allow connections that originated from LAN
      chain=forward action=accept connection-state=related 

12    ;;; Whitelist addresses that should have full access
      chain=input action=accept src-address-list=admin-access log=no log-prefix="" 

13    ;;; Log everything else
      chain=input action=log log-prefix="DROP INPUT" 

14    ;;; Drop everything else
      chain=input action=drop

Thanks,
Richard

CZFan · Sun Apr 22, 2018 6:28 pm

My suggestion for you will be take a break and do something else, then go to Wiki and read again how Firewall in Mikrotik works and make sure you understand what different chains means, i.e. Input, Forward, etc

flynno · Sun Apr 22, 2018 6:57 pm

You need to open and forward the public port plex listens on, default port is 32400, it can be changed in the server settings on plex.

hobbes1069 · Sun Apr 22, 2018 7:51 pm

The NAT part is pretty straightforward. I have dstnat set on a non-standard port forwarding to my server on 32400.

Thanks,
Richard

hobbes1069 · Sun Apr 22, 2018 8:24 pm

I think the fault seems to be with Plex. When I click "retry" after making a chance it always fails, but if I reload Plex from the web browser it shows green and I have been able to stream a movie to my phone after turning off wifi.

That fixes that problem but I would still like to understand better how the firewall works.

Thanks,
Richard

2frogs · Sun Apr 22, 2018 8:33 pm

Order matters! In your export, your first firewall rule would drop all incoming packets destined to your Plex that is not new. You should have an Allow for Related & Established above the Drop rule.Here is a basic firewall filter:

/ip firewall filter
add action=accept chain=input comment=\
    "Accept Established and Related to Router" connection-state=\
    established,related
add action=accept chain=input comment=\
    "Accept from Safe IP Address List to Router" in-interface="ether1-(WAN)" \
    src-address-list=Safe
add action=drop chain=input comment="Drop Invalid to Router" \
    connection-state=invalid in-interface="ether1-(WAN)"
add action=accept chain=input comment="Accept Pings (icmp) to Router" \
    protocol=icmp
add action=drop chain=input comment="Drop All from Wan to Router" \
    in-interface="ether1-(WAN)" log-prefix="Input Drop"
add action=accept chain=forward comment=\
    "Accept Established and Related to Clients" connection-state=\
    established,related
add action=drop chain=forward comment="Drop Invalid to Clients" \
    connection-state=invalid in-interface="ether1-(WAN)"
add action=drop chain=forward comment="Drop All other to Clients" \
    connection-nat-state=!dstnat in-interface="ether1-(WAN)

hobbes1069 · Mon Apr 23, 2018 12:27 am

I was having problems with the router bogging down and stop accepting connections so I reverted to a known good configuration:

Flags: X - disabled, I - invalid, D - dynamic 
 0    ;;; Accept established connection packets
      chain=input action=accept connection-state=established log=no log-prefix="" 

 1    ;;; Accept related connection packets
      chain=input action=accept connection-state=related log=no log-prefix="" 

 2    ;;; Drop invalid connection packets
      chain=input action=drop connection-state=invalid log=no log-prefix="invalid:" 

 3    ;;; Whitelist addresses that should have full access
      chain=input action=accept src-address-list=admin-access log=no 

 4    ;;; Detect and drop port scan attempts
      chain=input action=drop protocol=tcp psd=21,3s,3,1 log=no log-prefix="" 

 5    ;;; Supress DoS attacks
      chain=input action=tarpit connection-limit=3,32 protocol=tcp src-address-list=black_list log=no log-prefix="" 

 6    ;;; Detect DoS attack
      chain=input action=add-src-to-address-list connection-limit=10,32 protocol=tcp address-list=black_list address-list-timeout=23h59m log=no 
      log-prefix="" 

 7    ;;; Block incoming DNS requests (udp)
      chain=input action=drop protocol=udp in-interface=ether24-wan dst-port=53 log=no log-prefix="" 

 8    ;;; Block incoming DNS requests (tcp)
      chain=input action=drop protocol=tcp in-interface=ether24-wan dst-port=53 log=no log-prefix="" 

 9    ;;; Drop DHCP requests from WAN
      chain=input action=drop protocol=udp in-interface=ether24-wan dst-port=68 log=no log-prefix="" 

10    ;;; Allow connections that originated from LAN
      chain=forward action=accept connection-state=related 

11    ;;; Log everything else
      chain=input action=log log-prefix="DROP INPUT" 
 
12    ;;; Drop everything else
      chain=input action=drop log=no log-prefix=""

I'm going to read through things again but what I think would help would be firewall best practices from a conceptual point of view.

2frogs · Mon Apr 23, 2018 1:36 am

Firewall rules are processed in order by chain and the fewer firewall rules packets have to go through, the lower the cpu usage. Usually you want the rules that will match the most packets first and this usually the Accept Rules. The Established & Related, which can be combined, should be at the top. Next would be Accept for lesser amount of traffic. Things like Accepting from address list or accepting to certain ports. Last would be Drop rules. These are more of a catch all, if the packets did not match any others, they are dropped. It does not matter if you put input or forware rules first, or if you put all Accepts (bothchain input and forward) first and the Drop rules last.

The firewall rules I posted above are basically what come on new devices with the exception of Accept for the “Safe” address list.

hobbes1069 · Mon Apr 23, 2018 1:57 am

I think part of what's confusing to people is when to use chain=input and when to use chain=forward because I see similar rules with both.

I know it's very complicated and the pictures make it worse not better

So when does NAT apply? So is it really going through the firewall twice? Once for the input chain for everything coming in to the router, then once it matches a NAT rule and the public IP substituted for the local one, does it go through the forward rules?

Thanks,
Richard

2frogs · Mon Apr 23, 2018 2:05 am

Input/Output is any traffic going to or coming from the router itself. Winbox, Webfig, VPN, DNS.... etc. The Forward chain is any traffic that gets forwarded from one interface to another. This includes not only traffic from your LAN to Internet, but also LAN to LAN.

https://wiki.mikrotik.com/wiki/Manual:Packet_Flow

This may help explain things better.

hobbes1069 · Mon Apr 23, 2018 2:15 am

That helps a little bit, but I'm basically running a home/SOHO network so I have one WAN interface (port 24) and everything else is internal or "switched" so for my particular setup it sounds like my assertion is correct.

Thanks,
Richard

CZFan · Mon Apr 23, 2018 3:20 am

The below might be some good reading

Tips and Tricks for Beginners and Experienced Users of RouterOS

ToBeFrank · Tue Apr 24, 2018 10:20 pm

I think part of what's confusing to people is when to use chain=input and when to use chain=forward because I see similar rules with both.

I know it's very complicated and the pictures make it worse not better

So when does NAT apply? So is it really going through the firewall twice? Once for the input chain for everything coming in to the router, then once it matches a NAT rule and the public IP substituted for the local one, does it go through the forward rules?

If we look at the packet flow diagram, https://wiki.mikrotik.com/wiki/Manual:Packet_Flow_v6, we can see that the packet comes into the "I" diagram. The I diagram starts with prerouting. Looking at prerouting, we can see that is where dst-nat is done. When we leave the I diagram, the next step is to go to the forward chain since the dst-nat changed it to go to an internal machine. Thus, the packet never hits the input chain and no firewall rules on the input chain are needed.

hobbes1069 · Wed Apr 25, 2018 12:19 am

Thanks, that helps. I had done some more (re)reading and was begging to come to that conclusion.

So basically, for my simple SOHO router situation, a packet is either destined for the router itself (ping, port scan attempts, etc) which "input" would apply to, or it's dst-nat'ed in which case the "forward" chain applies.

One thing to be careful of, is it appears that "input" would also apply to packets originating on the LAN side going to (but not through) the router, correct? Such as accessing it with Winbox/Webfix/ssh.

And in both cases, if I don't set an in or out interface, the rule applies to both directions (for both input and forward), correct?

Thanks,
Richard

CZFan · Wed Apr 25, 2018 2:30 am

You seem to be getting there, also remember that as you said for input chain, the forward chain can also originate from LAN, I.e. From LAN to Internet through router.

In and out interface can to a certain degree depict flow, but rather just see it as the interface is entering or exciting the router

anavds · Wed Apr 25, 2018 6:11 pm

The I diagram starts with prerouting. Looking at prerouting, we can see that is where dst-nat is done. When we leave the I diagram, the next step is to go to the forward chain since the dst-nat changed it to go to an internal machine. Thus, the packet never hits the input chain and no firewall rules on the input chain are needed.
[/quote]

But how then does IP NAT rule work if one wants to limit external IP address or addresses (by list if more than one) to access the LAN Server (port(s)??
Do we need a separate FW rule on the forward chain? In other threads it seems to be indicated that we can simply specific the source address(es) in the NAT rule
(so we are actually filtering in pre-routing??)

hobbes1069 · Wed Apr 25, 2018 9:41 pm

But how then does IP NAT rule work if one wants to limit external IP address or addresses (by list if more than one) to access the LAN Server (port(s)??
Do we need a separate FW rule on the forward chain? In other threads it seems to be indicated that we can simply specific the source address(es) in the NAT rule
(so we are actually filtering in pre-routing??)

Hmm... If you want to limit access to servers that are nat'd, I would think you could add a forward rule but there's a couple of different ways to do it depending on what other rules you have in place.

Thinking out loud here, but you could setup a rule for those hosts and instead of the normal (allow if from this address list), you could reverse it. Deny if NOT on this list, otherwise you may have another rule that would accept the traffic.

Thanks,
Richard

anavds · Wed Apr 25, 2018 11:30 pm

Hi hobbies, its a dilemma I don't understand as I come from another routing experience which separates out virtual servers and FW rules...........learning as I go.

ToBeFrank · Sat Apr 28, 2018 9:04 pm

But how then does IP NAT rule work if one wants to limit external IP address or addresses (by list if more than one) to access the LAN Server (port(s)??
Do we need a separate FW rule on the forward chain? In other threads it seems to be indicated that we can simply specific the source address(es) in the NAT rule
(so we are actually filtering in pre-routing??)

As you noted, you just set the src-address or src-address-list on the nat rule for servers you want to allow. If it matches, the packet gets dst-nat'ed to the internal server, and it goes through the forward chain. If it doesn't match, the packet doesn't get dst-nat'ed and goes to the input chain where presumably you have a default drop policy in place.

hobbes1069 · Sun Apr 29, 2018 3:30 pm

Ok, Plex is completely frustrating... I gave up last night and now that I'm sitting here drinking my morning coffee everything decided to work including my iPhone when I didn't change anything...

I think a lot of this has to do with the Plex side and perhaps waiting for tokens to update or something. It's really frustrating but things just don't happen instantly on their side apparently so it takes time to figure out when you change something to know whether it works to not.

Thanks,
Richard

Getting Plex to play nice with firewall rules

Getting Plex to play nice with firewall rules

Re: Getting Plex to play nice with firewall rules

Re: Getting Plex to play nice with firewall rules

Re: Getting Plex to play nice with firewall rules

Re: Getting Plex to play nice with firewall rules

Re: Getting Plex to play nice with firewall rules

Re: Getting Plex to play nice with firewall rules

Re: Getting Plex to play nice with firewall rules

Re: Getting Plex to play nice with firewall rules

Re: Getting Plex to play nice with firewall rules

Re: Getting Plex to play nice with firewall rules

Re: Getting Plex to play nice with firewall rules

Re: Getting Plex to play nice with firewall rules

Re: Getting Plex to play nice with firewall rules

Re: Getting Plex to play nice with firewall rules

Re: Getting Plex to play nice with firewall rules

Re: Getting Plex to play nice with firewall rules

Re: Getting Plex to play nice with firewall rules

Re: Getting Plex to play nice with firewall rules

Re: Getting Plex to play nice with firewall rules

Who is online