Hi Steve,
while collecting the information for my reply, I think I found the relevant point:
Search scope level was set to "one level". Setting it to "entire subtree" seems to fix the problem.

Thanks!

The pf antispoof rules that are applied by default should block that traffic anyway and are above the user rules.
Something isn't right there. Is that counter still increasing? Did you change the rule previously maybe?

Steve

Hi,

Access console, use option 8.
Type

and look for all hardware the kernel found, typically NIC's.

pfSense uses the NIC's the OS (FreeBSD) has found.

@warudo said in Accessing 169.254.2.1:80 on an OPT interface from the LAN interface:

I did some digging through the FreeBSD sources.
While the blocking of this subnet can be disabled in pfSense and causes it to respond to packets, the underlying FreeBSD TCP/IP stack is hardcoded to not forward traffic from and to it. The relevant part is here.
So this seems to be impossible.

Of course it's impossible, it's against the RFC to do that.

https://tools.ietf.org/html/rfc3927

Section 2.6.2
[...]
The host MUST NOT send a packet with an IPv4 Link-Local destination
address to any router for forwarding.

Section 2.7 Link-Local Packets Are Not Forwarded

A sensible default for applications which are sending from an IPv4
Link-Local address is to explicitly set the IPv4 TTL to 1. This is
not appropriate in all cases as some applications may require that
the IPv4 TTL be set to other values.

An IPv4 packet whose source and/or destination address is in the
169.254/16 prefix MUST NOT be sent to any router for forwarding, and
any network device receiving such a packet MUST NOT forward it,
regardless of the TTL in the IPv4 header. Similarly, a router or
other host MUST NOT indiscriminately answer all ARP Requests for
addresses in the 169.254/16 prefix. A router may of course answer
ARP Requests for one or more IPv4 Link-Local address(es) that it has
legitimately claimed for its own use according to the claim-and-
defend protocol described in this document.

This restriction also applies to multicast packets. IPv4 packets
with a Link-Local source address MUST NOT be forwarded outside the
local link even if they have a multicast destination address.

As @stephenw10 said maybe if you had a VIP on WAN in 169.154.x.x and you did NAT to that on the way out it might work, but it would likely still fail to be carried properly since the original host is violating the RFC by sending 169.254.x.x traffic to a router when trying to connect. I would not use a gateway or route-to on traffic to or from 169.254 -- See https://redmine.pfsense.org/issues/2073 for why.

What you might need is inbound NAT on the LAN of pfSense to map that 169.254 address to something actually routable.

LAN host -> destination LAN VIP -> exit WAN outbound source NAT to 169.254.x.x to destination of 169.254.x.x. The link-local stays local, no RFCs would be violated by that behavior (technically).

Makes no sense.. Have you messed with your outbound nat?

Yes it's unclear exactly what they are counting or should be counting. To me at least.
I would not rely on them for any accurate measure of traffic that is matched.

Steve

One thing I've just thought about, it would only disallow the connection if they disconnected and then tried to re connect.

Maybe FreeRADIUS isn't the solution.

Per your drawing your multicast traffic doesn't hit your wan..

If you have questions to what is being counted why not just sniff on the interface and see.. Looks like your wan is a pppoe connection.

Forked from here:

https://forum.netgate.com/topic/92318/pfsense-active-directory-admin-authentication-via-radius/12

Where are you seeing this throughput?

Steve

@stephenw10 Hi Steve, I shall try that! Thank you

Consider this a low priority bug.
pfSense has a menu item in the status menu : Package logging. And guess what, I didn't find yet one package that logs its output over there. Worse : huge loggers like FreeRadius log in the "main" pfSense log file "system", or, I really think it shouldn't.
Why I'm talking about this ? Because you would have seen that your cron didn't work ... because not logs ... Every major OS these days have a cron.log.

But glad it worked out for you.

I'm doing this in a real (real) way, in a company. This company had problems of intrusion (violation) through a CRM server (data shared inside and outside the company) I mounted a virtual environment, added a firewall (PFSENSE) those servers that have external access. This would be my DMZ, soon after the firewall (already existing in the AKER company) and wanted to bar all external accesses from that line forward.

I have already written the part of the article academically. Now my difficulty is to demonstrate what I have done and what will happen to improvements from the implementation of this DMZ

That works! I had tried it that way previously, a few years ago, without luck.
It now seems to work.
Thank you!

@dranick You are probably referring to Cisco open-sourcing Vector Packet Processing (VPP) which is a fundamental part of a Netgate product called TNSR which is a completely different code base from pfSense.

OpenVPN works. Maybe you should concentrate on asking some questions there, watching the OpenVPN hangouts, reading the pfSense book's OpenVPN section, etc.

There is no functional difference in OpenVPN on Community Edition on a VM and factory on an XG-1537.

i had try do that before, now i have upgrade PF 2.4.3 to 2.4.4, but i can't open lan gateway webGUI, i can ping gateway ip and network work, why i can't open webGUI. i need waiting for fix this and then try setup MTU again.

It should see the USB image as bootable if you have UEFI enbabled.
That looks like a regression though. Thanks for reporting.

Steve

I made the change for the zfs arc cache in loader.conf and then rebooted. The memory is back down to normal and no swap usage as expected. Hopefully that will solve it for good. I'll keep an eye on it.