For point 1, then the question would be: Is 0.255.255.255 legitimate traffic that I should allow so they will disappear from those logs and potentially fix a traffic currently being blocked? If not I agree I should look to understand who is sending those. (so far my captures where empty with filter "0.255.255.255 | 127.0.0.1 | 0.0.0.0" so I need to let him run longer) FYI I have noted this on my Pfsense: netstat -n | grep 137 tcp4      0      0 192.168.1.10.39316    137.254.104.115.80    TIME_WAIT tcp4      0      0 192.168.1.10.17033    45.79.137.197.443      ESTABLISHED netstat -n | grep 138 tcp4      0      0 127.0.0.1.3129        10.0.0.2.61383        FIN_WAIT_2 1/ Maybe is then normal to have 127.0.0.1:3129 or 3128 ? Do you also have this on your Pfsense box? (FYI 192.168.1.10 is my WAN IP behind the DSL box) For point 2, do you think it worth trying these Squid options by adding my private IP ranges (as 10.20.30/24)? Bypass Proxy for Private Address Destination Bypass Proxy for These Source IPs It's interesting not critical issue but I like to understand what is happening and have clean logs too :) PS (EDIT): Attached the NAT rules created for Ipsec. I am wondering if this 127/8 couldn't be the reason. I will remove the 1st line as I am using OpenVPN and not IPsec tunnel [image: nat.jpg] [image: nat.jpg_thumb] [image: sockets.jpg] [image: sockets.jpg_thumb]

Think this would be great because there is no need to use the orig. Cisco Client on Windows and Linux either http://www.infradead.org/openconnect/ I allready build the latest packages and got it up and running but all inside traffice on the tun interfaces got blocked - the tick provided for the openconnet client does only work as long the client connection stays as newbie in BSD I am struggling with the pf firewall rules - read someting about anchor rules but … I really have no glue at all ... :-[ [sup]Ocserv's main features are security through privilege separation and sandboxing, accounting, and resilience due to a combined use of TCP and UDP. Authentication occurs in an isolated security module process, and each user is assigned an unprivileged worker process, and a networking (tun) device. That not only eases the control of the resources of each user or group of users, but also prevents data leak (e.g., heartbleed-style attacks), and privilege escalation due to any bug on the VPN handling (worker) process. A management interface allows for viewing and querying logged-in users. openwrt does the trick below - so I like to know how it could work with pfctl  and multiple tun devices? https://github.com/openwrt/packages/tree/master/net/ocserv ####################################### –--/etc/config/network------------------------------------------ config interface 'vpn'         option proto 'none'         option ifname 'vpns+' ----/etc/config/firewall----------------------------------------- config zone         option input 'ACCEPT'         option forward 'ACCEPT'         option output 'ACCEPT'         option name 'vpn'         option device 'vpns+'         option network 'vpn' config forwarding         option dest 'lan'         option src 'vpn' config forwarding         option dest 'vpn'         option src 'lan' config rule         option target 'ACCEPT'         option src 'wan'         option proto 'tcp'         option dest_port '443'         option name 'vpn' config rule         option target 'ACCEPT'         option src 'wan'         option proto 'udp'         option dest_port '443'         option name 'vpn' thank you

Would you rephrase Question 3 answer for me ? :), and yes /31 is a special case. For example… the typical 192.168.1.0/24    .. would you still call that a subnet even thought there only is those 254 host adresses, not divided or anything. The /24 means that 24 bits are used for the network and 8 for the hosts.  That's a contiguous block of 256 addresses, with "0" the network address and "255" for the broadcast address on that subnet.  A mask always provides a network that has some power of 2 bits, as above a /24 provides 8 bits/ a /31, 1, /16, 16 etc.

@joelones: Wifi (Mac OS X) IP: 192.168.3.110 Printer IP: 192.168.3.80 pfSense has nothing to do with traffic inside a single LAN. https://doc.pfsense.org/index.php/Firewall_Rule_Troubleshooting#Unfilterable_Traffic

unfortunately refreshing the page had no effect.

@tomli: hi all,… i don't want to input 970 ip address in this table. Is it any good suggestion to me for reference? If, and only if these 30 PC's that should be allowed to use FTP (FTP clients are running on those PC's) are using static DHCP leases, or have static IP's, this means known, fixed,  IP's, then your close to a simple solution. You should use a firewall  ! Good news, pfSense IS a firewall  ;) So, instead of listing the 970 PC's that should not be allowed to use FTP, you should throw these "30 PC's" (their IP's) in an alias. And then you let the system do the work : Create a firewall pass rule with some nifty port selection (like "Destination something like port 21, to 'select' FTP traffic) and use the alias you created as a source address. A second block rule right after that, same destination port, but with a source address like "Any-on-your-LAN" (the one with 1000 PC's). The 30 PC's will hit the first rule, and this results as an accept, the can pass. All others won't be able to use FTP (on the selected destination port). Note : I couldn't test this myself with the package FTP_proxy, I don't know where that is good for. But see image for the firewall rules - I tested them and added the PC's that should have an FTP access to the list named "FTP_permitted_list". Added PC's have access, the other : no. Worked for me. [image: ftppass.PNG] [image: ftppass.PNG_thumb]

Ctrl-C  works, Thanks! I've tried before: Esc, Alt-Esc, Q, Alt-Q, Alt-Tab, Ctrl-Enter - non of those works

I have quad-port nic set up with a WAN, LAN1, LAN2 and W_LAN. The entire network is setup to go through a VPN (ExpressVPN) except LAN1. The PC I am trying to use to connect to the modem is on LAN1. For LAN1 I have my LAN1 net any any rule set to use the WAN_PPPOE gateway so that it does not go through the VPN. I do not understand why the following allowed me to access the modem from LAN1 but what I ended up doing was creating a new rule with my LAN1 pc IP address as the source and Modem_Access net as the destination. On this new rule I left the gateway as default. This causes the connection to go through the VPN but it works. So, though I do not understand why it wouldn't work using the WAN_PPPOE gateway it does work when not setting a gateway for the above rule. If anyone understands why creating a rule with no gateway chosen works please let me know so that I have a better understanding.

Things that tripped me with Unifi APs before were: Make sure your clients firewall is off…I couldn't access my AP when using a Mac unless I turned off my Mac firewall(I have read similar issues with a PC firewall) Unifi doesn't work well on VLANs i.e. controller and AP need to be on a non VLAN and on the same L2(same IP interface) Also explore their CloudKey pretty slick and despite the name doesn't require you to access it via the "Cloud".... Good luck....

And the culprit is….. the NIC :( I've disabled it and used a - gasp - USB3 one I had knocking around. So far, so good. Get a shade over 200Mb/s throughput which is more than ample for my needs (IoT wifi)

not unless you'd install a browser & X11 on pfsense itself …. so no

I wanted to follow up on this issue.  I noticed some of my other 2.4Ghz devices were offline after a few days and restarted the router I was using as a wireless AP.  That seems to be the issue.  It has dropped service again after just a day but only the 2.4Ghz band.  It looks like it may be on the way out.

If you have a network 192.168.x/24 lets call it - and your on 192.168.x.100 and plex is on 192.168.x.101 - no pfsense would never see that traffic.  The only thing plex might have to do is resolve plex.whatever.tld your using to 192.168.x.101 Yes if your .100 box is talking to your .101 plex server the dest would be 32400.. That is IT.. and the source would be whatever random high port your client is using for that session.. Something above 1024 and below 65515.. The only time pfsense would be involved in the traffic is if it was routing it.. so clients on 192.168.x/24 while your plex is on 192.168.y/24

It looks like your currently just running a specific vlan for each AP based on what switch you plugged it into.  Any dumb AP could do that, even some wifi router being used an AP.  The brief 2 seconds I looked at the specs of that AP model is it supports vlans.  So you should be able to run I would think at least 4 different vlans on the AP based upon SSID. Depending on the AP features - you could also do dynamic vlans based upon auth or mac, etc. But sure each of your AP should be able to do all 4 of those vlans. SSIDA - vlan5 SSIDB - vlan10 SSIDC - vlan15 SSIDD - vlan20 you should be able to do that on each AP..  Not sure how many SSID those AP support.  The unifi stuff can do 8 per band.. So if you wanted you could do 8 on 2.4 and 8 on 5ghz.. for a total of 16..  You will have to read the specs on your specific AP on how many SSID you can use on the same AP.

I think you are correct, but I chose a random name for my example as if it were a plain ethernet port. Thanks for your input! –jason

192.168.3.1.53: UDP, length 39 So that is your client at 192.168.3.3 asking for dns.. Pfsense does not answer - so no how would the client go to any website? if can not look it up.  So looks you do not have unbound running or forwarder working at all. Or you don't have any firewall rules on this interface to allow access?  The lan interface would have a default any any rule on it.  Some new interface you created would not have any rules you would have to put either an any any or the rules you would like to allow. Pfsense will create behind the scene firewall rules to allow for dhcp to work.. But I only see this 23:37:25.457114 IP 0.0.0.0.68 > 255.255.255.255.67: UDP, length 300 23:37:25.457435 IP 192.168.3.1.67 > 192.168.3.3.68: UDP, length 300 there should be more.. from what have to assume is the discover there to FF:67, the answer would be a offer - but you should then see a request and ack.. But clearly from this whatever .3 is sending traffic to .1 (pfsense)..  I take it .3 is a wifi client?  So where are the rules on this interface on pfsense?

After to clear the cache, the problem was solved. Thanks.