thanks, never worked with bin logs before. But found the problem, pfsense was only running on 443 and somehow the internal CA was missing nginx couldnt load. Changed via viconfig to enable port 80 http, recreated a cert and done. solved -

The openvpn client (at least with PIA) typically does not show the real gateway automatically. If your client / interface got assigned a (e.g.) 10.10.30.5, it may show 10.10.30.6 as the "gateway", which will typically not be pingable. You can manually change the monitor IP to something like 10.10.30.1 or something else on the internet that you know will respond to pings. Global DNS providers (google, openDNS are an example). HTH.

I'm a bit new to this, so let me give this a shot… Please let me know if there are more specific items I need to list. I'm using 2.4.2-RELEASE-p1, DNS resolver with forwarding enabled to Google DNS ipv4 and ipv6 with interfaces set to its default of ALL. Physical setup is a Qotom fanless box with i3 4025u + 4GB ram and quad intel i210 nics as follows: Cable modem > pfSense WAN >|> pfSense LAN+SPAN > Netgear GS108T managed switch (LAN) + Monitoring PC (SPAN) which is separate from my main PC. Packages installed are Snort, pfBlockerNg, ntopng, nut, openvpn-client-export. I tried powering off my main PC to see what how the traffic changes, and 127.0.0.1 now correctly resolves to the hostname of the device that performed the resolution; the target MAC address is still the same however. Originally 127.0.0.1 was resolving to gearssdk.opswat.com regardless of the device performing the resolution.

Your outbound NAT mode has to be set at hybrid or manual, if it's on auto your rules will always be disabled.

Yes, it's done with CARP and XML-RPC Sync etc. High-availability is documented.

@NogBadTheBad: Why do you keep posting the same question in multiple sections. https://forum.pfsense.org/index.php?topic=143715.0 https://psiphon.ca/en/faq.html#port-restrictions It uses the following ports by the look of things, they've chosen these ports for a reason the red ones specifically will cause you issues if you block them. 53, 80, 443, 465, 587, 993, 995, 8000, 8001, 8080 I am sorry For that

I cant imagine why I would be the victim Ddos, I have no web services running just a couple of PCs and other devices. I'll look into low latency thing you mentioned, thank you for your help.

How many local users do you have on there? That sounds like https://redmine.pfsense.org/issues/7469 – depending on the speed of the hardware that can show up with 10-20+ local users.

Also, on 2.4.x you do not need to use admin for this. Create a new user for synchronizing and give it the "System - HA node sync" privilege. Once that user synchronizes to both nodes you can then set that user/pass as the sync user on the primary under System > High Avail Sync.

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.