No, that will not accept the multicast ARP replies if you need that. That requires the system tunable to be added. If you just need to clean the logs then you can try that check box. I'm not sure I've ever done so for multicast ARP, we hardly ever see that (because it's invalid ). Steve

@stephenw10 Nice! Thanks man, thats exactly solved my problem!

A lot of that could be explained by a bad subnet mask somewhere. If the VMWare host are statically assigned and others use DHCP that could be the difference. Ultimately I would start a ping and run packet captures to see where it's going. Steve

Some nostalgia from 11 years ago. Same problem then, just scaled.

@ljr said in Connection trouble after switching ISP: I eventually got thru to an engineer, who said they ran out of 10.0.0.0/8 space. WTF. The same thing happened with Comcast, IIRC. They couldn't manage their network, without segmenting it, even with all the RFC 1918 addresses available. Their solution was to move to IPv6. Rogers provides IPv6, but they still have to support IPv4. I hope you're running IPv6, as it will help you avoid that sort of problem.

@stephenw10 Thanks a lot for your awnser !

These other systems are VMs in VBox connected to the internet network only? I would expect to setup the pfSense VM with two NICs; the WAN NIC should be bridged to the real NIC so it gets an IP in the local subnet. The LAN NIC should be internal only so other VMs can connect out through it. Steve

So solved it myself. As I had "NAT" as WAN adapter I changed it to "bridged adapter" and it's working fine.

@krishan said in How to pass a private ip 172.X.X.X in WAN.: LAN is on 24 and WAN is on 32 /32 is a subset of /24... There are exactly 256 /32s in a /24 block. Why would your WAN IP be in the same range as your LAN subnet? That is an invalid configuration. Is that assigned to you by your ISP's DHCP server (aka carrier grade NAT) or is it just an IP you pulled out of your arse? If it's the former, change your LAN range. If it's the latter, read a few networking books...

Yes, it will change the subnet for all devices connected to the LAN. You need to change it though, you cannot use WAN2 with the subnets overlapping like that. I suggest changing it from the console if you can as that gives you the option if setting the new dhcp range at the same time and you won't get locked out. Steve

@pwrobot said in pfsense blocking personal email web sights without any rules configured: ERR_SSL_BAD_RECORD_MAC_ALERT Google for that error points to 3rd party antivirus, etc.. None of which has anything to do with pfsense!!

@ton11797 You can't change the MAC for VLANs. The MAC address is determined by the hardware, though it is possible to change it, when configuring the port. VLANs have the same MAC as the native LAN. If you really need to have 2 connections via PPPoE, I suppose you could add another NIC and use a managed switch to create the VLAN. There are cheap managed switches that will do that, though you should stay away from TP-Link, as some models don't handle VLANs properly.

thanks @stephenw10 thats work exactly as it might be.

i found this for you @dennypage said in New Avahi package: Yes, this is intentional. There are no local mDNS browse clients for pfSense, so there isn't much use for dbus support on the firewall itself. Further dbus was the cause of a couple of significant issues, one being the minimum 5 second startup delay, and the other being a sporadic failure of Avahi to start at boot for many users. If you want to see what is in the network, I would recommend doing this from a general workstation or laptop in the network. This will also give you a better view into the overall functionality of reflection. There are several tools that support this. If you are a Mac user, then there is a free application called "Discovery" that is pretty nice. For a Unix based system, you can use avahi-discover (GUI) or avahi-browse (command line). I haven't used Windows in many years, but I'm sure there are some decent tools there as well.

@claferriere One thing I learned many years ago, suspect cables and connectors first, as they often fail.

There is a list posted in the IDS/IPS forum here that was created by some of the forum members. It is a pretty decent one in terms of suppressing most of the popular false positives. Might be that the list you posted actually originated from here, I don't recall all the individual rules on the posted list. The best way to suppress false positives in your setup is to put Snort in alert mode only (turn off Block Offenders) and let it run for at least a week, and maybe more, while analyzing your typical network traffic. Make it a point to review the alerts at least daily and more than once a day if possible. Remember that any generated alert is a block, so look at each alert and then use Google to find out what the alert really means if you are not sure. Use that info to construct your false positive list. Add rules to a Suppress List by clicking the plus (+) icon next to the rule's GID:SID value. If you want to disable the rule, click the red X. That is a more secure approach to creating a suppression/disabled list than copying somebody elses list off the Internet -- and that includes the list posted here ... . I'm just not a big advocate of copy-and-paste when it comes to IDS administration. Resist the urge to install Snort and immediately turn on blocking. That is almost guaranteed to generate blocks from false positives and create a headache for the security admin. Let it run for quite some time in IDS mode (intrustion detection) only without blocking so that you have an opportunity to see what alerts happen with your network traffic. From that list you can determine what you will consider OK to let pass and what you may want to block in the future. With that said, I will say that most admins turn off several of the more troublesome HTTP_INSPECT rules. You can find those in the alerts by both their GID (Generator ID) code and the fact the message will ususally start with the string (H_xxxxx) where the xxxxx is the particular HTTP_INSPECT section. The HTTP_INSPECT preprocessor rules will have either GID 119 or GID 120, depending on whether the rules are designed for the server (120) end or client (119) end of the conversation. But the HTTP_INSPECT preprocessor rules are not all bad. Here is something I found while doing some research recently: https://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/detecting-brazilian-banking-trojans-with-snort-http_inspect/.

check the openvpn manual under tunnel options : –remote host [port] [proto] there is no fixing that with PIA. this is why i dropped them and never looked back. but if you follow the command i posted it will reconnect you if you set it up properly

thanks alot.

Ok so that happens because your WAN 'ipaddr' is set to dhcp I assume? Is that an OpenVPN client or server? You may be able to workaround it by running that on a different interface, one that is static. Then port forwarding to it in the server case. Steve

@jimp said in New ping-based attack: This isn't relevant to pfSense in any way, as far as I can tell. It only affects FreeBSD 12, so it would not affect the current release, 2.4.4-p3, which is based on FreeBSD 11.2 It only affects the RACK TCP stack which is not used on pfSense 2.5.0 snapshots. This is an optional, non-default, TCP stack. The module for it is not built nor included in images. To use that stack, someone has to go out of their way to load the tcp_rack kernel module (which isn't on pfSense) and set net.inet.tcp.functions_default=rack (which on pfSense 2.5.0 is set to the default, freebsd) Good to know. Thanks.