Bringing out the big guns - PLEX, VPN and portforwarding

  • Hello,

    I'm completely new to this forum and relatively new to pfSense as well. For the past two months I have spent a lot of hours in the GUI trying to find the optimal solution for me and I feel that I have come very close. So first of all, thanks for a terrific product! Many a router had been bought and sent back before finding pfSense!

    So today I run pfSense virtually on a Hyper-V Host together with a Linux and a few Windows  10 machines. Among them I have my dedicated PLEX machine. I have run a VPN client from within pfSense with great success and just recently I discovered the gateway group functionality, enabling load balancing and fail over. Really great stuff! To the point at hand! Regardless of what  I do, I am not able to successfully port forward 32400 (for connecting to PLEX remotely) on the VPN interface! The service has public IP (which is required to work) and on every site where you  can check your IP it will tell me that the PLEX machine is on the VPN provider's public IP. Yet I cannot port forward.. To get this to work I turned to Sweclockers (good tech site in my native language Swedish) as well as the  VPN provider themselves. Sweclockers tips did not work and neither did the VPN provider. The latter have yet to compile a validated guide on how to get this to work in the latest version of pfSense.

    After having tried all possible combinations of rules I could think of I have removed all the rules under NAT and Rules to start clean. Any help from anyone would be appreciated.

  • I am not sure your setup is clear enough for us to help you, especially the vpn part.

    Seting up a reverse nat is done on pfsense using the nat menu/port forward section.

  • Hey friend I appreciate your reply!

    (Firewall NAT) (please don't mind the rule called PLEX WAN for

    (Firewall Rules Interface OPT1)

    (Firewall Rules Interface LAN)

    The PLEX server's LAN address is and the VPN Interface is OPT1. Does this help? The VPN is working incredibly well in terms of connectivity and stability and the PLEX machine does tell me that it is getting the public IP, my issue is just to be able to open port 32400 and allow traffic to go in and out through that port on OPT1..

  • Your VPN provider must support port mapping in their servers in order you can grant access to Plex from their IP.
    I have the same setup and my provider AirVPN support this feature and work flawlessly.
    In Plex settings you have to change port 32400 to the port mapped in VPN servers (if 32400 is not available).
    Basically here the steps:
    1 - VPN provider servers: map VPN port (normally random assigned) to 32400
    2 - Plex settings: change port number to that assigned in VPN Servers
    3 - pfSense: port forward VPN net:32400 to local Plex IP:32400

    In plex forums you can find the same solution I posted here and there.

  • Since my VPN provider both promises that it they support Plex and that they have tried to set up rules in my firewall (without success) I am fairly sure this is a confihuration issue on my end. Do you think you could post pictutes of all the rules in your set-up that are intended to make your plex server available thru vpn?

  • Here pfSense rules.
    The key is now to map 32400 on VPN servers, for example port 45000.
    In plex settings then change default to 45000… and you are done!
    Remember Plex uses TCP on 32400, UDP is not necessary.
    In your associated firewall rule use default gateway not VPN WAN.

  • Thanks!

    I copied your rules but it did not work. PLEX shows the VPN provider's IP but clearly states that the machine is not available from the outside (ports 32400).
    I've screenshotted both my rules, merged them into one picture and attached it here.

    EDIT: Just to clarify the VPN service I use offers a public IP without any firewall at all so there's no need to open anything up there.

    ![2017-01-29 14-58-35.jpg](/public/imported_attachments/1/2017-01-29 14-58-35.jpg)
    ![2017-01-29 14-58-35.jpg_thumb](/public/imported_attachments/1/2017-01-29 14-58-35.jpg_thumb)

  • It is not a matter of firewall in VPN servers sides….you need to forward exactly port 32400, your provider must set this (other providers offer this service).

    Because Plex Media Server registers itself as VPN_Public_IP:portX (that port MUST be set in plex settings) but since that port is not solely assigned to you and changes....from Plex Clouds is lost communication back to you....this trigger the condition "server not reacheable".
    Again you really need your provider assign to you and only to you a port to be mapped to 32400, in order to establish the correct routing from Plex Clouds:

    Plex Clouds->VPN_Public_IP:portX->VPN_Tunnel_IP:32400->PlexMediaServer:32400
    PortX is that assigned in VPN servers and set in Plex Media Server settings.

    Which is your VPN provider...I will check their services.

  • It's a Swedish provider at

    Just seems weird that they didn't tell me this when we were trying to solve the issue..

  • They don't offer port forwarding but this:….
    I don't like the fixed public IP assignment... frankly speaking you should change provider.
    My provider offers several ips but I have assigned always the same ports, better solution for security.

  • And I have the public address service configured on my plex machine, which brings me here :)

  • Try to set outbound rule with static port for your Plex Media Server, using your vpn gareway. this solution will open a comunication with plex clouds and they will be able to reach you without any port forarding since you have a state alive.

  • As much as I think that sounds like a great idea I am really not sure as to what to put where here. Could you please help me understand that?

    I yellowmarked the areas where I am not sure. I am guessing the interface should be OPT1 (my VPN client running with the public id). Also the address under translation should be QA (which is my test machine for this). But when it comes to source destination and pool options I'm not sure.

    ![2017-01-29 18-13-43.jpg](/public/imported_attachments/1/2017-01-29 18-13-43.jpg)
    ![2017-01-29 18-13-43.jpg_thumb](/public/imported_attachments/1/2017-01-29 18-13-43.jpg_thumb)

  • Interface: the one assigned to VPN
    Source: ip of media plex server

    Address "network" and thick "static port"

    As a first step use the defaults and see the behavior.

  • Something like this? I can't select network under Translation Address. At the moment it is not working.

    Also I should probably mention that you can't select a single client as source. Only an entire network. So if I input (which is my PLEX client's ip) I get

  • In source don't put any port…if Plex ask to go with 32400 the static port preserve natting the port.
    In the transaltion section, in address you should be able to select "network address".... do you have other options?

  • I can only choose from my host aliases and "other subnet".

  • Use exactly "interface address"

  • Still the same results.. Reposting my rules in the attached picture. Does it matter that I have rules to forward traffic coming in on 32400 via the WAN activated the same time as I have the corresponding rule but for traffic coming in from OPT1 (VPN)?

  • Can you post the gareway screenshot and interface assignement…
    Opt1 is the VPN gateway? Or the interface assigned to plex subnet?

  • Here you go!

    Opt1 is the vpn gateway yes.

  • I don't have any other idea…sorry.

  • No problem you really did make an effort so thank you very much friend!

  • @Wolf666:

    I don't have any other idea…sorry.

    Hey Wolf I just wanted to tell you (and anyone else with this weird problem) that I solved it. After spending an hour or so googling yet another time I found a thread where a guy had issues not very different from mine. He received the advise to remove all rules under the OpenVPN tab under rules. After I did that it worked. The rule I had there was automatically created from the OpenVPN server wizard that I had run a while back. Really weird but it did the trick!

  • Great! Thank you for feedback.

Log in to reply