fixed .

CP doesn't work with pf. Aliasses in the webGUI are designed to pf
CP is based on ipfw to have the L2 features it has. no gui is currently available to create ipfw aliasses.

no problem , its got to be hard keeping everything you do as straight as you do, thanks for all the help

They work. Firewall rules specifying a gateway override the routing table.
https://doc.pfsense.org/index.php/Bypassing_Policy_Routing

UDP is not blocked. The UDP Hole Punching Mechanism isnt working in my case.
I switched over to anydesk (instead of Teamviewer) and everything is working.

Maybe this is a TeamViewer problem.

Description field restored.

Thanks for spotting this.

Hmm that is sad indeed.  Don't know what the differences in v5 vs v9 are or what if anything is lost by falling back to the older version. What are you guys using for visualizing bandwidth/flows – ntopng? built in RRD? Am I cuckoo for trying to use netflow? I saw this post on pushing data to an ELK server and the results are very impressive. That's basically what I wanted to emulate.

Applied the fix and it is working, thanks!.

I was looking at the RRD Graphs and noticed that i have some Queue graphs that were added but aren't being populated.

status_rrd_graph_img.png
status_rrd_graph_img.png_thumb

@Steve_B:

Its not really the widget that looks like 2.2.x, its the graphs themselves. Work is underway to replace that whole system with browser based graphing. Once that has been released you will see a dramatic improvement,

Awesome. That's the answer I was looking for. Thank you Steve!

It seems difficult to achieve a full test of the APU2 new board using pfSense 2.3 Beta.

I decide to do a fresh clean install on the SSD with pfSense 2.2.6 and it's working for most of the feature :

Squid with transparent mode is working Captive Portal (without Squid is working) MC7710 is working using ppp Limiter for user download and upload works fine

Still not yet working using pfSense 2.2.6 :

LED Thermal Sensor Still need to try how to have MC7710 working using DIP mode

Nicolas

The Snort GUI is as expected. The new Bootstrap GUI for Snort is under development and will be released as an updated package when it is ready. Snort should work OK; it's just the GUI that will look like Snort on 2.2 but with most of the icons missing. There may be some parts of the GUI that don't work properly, but you should be able to use a configuration upgraded from 2.2 successfully.

Your PS/2 to USB adapter will likely be detected as a USB mouse even though no mouse is plugged in. The error related to ums is really only cosmetic.

The pfSense developers are considering dropping x86 support after the last release in the 2.3.x series, as the majority of users have moved on to amd64. This means there is no need for immediate action, but it is worth starting to think about the options for replacing your existing hardware. The chances are that something modern will be more power efficient, giving some sort of payback over time.

There have been some hints that there will be an ARM version of pfSense in the future, but there is no firm commitment over whether this will happen. Additional platform support takes resources, so it may well be that the medium term intention is to use the resources freed up by dropping i386 to support a limited number of ARM boards. For now, if you are looking to buy replacement hardware, you need to look for an amd64 device.

@hda:

So you have assigned & enabled interface ue0 as OPT1, and there is nothing plugged on it or to do ?

There is just a Wireless AP connected to it via a POE injector that is constantly trying to connect to the syslog server on LAN and up to 3 wireless clients connected at any one time.  So not that busy but that interface also participates in the DHCPv6 setup with prefix ID 1 from WAN interface which goes down when ue0 drops and it takes all IPv6 with it.

I have been monitoring the usbdump since I posted this and there have been a few single ERR=TIMEOUT events and I do see an extra dhcpleases6 and dhcpd -6 process now (meaning there must have been some event that started another copy of those without killing the current ones) but I haven't seen IPv6 drop since I posted last…

If the verdict is that USB is too flaky for full time use I am fine with that.  I had this cheapo interface laying around so I have been trying it out.  I also have a mini-pcix slot I could use to get another interface if I had to...

@iamzam:

My problem may be different because it seems to have something to do with my OPT1 (ue0) interface going away and coming back many times an hour:

As hda says, you have a different issue - but one that is somewhat related to that discussed in this thread.

Your issue happens because your USB network interface keeps going down and coming back up. It really would be in your interests to get away from the problem by fixing or changing the interface if possible as an interface really should not be behaving this way.

The root cause is that nothing is terminating the dhcpd / dhcpleases6 / dhcpleases processes when the interface goes down. It may well be that interface_bring_down() (/etc/inc/interfaces.inc from around line 1219) should do this, though it would be important to check for possible side effects before making this change because this function is used in /etc/rc.linkup when a hotpluggable interface goes down (as in your scenario) but also in many other places.

one thing i noticed is disabling nat rules dont automatically disable associated firewall rules

Blow 'em away, they shouldn't come back. If they do, let us know.

Yay!

Thanks to everyone who helped to track this down and test the fix. I learn something from you guys every day  :)

Great, thanks! That was quick :)
GitSynced, gave it a quick test and it worked like a charm.

Thanks.

Just pushed a fix for this.