Agreed.  More details are needed to offer any troubleshooting help. By default, PFsense allows all outbound connections regardless of OS.  My guess is you have either a networking or DNS issue… or possibly both.  However, we won't know anything until more details are provided.

Thanks muppet. So it should be working better, good to get this confirmed. I suspect the firewall, but i will do some testing as you suggests. :)

Fine. put a gateway and a monitor IP address on LAN but don't set a gateway on the LAN interface itself. If it is showing down that means it is not responding to ping. You can only monitor addresses that reliably respond to ping.

All I can say is check again. It is pretty much impossible to have an inside MAC address on a WAN pcap without some sort of layer 2 connectivity between inside and outside.

There is a catch22 regarding the idea to contact Netgate. To contact them I need to open a ticket. Well, no.  As you have already discovered, the Netgate staff are quite active in these forums.  Your problem has already been addressed.

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