raspap, routing, expressvpn

[frankozland]

I have raspap installed. Performance isnt where it should be and i dont think the routing is correct.
I have eth0 and wlan1
desired is wlan1 clients can connect to raspap - raspap routes thru expressvpn and to lan connection on eth0

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
705 53450 MASQUERADE all -- any any anywhere anywhere
0 0 MASQUERADE all -- any any 192.168.50.0/24 !192.168.50.0/24

It doesnt seem thats whats happening tho

Everything should be going thru xvpn interface?

sudo iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination
xvpn all -- anywhere anywhere

Chain xvpn (1 references)
target prot opt source destination
xvpn_dns all -- anywhere anywhere
xvpn_ks all -- anywhere anywhere

Chain xvpn_dns (1 references)
target prot opt source destination
xvpn_dns_iface_exceptions all -- anywhere anywhere
xvpn_dns_ip_exceptions all -- anywhere anywhere
DROP tcp -- anywhere anywhere tcp dpt:domain
DROP udp -- anywhere anywhere udp dpt:domain

Chain xvpn_dns_iface_exceptions (1 references)
target prot opt source destination

Chain xvpn_dns_ip_exceptions (1 references)
target prot opt source destination
ACCEPT udp -- anywhere 100.64.100.1 udp dpt:domain

Chain xvpn_ks (1 references)
target prot opt source destination
xvpn_ks_iface_exceptions all -- anywhere anywhere
xvpn_ks_ip_exceptions all -- anywhere anywhere
ACCEPT udp -- anywhere anywhere udp dpts:bootps:bootpc
DROP all -- anywhere anywhere

Chain xvpn_ks_iface_exceptions (1 references)
target prot opt source destination
ACCEPT all -- anywhere anywhere

Chain xvpn_ks_ip_exceptions (1 references)
target prot opt source destination
ACCEPT all -- anywhere 10.0.0.0/8
ACCEPT all -- anywhere xxx.16.0.0/12
ACCEPT all -- anywhere 192.168.0.0/16
ACCEPT all -- anywhere xxx.254.0.0/16
ACCEPT all -- anywhere base-address.mcast.net/24
ACCEPT all -- anywhere xx.xx.57.250

[billz]

If you've used the VPN provider option at install time, bear in mind that RaspAP provides a rudimentary front end to this service only. See https://docs.raspap.com/providers/#control-scope

That is, it does not manipulate routing or any iptables rules related to the VPN service—that's entirely up to you and/or your VPN provider's CLI. Best advice is to consult the logging tab for the service. Alternatively, the debug log generator will give you a more comprehensive view of your system so that you may perform a self-diagnosis.

[frankozland]

I think there is an issue with the OS network stack and thats the purpose of the tests.
Totally ok - just want to get to bottom of it.
Its not just raspap - its also expressvpn - without raspap even installed - performance is abysmal.
Raspap has a similar issue - and because you are using cli so heavy/linux directly wrapped with php - your sw is perfect for isolating the layer thats having issues.

Sorry to be pest on all this - i really only trying to help the community.

On raspap - i only have raspap installed with the openvpn option installed but openvpn is disabled.
no ad block, no other cli or raspap api installed. expressvpn was removed and purged.

I have eth0 and eth1 and wlan0 (built in)

I confirmed both eth0 and eth1 works on raspberry.

The topology now is:
(fiber) -> router -> asus router acting as Access point -> (ethernet) -> eth0 on raspberry pi running raspap -> eth1 dongle -> (ethernet) -> linux desktop running manjaro linux

on the config for hotspot there is an option to select eth0, eth1, lo, wlan0. I shut down hotspot and selected eth1.
I attempted to "save settings"
This option is disabled.

So then i tried to start the hotspot again. It defaulted to wlan0.
so then i did a soft kill in linux to disable the wlan0
sudo rfkill block wifi
and went back to raspap - and tried to set to eth1.
it didnt work - hotspot would not start because it the wlan0 was disabled.

rfkill: WLAN soft blocked
wlan0: interface state UNINITIALIZED->COUNTRY_UPDATE
Using interface wlan0 with hwaddr dc:a6:32:5e:6a:05 and ssid "raspi-webgui"
Failed to set beacon parameters
wlan0: Could not connect to kernel driver
Interface initialization failed
wlan0: interface state COUNTRY_UPDATE->DISABLED
wlan0: AP-DISABLED
wlan0: Unable to setup interface.
wlan0: interface state DISABLED->DISABLED
wlan0: AP-DISABLED
wlan0: CTRL-EVENT-TERMINATING

So digging in a little - if user doesnt select a wifi device, the save button is disabled.
I think its in the .js code thats doin this - im not sure if thats intentional

its in custom.js starting on line 533 - eth1 isnt a wifi device - so no channel is selected and then the save settings button is disabled.

if (hw_mode === 'a') {
selectableChannels = data.filter(item => item.MHz.toString().startsWith('5'));
} else if (hw_mode !== 'ac') {
selectableChannels = data.filter(item => item.MHz.toString().startsWith('24'));
} else if (hw_mode === 'b') {
selectableChannels = data.filter(item => item.MHz.toString().startsWith('24'));
} else if (hw_mode === 'ac') {
selectableChannels = data.filter(item => item.MHz.toString().startsWith('5'));
}

    // If selected channel doeesn't exist in allowed channels, set default or null (unsupported)
    if (!selectableChannels.find(item => item.Channel === selected)) {
        if (selectableChannels.length === 0) {
            selectableChannels[0] = { Channel: null };
        } else {
            defaultChannel = selectableChannels[0].Channel;
            selected = defaultChannel
        }
    }

    // Set channel select with available values
    channel_select.empty();
    if (selectableChannels[0].Channel === null) {
        channel_select.append($("<option></option>").attr("value", "").text("---"));
        channel_select.prop("disabled", true);
        **btn_save.prop("disabled", true);**    // <---------------save button disabled here because selected device isnt wifi
    } else {
        channel_select.prop("disabled", false);
        btn_save.prop("disabled", false);
        $.each(selectableChannels, function(key,value) {
            channel_select.append($("<option></option>").attr("value", value.Channel).text(value.Channel));
        });
        channel_select.val(selected);
    }

[billz]

Sorry to be pest on all this - i really only trying to help the community.

No worries, your thorough report is appreciated 😉

This interface administers hostapd. Hostapd can do a lot of things, with some limitations. The most fundamental requirement is a WLAN adapter with AP mode support:

$ iw list | grep "Supported interface modes" -A 6
	Supported interface modes:
		 * IBSS
		 * managed
		 * AP
		 * P2P-client
		 * P2P-GO
		 * P2P-device

What it can do

1. Create an AP;
2. Create multiple APs on the same card (if the card supports it);
3. Create one AP on one card and another AP on a second card, all within a single instance of hostapd;
4. Use 2.4GHz and 5GHz at the same time on the same card. This requires a card with two radios though, which is pretty rare (but hostapd supports it)

What it cannot do

1. Create multiple APs on different channels on the same card;
2. Create a dual-band AP, even with two cards. But it can create two APs with the same SSID;
3. Assign IPs to the devices connecting to the AP, a dhcp server is needed for that;
4. Assign an IP to the AP itself, it's not hostapd's job to do this;
5. Create APs on cards without AP mode

I think I understand your use case. You want RaspAP to manage IPv4 rules to route traffic between your wired interfaces: eth0 and eth1. RaspAP supports this for WLAN interfaces but doesn't have a generalized UI for all network interfaces (yet). The "AP" in this project's name harkens back to its original purpose—administering hostapd on Linux with a web interface. It's evolved substantially since then but has remained focused primarily on WLAN connectivity sharing.

I can see adding a UI to support this at some stage, but hostapd isn't the right place for it. The Networking UI displays a summary of the routing table already; adding a tab to manage these interfaces is probably the next step.