Messages

Nice. That one is available even with an N6005, which has more performance than the J4125, especially single-threaded. Slightly higher cost and power draw, but not too much.

My savior! How can I have overlooked that?

This type of alias is robust against NDP.

Big thanks, Franco!


Explanation as to what I was trying to accomplish: Make accessible a port of an IPv6 host behind OpnSense from the WAN side via a DNS entry. My ISP (M-Net) does not offer IPv6 IA-NA, i.e. I do not get an IPv6 on the WAN interface, but only on the LAN interface via IA-PD.

Thus, I need:

1. A working firewall rule that is robust against IPv6 prefix changes (now I have it)
2. Dynamic DNS that can handle a /56 prefix change, but keep the lower 72 bits of the client host (8 bits prefix-ID from "track6" of the LAN interface plus 64 bits interface id derived from the MAC). With this trick, OpnSense can do the dynamic DNS updates for any number of LAN clients and assign different names for them.
That, I have too (by implementing my own DynDNS).

Damn. So with changing IPv6 prefixes, the way to go would be to have the possibility of specifying a partly-qualified IPv6 that masks out the dynamic prefix part like what AVM does in their Fritzboxes.

That would need a new alias type, though.

I have found an apparent problem when I define a rule on the WAN interface that allows IPv6 traffic to a host on the LAN.

The rule in question defines the LAN host by its MAC address via a firewall alias. That is mainly because my ISP assigns dynamic IPv6 prefixes, so that the rules cannot be specified via full IPv6 addresses - or at least they will be outdated when I get another prefix. Thus, specifying a destination host via its MAC seems like a good option.

However, I found that after I reboot my OpnSense or get a new IPv6 prefix, the rule does not fire, but instead the "default deny all" rule blocks incoming IPv6 packets for the LAN host. The command I use to test if the port is open is "nmap -p<port> -Pn -6 <ipv6addr>".

This starts to work only after I trigger an IPv6 neighbor discovery of that host on the OpnSense box, like a ping from OpnSense to the host. It does not work the other way around as the host uses IPv6 privacy extensions and thus usually does not communicate via its EUI-64-based, but over one of its temporary IPv6 addresses.

It can be proven that the neighbor cache is the culprit by looking at "ndp -a", which shows the hosts IPv6 when it works. Once I remove the address with "ndp -d <ipv6addr>", the connection is blocked again.

If I use a firewall rule that is based on the real IPv6 instead of the MAC of the host, it works without having to "introduce" the host in this way first. I would expect the same behavior with a MAC-based rule - I am almost sure that I tried that on 21.x and never had that problem. The MAC trick was discussed by other people as well, who did not have that problem.

I do not get what is wrong here, i.e. why is the packet not matched anyway? Is the MAC-based rule matching depending on the content of the neighbor cache and not followed blindly, like it should? What about IPv4: Is the ARP cache involved there? Is that behavior new in 22.1?

With the advent of more and more IPv6-only ISPs, such problems are becoming quite visible.

Works for me, too.

Yes, and systems like that are available even with passive cooling, with a J4125 and 4x I225-V NICs:

https://www.amazon.com/gp/product/B09PHHXN9V

Depends on if you need 1U for rack mounting, though, but that is likely to have active cooling.

I have a HUNSN RS34g and that works fine as I wrote - it is also dirt cheap:

https://www.amazon.com/gp/product/B09PHHXN9V

It is available as RS34f with I210 as well. The RS34g has only one SODIMM slot if you want to buy it as a barebone, the RS34f has two. Internal storage is M.2/SATA or plain 2.5" SATA.

The machine is about 80% performance of the DEC7x0 at ~10 Watts. It has USB and HDMI/VGA output, so you can access the BIOS - essentially, this is a PC with 4 NICs.

I would not try to fuse FreeBSD and OpnSense together, but just test if Linux or FreeBSD work plain vanilla - so you could see if there is a problem with OpnSense kernel specifically.


P.S.: There is now a review out from ServeTheHome: https://www.youtube.com/watch?v=wUcDg_ms0is

In the pfsense thread, there were two more tips:

1. Disable any other NIC in the system.
2. Boot up with no cable plugged in.

Would be interesting to see if the system works with vanilla FreeBSD oder Linux.

Good for you. When I looked for a similar device in 2020, there were few that supported 2.5 and 5 GBps.

Ubiquiti sells one, but that gets reportedly too hot. I got one that works like yours, i.e. the intermediate speeds are intransparent to the host. This is O.K. for most cheap 2.5 Gbps counterparts (like Realtek-based chips), but can be problematic for counterparts that also have all speeds.

I found that anything up to 5 Gbps is fine over older CAT5 cabling, whereas 10 Gbps sometimes works but is unreliable. Thus, manual selection would be nice to have...

Another question: I think that the DEC700 series uses Insyde as well - however the BIOS page does not say that the BIOS update is applicable.

So will there be an update for those devices as well?

I just received my device and the I225-V worked right out of the box with 22.1.2. It is indeed also a revision 3 chip:

Code Select Expand

#pciconf pciconf -lbcevV
igc0@pci0:1:0:0:        class=0x020000 rev=0x03 hdr=0x00 vendor=0x8086 device=0x15f3 subvendor=0x8086 subdevice=0x0000
    vendor     = 'Intel Corporation'
    device     = 'Ethernet Controller I225-V'
    class      = network
    subclass   = ethernet
    bar   [10] = type Memory, range 32, base 0xa1b00000, size 1048576, enabled
    bar   [1c] = type Memory, range 32, base 0xa1c00000, size 16384, enabled
    cap 01[40] = powerspec 3  supports D0 D3  current D0
    cap 05[50] = MSI supports 1 message, 64 bit, vector masks
    cap 11[70] = MSI-X supports 5 messages, enabled
                 Table in map 0x1c[0x0], PBA in map 0x1c[0x2000]
    cap 10[a0] = PCI-Express 2 endpoint max data 256(512) FLR RO NS
                 max read 512
                 link x1(x1) speed 5.0(5.0) ASPM disabled(L1)
    ecap 0001[100] = AER 2 0 fatal 0 non-fatal 0 corrected
    ecap 0003[140] = Serial 1 00e269ffff52857e
    ecap 0018[1c0] = LTR 1
    ecap 001f[1f0] = Precision Time Measurement 1
    ecap 001e[1e0] = L1 PM Substates 1



They show up as being configurable for all speeds up to 2500 MBit/s. I tried only with 1 GBit/s and throughput was fine even without any tuning.

I think Intel had hardware problems with older revisions and that is the reason for B3. I comes with newer firmware, I think the 145 version was for B2 or even B1 in order to reduce the impact of the hardware problem.

https://www.borncity.com/blog/2020/05/03/bug-in-intel-ethernet-controller-i225-v-v1-gefixt/

I225-LM and I225-V should be only slight variants (the former with commercial features like 5 year support).

I am still eagerly waiting for delivery of my system which supposedly has 4x I225-V and will report back.

I would try to check if the multicast traffic really reaches the clients with "tcpdump -i eth0 -s0 -vv net 224.0.0.0/4" - but that relies on a proper client.

If not, there are only so many possibilities: Firewall out rules, weird VLAN filtering, routing problems diverting the packets or a switch not forwarding multicast.

I use mdns-repeater, too. The process was running:

Code Select Expand

#ps auxwww | fgrep mdns
root   47056   0.0  0.0  12652  2288  -  Ss   22:44       0:00.00 /usr/local/bin/mdns-repeater -p /var/run/mdns-repeater.pid ax0_vlan7 ax0_vlan108 ax0


Started without "-f", the process never outputs anything, so nothing is logged.

After I killed the process and restarted with debug on, I could see it working:

Code Select Expand

# /usr/local/bin/mdns-repeater -p /var/run/mdns-repeater.pid -f ax0_vlan7 ax0_vlan108 ax0
mdns-repeater: dev ax0_vlan7 addr 192.168.7.1 mask 255.255.255.0 net 192.168.7.0
mdns-repeater: dev ax0_vlan108 addr 192.168.108.1 mask 255.255.255.0 net 192.168.108.0
mdns-repeater: dev ax0 addr 192.168.1.2 mask 255.255.255.0 net 192.168.1.0
data from=192.168.108.80 size=120
repeating data to ax0_vlan7
repeating data to ax0
data from=192.168.7.210 size=114
repeating data to ax0_vlan108
repeating data to ax0
data from=192.168.7.210 size=114
repeating data to ax0_vlan108
repeating data to ax0
data from=192.168.108.22 size=519
repeating data to ax0_vlan7
repeating data to ax0
data from=192.168.108.81 size=41
repeating data to ax0_vlan7
repeating data to ax0
data from=192.168.108.80 size=585
repeating data to ax0_vlan7
repeating data to ax0
data from=192.168.108.23 size=481
repeating data to ax0_vlan7
repeating data to ax0


Also, my printer, as well as my AppleTV, which are both on VLAN 108, showed up on a smartphone on my guest VLAN 7, so MDNS seems to work fine here in a situation similar to yours.

Did you use hardware VLAN filtering and is your hardware capable of that? igbX usually stands for Intel hardware which should be fine?

[everybody]

You cannot fix a problem that does not even occur on your side.

While it may be true that you have some blocking for that particular website, it does not function from anywhere, even if the DNS entry works... everybody sees a 404 error, with OpnSense or without:

Code Select Expand

#wget -O- https://ssl.kaptcha.com/
--2022-02-28 13:38:56--  https://ssl.kaptcha.com/
Resolving ssl.kaptcha.com (ssl.kaptcha.com)... 54.148.115.137, 35.80.101.90, 35.81.31.24
Connecting to ssl.kaptcha.com (ssl.kaptcha.com)|54.148.115.137|:443... connected.
HTTP request sent, awaiting response... 404 Not Found
2022-02-28 13:38:57 ERROR 404: Not Found.

See? This is on a system that is not even remotely dependend on OpnSense - and I tried several ones.