IPFire Mini Appliance - observations / questions

Networking
1

Dear community,

I fiddled around with ipfire before (tested it on a Raspberry Pi 4B) and it worked pretty good, but now I wanted something proper! =) So I’ve been a proud owner of an IPFire Mini Appliance (including the Wireless Kit) for three days now (thanks again to Michael Tremer at this point for the fast, friendly and helpful contact :-)).

I’m still in the stage of testing / configuring and I wanted to share some observations and ask some questions.

Beforehand:

Clean installation via USB (mounted image on a Zalman/IODD) and the console-port worked like a charm, even though the boot-menu seemed a bit drunk. :smiley:

Screenshot 1

I did a firmware-upgrade afterwards, so now it’s version 4.17.0.3 from August 2022. According to “pcengines”, 4.19.0.1 has been out recently, is there already a date when it will be available through pakfire?

My software-version itself is 2.27 - Core Update 173

So much for the facts, now to the observations / questions.

  1. Dongle

I have a Delock USB-to-ethernet-dongle plugged into the IPFire Mini Appliance (because I need a fifth Ethernet-Port). Everytime I reboot the appliance, the dongle is not shown in the zone-configuration (although it’s recognized by the device, because it’s listed via “lsusb”). But when I disconnect it from the running appliance and plug it back in again, then I can select a zone for it and it works without any problems.

Where could the error be? The problem appears on both USB-ports. How can I make ipfire recognize the dongle / show the dongle in the zone-configuration right from the start?

  1. Ping

Even when I grant full access from blue to green (just for testing), either for single IPs or the whole net, with all protocols and so on, I’m not able to ping a device in the green zone from the blue zone (or at least get no response to the ping), although I can connect to shared folders or web-services for example. Is this “works as designed” or am I missing out on something?

  1. Same old (long) story, but the last one for now, I promise! :wink: HT Caps and VHT Caps

I opened up the IPFire Mini Appliance to make sure it has the Compex WLE600VX module (“lspci” just spit out “Qualcomm Atheros QCA986x/988x 802.11ac Wireless Network Adapter”).

I downloaded the instruction manual from Compex (nothing to find on Qualcomms website),

https://compex.com.sg/shop/wifi-module/802-11ac-wave-1/wle600vx-wifi5-11ac-qca9882-qca9892/

read through the ipfire-Wiki and forum and even picked some useful details from that teklager post about configuring IPFire Wifi

iw list gave out

            Capabilities: 0x19ef
                    RX LDPC
                    HT20/HT40
                    SM Power Save disabled
                    RX HT20 SGI
                    RX HT40 SGI
                    TX STBC
                    RX STBC 1-stream
                    Max AMSDU length: 7935 bytes
                    DSSS/CCK HT40
            Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
            Minimum RX AMPDU time spacing: 8 usec (0x06)
            HT TX/RX MCS rate indexes supported: 0-15
            VHT Capabilities (0x338001b2):
                    Max MPDU length: 11454
                    Supported Channel Width: neither 160 nor 80+80
                    RX LDPC
                    short GI (80 MHz)
                    TX STBC
                    RX antenna pattern consistency
                    TX antenna pattern consistency

So from “iw list”, the instruction manual, the teklager-posting and an intensive lecture of two different hostapd-example-configs, I figured, the right Caps for the Compex WLE600VX had to be

HT Caps: [OFDM][BPSK][QPSK][DBPSK][DQPSK][16-QAM][64-QAM][256-QAM][LDPC][HT20][HT40-][HT40+][SMPS-DYNAMIC][SHORT-GI-20][SHORT-GI-40][TX-STBC][RX-STBC1][MAX-AMSDU-7935][DSSS_CCK-40]

VHT Caps: [MAX-MPDU-11454][RXLDPC][SHORT-GI-80][TX-STBC-2BY1][RX-ANTENNA-PATTERN][TX-ANTENNA-PATTERN]

In “HT Caps” I set [SMPS-DYNAMIC] because even though “iw list” shows “SM Power Save disabled”, the instruction manual says this module supports “Spatial Multiplexing”. I choose [SMPS-DYNAMIC] over [SMPS-STATIC] because I considered it to be more efficient, but on the other hand I don’t know if it’s even working. :smiley: Maybe someone could throw light on this. =)

Only on the teklagers site, I found that you also have to write down the modulations-caps ([OFDM][BPSK]…[256-QAM]). Oddly enough, the first time I activated WLanAP, I left them out and I could not get 802.11ac to work (only a,b,g,an or gn). Later, I punched them in and 802.11ac worked. Now, when I delete them from HT Caps, 802.11ac still works. Does anyone know why?

Both, my laptop and ipfire show a connection at around 800 Mbit/s (ipfire says it’s the maximum of 866, on my laptop it’s sometimes 575, sometimes 650, sometimes 780, whatever). Anyway some test-downloads from my NAS gave a maximum speed at about 45 mbyte/s, which would be 360 mbit/s. Is there any possibility to improve this? Maybe through other Caps? Considerations following:

On the Wiki-site for the Mini Appliance (no more than two links allowed for me :P) and the hardware-compatibility-list (no more than two links allowed for me :P) there are some more / different caps than the ones I have:

For “HT Caps”, there are additional [RX-STBC] and [SMPS-STATIC]. I guess [RX-STBC] is either wrong or obsolete, because according to hostapd it’s either [RX-STBC1], [RX-STBC12] or [RX-STBC123]. The thing about [SMPS-STATIC] I mentioned before.

For “VHT Caps”, there are additional [RX-STBC-1][MAX-A-MPDU-LEN-EXP7][BF-ANTENNA-2][SOUNDING-DIMENSION-2][VHT-LINK-ADAPT3] listed on the ipfire-pages, but I could not find any hints on these in the manual for the module nor via iw list. What are they for?

I read through Caps part on the openwrt-page (the only half-decent list I found) but my understanding in Wifi-technique is not that low level. Maybe again, someone could explain a few things. =)

For my understanding the “Caps” are just features, so it wouldn’t hurt to punch in as many as you can. If there are some completely false, the interface just would not come up, which is ok. But could there be some Caps that slow down the interface or lead to errors in the transmission?

I would really appreciate some answers / observations from you guys, so that we can get more facts down. I would like to correct / complete the two ipfire-Wiki-sites (because at the moment they are mutually contradictory), so that “new” people do not have to research as long as I did. =)

Hope, I didn’t bore you too much and looking forward to your answers. Have a nice weekend! :slight_smile:

Greetings

Alex

3

Find out for yourself. Open a console, issue the following command tail -f /var/log/messages, then ping from a machine in blue to the blue network gateway, then ping from blue to a green machine or the green gateway interface. What do you see in the kernel? ctrl-c to exit.

1 Like
4

the NAS is connected through WIFI? If yes, that’s pretty much the maximum for the card.

5

The following Wiki page may be helpful

Best

4 Likes
6

Hey there and thanks your replys,

I tried it, I can ping the green interface from the blue network, but no clients in the green network. The other way around works, clients in the green network can ping clients in the blue one.

There’s nothing in the kernel-messages. It does not bother me that much, I just wanted to know why it does not work.

Nope, the NAS is connected via ethernet and in the green zone. Laptop is the only wifi-client and in the blue zone. Green and blue are not bridged, maybe it’s not the AP but the switching capacity?

7

Haha, did not know this page but it wasn’t that big of a problem to me. Figured it out by myself yesterday, I just thought it would be funny. :slight_smile:

8

I did some test and by default the ICMP packets are not logged. However, I wrote a DROP rule specifying the ICMP ECHO_REQUEST protocol plus setting the rule to be logged, and it worked as expected including the logging. Basically, it logs only drop or reject, not allow.

Can you try to open another pinhole, specifying as protocol ICMP and ECHO_REQUEST(8)?
EDIT: you should put this rule before the other with protocol=ANY.

I am guessing choosing “ANY” in the protocol section of the rule does not include (all?) ICMP categories.

1 Like
9

how did you do your speed test from the NAS? Which points were connected?

If you did it from the laptop, then the WIFI is the bottle neck.

10

Good call, I would have never thought of that, but unfortunately it’s not the reason for this behaviour either.

The only way I get to ping a client in the green zone out of the blue one is to include NAT in the firewall rule (obviously). Without NAT, there is no chance at the moment.

If I have time on the weekend I will check the firewall-rules per ssh, meaning iptables itself. Maybe there is some sort of “–icmp-type”-rule that blocks every echo-requests from blue to green right from the beginning. :slight_smile: Maybe too much effort for this “problem”, but hey, it’s knowledge. :smiley:

The NAS is connected via ethernet directly with the ipfire. The test was, to download some files from the WebInterface of the NAS (it’s a Synology) right through the browser. I did it two weeks ago, when everything was still connected to the FritzBox and I was pretty impressed, because it almost reached 100 Mbyte/s.

But then again in a FritzBox it’s all on the same virtual interface (or at least in the same subnet) and no routing has to be done, so I thought maybe that could be a factor, too.

Anyway, my Internet-Speed is slower than 360 Mbit/s, so it does only matter when I transfer files within the network, but you know… a litte bit more would be nice. :slight_smile:

Thanks for you help, guys! If you have any more ideas, I’d be glad to hear them.

11

If the NAS and the laptop are both on the green network then the speed performance is only due to those two machines and the cables/switches between them. Traffic on the same subnet does not go through IPFire.

I just tried this out on my vm testbed system.

With no blue to green pinhole rules:
I tried a ping from a green machine to a blue machine and ping worked fine.
I then tried the same from blue to green and ping had 100% dropped packets.

Then I created a firewall rule for the blue to green pinhole.

Source was Blue network.
NAT left unchecked.
Destination the IP of a machine in green.
Protocol ICMP.

Then ran ping on blue to the green machine and all packets successfully transmitted.

Just a thought. You did allow the MAC address for your machine on blue in the Blue Access WUI page, or you can allow the whole blue subnet with no MAC filtering.
See:-
https://wiki.ipfire.org/configuration/firewall/accesstoblue

3 Likes
12

You misunderstand how NAT, specifically Destination NAT works and what problem it is designed to solve. It was the case for me for a long time and still is for many other topics. In network engineering details are crucial and creating a model of how things work without looking to the details leads to gigantic errors of judgment, especially in the troubleshooting phase.

The premise of DNAT is the scarcity of IPv4 address space. You have ONE public address on the wan side, and SEVERAL servers on the LAN side with local IPs. How can you make all of them publicly accessible with only one public IP address? You do DNAT using the ports to sort the traffic. The router has a rule for each port which allows to create a table whereby it know that incoming traffic to port 80 goes to 192.168.0.23 and incoming traffic to port 21 goes to 192.168.0.24. It keeps track of these two streams and does the necessary switching of traffic.

All this is not necessary at all to route traffic inside the LAN. If 192.168.0.23 needs to serve a web page to a client with the IP of 192.168.1.14, it just emits the packets with the correct source and destination written in the corresponding data fields and the router does not need to take notes and convert numbers, it just reads those numbers and switch the packets to the corresponding network. No DNAT involved.

As a final note, ICMP packets are not UDP or TCP, they have a different structure and the concept of PORT does not apply.

1 Like
13

For testing reasons I followed your idea and put the WiFi-adapter in the green interface as well, and download-speed (from NAS to laptop) peaked at 60 Mbyte/s (so almost 500 Mbit/s). Thats more like what Michael Tremer said on the Wiki-page of the Mini Appliance. :wink:

Although 25% loss because of the way through the firewall (when WiFi is on blue) seems a bit much (because there are actual no rules applied), I can live with it. After all it was just to “explore the limits”. :slight_smile:

Concerning the ping…

Access to blue is configured correctly, the laptop in the blue zone has internet access and everything and like I said, I can even ping the green interface from blue, just not a green client. I tried source: IP, destination: IP; source: blue, destination: green; and some variations. I also choose ICMP as a protocol but no ping from blue to green. Maybe because of the many changes, a reboot of the Ipfire after applying the rules would have done the trick. I will test this out later today or tomorrow. Thanks for your example-configuration! :+1:

I don’t wanna sound smug here, but I have a Cisco CCNA (or at least I did… did not renew it after 3 years :crazy_face:), so I KNOW what NAT is for and to be nit-picky it’s not only NAT, but also PAT (at least that’s what Cisco calls it) because you have to masquerade many internal IP-adresses at the same time with one external IP-adress and this only works with port-overloading, which means that you allocate different ports “of” the external IP-adress to different internal IP-adresses, otherwise you could have only one internal IP adress behind every external IP adress. :wink:

Anyway, I did not want to start a discussion about NAT in my posting before, I just wanted to add the comment, that ping from blue to green only works with NAT activated (obviously) but not without. But then again, like I wrote before, maybe it was to much fiddling with the firewall-options and ipfire just needed restart at some point. I will try out the configuration that Adolf Belka suggested. :slight_smile:

Greetings

Alex

14

again, what does NAT have anything to do with the ping from inside the LAN? Hopefully you will understand why I thought you did not know in enough detail how DNAT works.

Thanks for the opportunity you offered to learn new things with this thread and best wishes for your current projects. I am checking out this thread.

1 Like
15

That sounds very weird and not normal.

What happens if you run the ping command for the green client from the IPFire command line.

Are the green clients getting dynamic IP addresses from IPFire, or have you defined Fixed Leases for them in the IPFire dhcp page or have you defined static IP’s on the clients themselves.

I am presuming that this means that after creating the firewall rule for the blue to green pinhole that you did press the Apply Changes button at the top of the Firewall Rules WUI page. (Clutching at basic straws as running out of ideas why your IPFire is performing so non standard.)

2 Likes
16

Again, it was just a comment about the internal firewall-rules, I activated “Source NAT” within the firewall-rule, that allows Blue-To-Green-Communication… and then ping was possible. When I deactivated NAT, ping did not work anymore. It was just an observation.

I did some more testing and all I know is, that it has nothing to do with the IPFire. I tried pinging other devices in the green network and they answered. Just this one device (a perfectly normal Windows-10-machine) did not answer… I don’t know why… maybe when I set it up (months ago) I choose some security-options, which forbid ping-echos to other subnets. When I ping form the IPFire-Interface (in the same subnet), then there is a respond…

Anyway, I did not want to bother anyone for so long about the ping-stuff, this was the least important topic on my list. :smiley: Anyway, thank you all very much for guiding through the solution or at least the explanation. :slight_smile:

If anyone could add some more informaiton about the Wifi-Caps, I would like to update / complete the entrys in the IPFire-Wiki. :slight_smile: