That sort of issue would be better fixed with a local host override or just turning off rebind protection for the plex.direct domain.  If your having issues you prob have issue with rebind protection.  Because the url you could use to access would be something like https://192-168-9-8.11b1ea3fe<snipped>92c7b8.plex.direct:32400 Where that would be some random token.  You can find that in your xml.. go to https://plex.tv/pms/resources.xml?includeHttps=1 You can set plex.direct to not use rebind protection so when you query for that name you get back your private IP.  Out of the box pfsense would block getting back rfc1918 for a query and you get back nothing.  So you see when I do a query for that fqdn get back no answers. I then add in the unbound advanced custom box to turn off rebind protection for plex.direct and then I get an answer back of my local IP. https://doc.pfsense.org/index.php/DNS_Rebinding_Protections private-domain: "plex.direct" See the rebinding section on the plex support site for https as well https://support.plex.tv/hc/en-us/articles/206225077-How-to-Use-Secure-Server-Connections [image: rebind.jpg] [image: rebind.jpg_thumb]</snipped>

@SoulChild: Sure, it's possible You indeed need a vlan-capable switch. Prices of this range from several thousand bucks to 20 something. I have personal experience at home with these: http://www.ebuyer.com/641041-tp-link-tl-sg108e-8-port-gigabit-easy-smart-network-switch-tl-sg108e?mkwid=s1HfC5rWZ_dc&pcrid=51482425979&pkw=&pmt=&gclid=Cj0KEQjwmri_BRCZpaHkuIH75_IBEiQAIG0rIT5tBk3xx6BSTrX8HzKbXoMKydTRzeB4DU1q0HfRVBcaAmla8P8HAQ Sure, the gui is confusing and pedantic, but once you got it working, it works fine. You can't expect everything for 20 bucks :) For a bit more, you can have 24 ports, even. For simple(!) vlan setups like yours, this will work fine. But be aware that setting this up can be painfull unless you're really sure what you're doing. But then again: you only learn by trying :) Thanks! im going to do a little research on those switches, i was thinking on the "Tl-sg2008" its a little better i think and i found it at good price.

fredie380 may be lacking actual content, but I'm also trying to track down a problem with my machine needed reboots at least once a week, sometimes hanging. Symptom 1: I lose the lan connections randomly.  It seemed to be every 7 days.  We tracked this down to a network surveying software that was scheduled to run every 7 days.  This is a symptom though, not a cure. Symptom 2: Firewall would spike to 100% and require hard reboot.  All interfaces were offline at this time.  Reading an forum post on 2.3.x and a bug track on SMT, IPSEC, and UDP, I disabled SMP on the firewall, running it down to single thread to see if it would resolve. So far firewall is stable, but this isn't a cure it's a band aid. So fredie380, if you're seeing similar symptoms you may want to try the above and report back. If it's not the same, please give more information.

Well, interface might be misleading of even wrong. Difference between RFC 2307 and 2307bis is mainly how members are described within group. Basically RFC 2307 bis will store members as "uniquemember" (containing member's DN) while RFC 2307 will look at memberuid storing… uid This is quite different and has real impact on the way one look at group memebership. This said, I don't understand your ldap filter as you search, within same filter, for "uid=something" (this searches for user's LDAP entry, if I'm not wrong) and cn=somethingelse + objectclass = posixgroup, which targets group. This works only with your groups contain uid attribute describing members, which would be odd. I'm not discussing here other differences between 2307 and 2307bis about structural vs. auxiliary  ;)

Yep, something stupid. A reboot of the machine fixed it.

@johnpoz: " I am coming from another subnet further down the 192.168.0.0/24, the pfsense would need a gateway on the LAN interface and I am not very clear on pfSense different gateways especially when one is pointing at the upstream through the WAN and the other one is pointing as the downstream infra through the LAN interface." You would not connect a downstream router via the "lan" you run into asymmetrical routing that way.  If you need to connect downstream router to pfsense then that would be via a transit network.  You don't put hosts on a transit.  If you do everyone of those hosts would need to have host routing to tell them which gateway to use to get to which network, etc.  Its a logistic nightmare which is why you use transit networks to connect routers. Isolation of what interface you use to management pfsense very simple.  Create a new network and use that network as your management be it you use a whole physical interface for this or a vlan is up to you.  Generally speaking if you want an isolated managment network use of the "lan" would be good since it has the antilock rules on it.  Then all your other networks connected to pfsense would be on opt interfaces or vlans running on lan or opt interfaces.  But again when connecting another router be it downstream or even stream of pfsense it would and should be via a transit network. Thanks ! I am not entirely sure I got your point except that it's likely to be messy which I know well ;-) I will keep it simple for now and just add a route to my few networks in my out-of-band management network.

You're right, but it just feels a bit weird implementing a virtual firewall on your openstack to access your virtual IP's But god knows, openstack is the wild west so far as best practices are concerned, so don't let me tell you otherwise :D

@zedutchman: Looks like it was pfblocker. Not sure why. Didn't look at the logs before I did a fresh install. I've setup my essentials (OpenVPN, Squid) for now till I have a stable setup and I know I have no issues from before. That was my fix. I was running with top 20 ipv4 blocked. Followed a guide online and it did not work out. Probably didn't help that as a newb I ran Snort with PFblocker and had everything getting blocked. Hi, I had same issue 2 days ago. I am running squid-snort and pfblocker with dnsbl enabled. I think its your firewall. You need to allow port TCP/UDP on 8081 and 8443, Also, i found this in the forum. Please make sure that you have dns-resolver turned on and inside there dns-forwarder is unchecked. Also, to check if things are working go to 10.10.10.1 and you got to see 1x1 gif square of white color. Hope it helps Firewall > NAT > Port Forward> Edit Interface LAN Protocal TCP/UDP Click Invert match select LAN Address Destination port range From Port DNS and to Port DNS Redirect target IP 127.0.0.1 Redirect target port DNS NAT reflection Use system default Filter rule association Create new associated filter rule Create rule that allows TCP/UDP from LAN net to  LAN address on port 53 Create rule that allows TCP/UDP from This Firewall to Any on port 53

You might have a crashreport available in the GUI. Paste it on pastebin & link it here.

This was setup many years ago and i never questioned why…. guess i have some detective work to do... im sure I just need to forward some ports and it'll work fine...

and how is  the 2.3.2 release ?? I have the same problem =\

Yes, there are some additional steps which are required to 'normalize' the operator branded modem. I've added a brief description to my earlier post. Those changes are modem specific and not directly related to pfSense. I don't think it's really necessary to buy a new modem, but I would prefer to use a stick rather than router like 5372.

You are correct, it relates well to Op question.  My created-topic with a similar problem however remains empty :)

It will be in 2.3.2_1.

How can we allow ftp protocol for my users. Or do us all (ISP, hosters, your clients) a favor and switch to SFTP for file transfer. And no, I'm not talking about FTP/S (FTP with TLS/SSL encryption), but SFTP (subset of SSH service). It is SO much less hassle. FTP as a protocol is just a giant PITA. If you have to, check you don't have a far too big passive ftp port range so you don't have to open up some thousands and thousands of ports.

Normally this should be completely transparant and no changes required with the default pfsense rules. The PFsense box is not aware of your VPN, it' just TCP(or UDP) traffic that is forwarded. Nothing more.

@Harvy66: Lagging is a result of bufferbloat. While trying to figure out how figure out what ports common game servers use, enabled Codel Active Queue on your firewall queue. I thank you for your reply, but, honestly, what will 'Codel Active Queue' do with my problem? as for an example, I have an online Game "XYZ", but they don't provide game port(s) as they are paranoid that it will attract/invite DDOS :(. I have pfSense traffic rules configured, lets say people are playing DOTA 2, League of Legends or Heroes of Newerth while doing streaming/browsing on my LAN and the ping rates are 'acceptable' because of the traffic rules I have created and these Games provide either directly or indirectly with the correct port(s) to configure. If Game XYZ port(s) are not determined, it will ultimately goes to the default queue (unless otherwise they use same/similar port(s) of other game servers), of which I have configured with less bandwidth. Once again, I am really sorry as I don't get the whole picture enabling "Codel Active Queue" for this.