ios: Sign in fails sometimes after an spr update

[0vercl0k]

So I've run into this bug several times now but it comes and go so I never really filed an issue for it. I also have limited details so here is what I have observed:

• This usually happens after an SPR update; usually the router itself; I am not sure if it has happened to me after an iOS app update though so can't rule that out
• From the user perspective I get an 'invalid password' but when I can see a 'private drop' event from that device trying to reach out to x.x.2.1 when the URL in the iOS app is set to x.x.3.1
• From that same device, I also don't seem to be able to access the web UI directly from the browser; trying to browse to it doesn't seem to generate any events, but I get 'safari couldn't open the page because the server stopped responding'
• Lockdown mode is turned on on that device so it might play a role, maybe

Let me know if there's any way for me to grab more useful information for you guys to figure this out :)

Cheers

[lts-rad]

@lts-po looking into this preliminarily i think it has to do with:

api/API.js: return gApiURL || 'http://192.168.2.1/'

const handleLogin = () => {
if (Platform.OS !== 'web') {
//TODO use URL to set/parse
let url = ${protocol}//${hostname}/
if (hostname.match(/mock|test/g)) {
url = 'mock'
}

  setApiURL(url)
}

doLogin(username, password)

}

I'm thinking something is off with the react state and this doesnt kick in when it needs to

[lts-rad]

discussing with @lts-po this might also be happening if the API is not ready yet. so perhaps we need to add a 3rd feedback option when the API isnt available instead of saying the login failed

[0vercl0k]

Could the web UI be working properly and the API not accessible at the same time? Because I was able to browse the web UI from another device without any issues!

…

On Mon, Sep 9, 2024 at 8:09 AM Alex Rad ***@***.***> wrote: discussing with @lts-po <https://github.com/lts-po> this might also be happening if the API is not ready yet. so perhaps we need to add a 3rd feedback option when the API isnt available instead of saying the login failed — Reply to this email directly, view it on GitHub <#366 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AALIOROB4SDG77HTMTXBJLLZVW22TAVCNFSM6AAAAABN3CYLLSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMZYGM4DMMBUGQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[lts-rad]

the web ui is be cached, but if you see data that means the API was working there

[lts-rad]

Discussing further with @lts-po the thing to investigate is if it's a routing issue. suppose a client gets put onto 192.168.10.118/30, but they are unable to reach 192.168.10.1 for some reason, but they would be able to connect to the API on 192.168.10.117.

We should see under which conditions this can happen and resolve it.

The MAC filter may be blocking the request in this situation because forwarding would take effect from the VLAN

[lts-rad]

  chain FORWARD {
    type filter hook forward priority 0; policy drop;

    # MSS clamping to handle upstream MTU limitations
    tcp flags syn tcp option maxseg size set rt mtu

    # Block rules
    counter ip saddr . ip daddr . ip protocol . tcp dport vmap @fwd_block
    counter ip saddr . ip daddr . ip protocol . udp dport vmap @fwd_block

    #jump USERDEF_FORWARD


    # Extra hardening for when running Virtual SPR, to avoid exposing API to the uplink hop
    # https://github.com/moby/moby/issues/22054 This is an open issue with docker leaving forwarding open...
    # Can disable this hardening by setting VIRTUAL_SPR_API_INTERNET=1
    $(if [ "$VIRTUAL_SPR_API_INTERNET" ]; then echo "" ;  elif [[ "$WANIF" && "$WAN_NET" ]]; then echo "counter iifname @uplink_interfaces tcp dport 80 ip saddr != $WAN_NET goto DROPLOGFWD"; fi)

    # Allow DNAT for port forwarding
    counter ct status dnat accept

    counter jump F_EST_RELATED

    # Do not forward from uplink interfaces after dnat
    # and after F_EST_RELATED
    iifname @uplink_interfaces goto DROPLOGFWD

    # Log after F_EST_RELATED to reduce logs

    # mark outbound for upstream with wan:out and others as lan:out
    oifname @uplink_interfaces log prefix "wan:out " group 0
    oifname != @uplink_interfaces log prefix "lan:out " group 0

    # Verify MAC addresses for LANIF/WIPHYs
    iifname @lan_interfaces jump DROP_MAC_SPOOF

    # After MAC SPOOF check, but before rfc1918 check
    # These rules allow permits via endpoint verdict maps
    counter ip saddr . ip daddr . udp dport vmap @ept_udpfwd
    counter ip saddr . ip daddr . tcp dport vmap @ept_tcpfwd

    # Drop private_rfc1918 access on upstream
    counter oifname @uplink_interfaces ip daddr vmap @drop_private_rfc1918

    # Allow additional interfaces to communicate upstream
    # This includes docker0, see fwd_iface definitions above
    # Note: if they should have rfc1918 forwarding access they need
    # to be added to @upstream_private_rfc1918_allowed.
    # These maps explicitly allow ranges, whereas @internet_access, @lan_access do not.
    # We can consider combining them later.

    counter oifname @uplink_interfaces iifname . ip saddr vmap @fwd_iface_wan
    counter oifname @lan_interfaces    iifname . ip saddr vmap @fwd_iface_lan

    # Now accept LAN to the container/custom interface in reverse
    counter iifname @lan_interfaces    oifname . ip daddr vmap @fwd_iface_lan


    # Forward to Site VPN if client has site access
    counter oifname @outbound_sites ip saddr . iifname vmap @internet_access

    # Forward to site interfaces if client has site access, filtered by src+addr
    counter ip saddr . ip daddr . oifname vmap @site_forward

    # and port specific ones
    counter ip saddr . ip daddr . tcp dport . oifname vmap @site_forward_tcp_port
    counter ip saddr . ip daddr . udp dport . oifname vmap @site_forward_udp_port

    # Forward to uplink interfaces
    counter oifname @uplink_interfaces ip saddr . iifname vmap @internet_access

    # The @lan_access dynamic verdict map implements the special LAN group in SPR.
    # It allows one-way access to all stations, without an explicit relationship by IP,
    #  with a NAT return path (F_EST_RELATED)

    # 1. Transmit to the LANIF interface
    counter oifname @lan_interfaces ip saddr . iifname vmap @lan_access

    # 2. Transmit to the wireguard interface
    $(if [ "$WIREGUARD_PORT" ]; then echo "counter oifname wg0 ip saddr . iifname vmap @lan_access"; fi)

    # 3. Forward to wireless stations. This verdict map is managed in firewall.go
    jump WIPHY_FORWARD_LAN

    # Custom groups. Managed in firewall.go
    jump CUSTOM_GROUPS


    # Fallthrough to log + drop
    counter goto DROPLOGFWD
  }


so we would expect nft:drop:mac if its the MAC address filter, otherwise nft:drop:forward if its something else

[0vercl0k]

I am still running into this fwiw - this time I triggered this after forgetting the network, and joining the network as a new device. Every time I try to log-in on 192...1.1, I see events that says that my device is trying to access 192...2.1 somehow.