jeff___m has quit [Remote host closed the connection]
jeff___m has joined #openwrt-devel
tSYS has joined #openwrt-devel
jeff___m has quit [Remote host closed the connection]
jeff___m has joined #openwrt-devel
jeff___m has quit [Ping timeout: 480 seconds]
jeff___m has joined #openwrt-devel
jeff___m has quit [Ping timeout: 480 seconds]
slh has quit [Remote host closed the connection]
slh64 has quit [Quit: gone]
slh has joined #openwrt-devel
slh64 has joined #openwrt-devel
SpectreDev_01 has joined #openwrt-devel
<SpectreDev_01>
Hmm weird I got openwrt fully working on a ipq807x device but not getting the full speed I have 1.1/1.2gbps connection but only getting 600mbps at peak
<slh64>
the network/ switch drivers currently available are very basic and don't even support checksum offloading (without nss), meaning they're rather slow and depend a lot on the CPU power
<slh64>
that's where 1.4 GHz (ipq8071a) vs 2 4 GHt (ipq8072a+) makes a material difference
<slh64>
around 600 MBit/s would match my experiences with ipq8071a, but resulta will vary if you add PPPoE or sqm into the mix
<SpectreDev_01>
Hmm I've tried to build with nss but it ends up killing WiFi and ethernet
goliath has joined #openwrt-devel
robimarko has joined #openwrt-devel
<mrkiko>
Ansuel: Great work for the nbg7815 fan - still, can you explain me little bit what you did with the aqr thermal zone, how the correlation between it and the tmp103 works?
<mrkiko>
Ansuel: plain curiosity
<mrkiko>
Ansuel: furthermore, on an unrelated note, wonder if bluetooth works for you
<mrkiko>
Ansuel: on a unit on which I tested it, it seems to initialize and wortk but sees no devices around
autkin has joined #openwrt-devel
hanetzer1 has joined #openwrt-devel
hanetzer has quit [Ping timeout: 480 seconds]
SpectreDev_01 has quit [Quit: Connection closed for inactivity]
autkin has left #openwrt-devel [#openwrt-devel]
autkin has joined #openwrt-devel
<f00b4r0>
is bridge leakage expected? Context: router two (uci) network interfaces, "LAN" and "DMZ". uhttpd listening on "LAN" ip to allow access to Luci. No forwarding setup between DMZ and LAN. Client connected to DMZ can access luci by inputing the "LAN" IP address
<f00b4r0>
both network interfaces are part of a bridge-vlan
<f00b4r0>
and sit on different vlans
<f00b4r0>
LAN and DMZ are part of different firewall zones. This is on 23.02
<f00b4r0>
netstat shows ip connection from DMZ client ip to LAN router ip
<jow>
f00b4r0: but it has always been this way for me
<jow>
f00b4r0: that's why we keep explaining users that they should port scan their wan ports from the outside
<jow>
if you "come in" via an interface that allows input, you can reach all IP addresses local to the router
<jow>
regardless of their zone policies
<jow>
which also makes sense since zone policies are source interface bound
<f00b4r0>
i'm sorry I don't understand
<f00b4r0>
what I'm seeing is: it's impossible to firewall a multihomed router
<f00b4r0>
in a bridge-vlan configuration
<f00b4r0>
someting that bridge-vlan was, AIUI, designed to solve.
<jow>
was it?
<f00b4r0>
I think it wsa, but that's not the point anyway
<jow>
it's purpose is to segregate a bridge into a bunch of vlans
<jow>
semantics should be identical to those of a bunch of nics
<f00b4r0>
if you have bridge-vlan and one of its member allows incoming packets, as soon as you sit on a routable interface to any of the other ones, you can access everything
<jow>
*everything on the router*
<f00b4r0>
which means it's impossible to segregate router services per interface
<f00b4r0>
yes
<f00b4r0>
which is very bad when one of your interface serves an untrusted network
<jow>
can you please share your "nft list ruleset" as well as your network configuration?
<jow>
still struggling to understand your setup
<f00b4r0>
but what makes no sense to me here is that there seems to be some routing involved, since the 10.234 and 192.168 networks are routed on the router (according to netstat output), *despite* this being not allowed.
<jow>
yes, I think ingress from DMZ is simply allowed
<jow>
maybe the firewall ruleset is incomplete
<jow>
or zones are overlapping in scope
<f00b4r0>
what's the curl-based pastebin url if someone can jog my memory?
<f00b4r0>
the CoA responder I tested from LAN zone tbh
<f00b4r0>
i really must eat, I'm totally starving
<jow>
the daddr 192.168.1.1 reject rule comes too late
<jow>
you should move it before the port accept rule
<jow>
and I would generalize it into !a.b.c.d/e where a.b.c.d/e is the subnet of the DMZ interface
<jow>
or potentially even !a.b.c.d without mask to only allow input to the routers ip in this subnet
<f00b4r0>
so moving the rule seems to work. But why spelling out that rule work when according to the weak host model it shouldn't matter either?
<jow>
the weak host model applies to routing / binding, not netfilter
<f00b4r0>
and does that mean that I need to write rules for every exclusion case? that's combinatorial that can grow very quickly when this should be handled by the default "DROP" targets of each zone, shouldn't it?
<jow>
as I wrote eralier, zones are ingress interface bound
<jow>
in engish "allow any traffic destined for any address local to this router, received via interface X"
<f00b4r0>
well I don't follow: the "no forwarding" rule is a netfilter one, is it not?
<jow>
for netfilter this isn't forwarding
<jow>
forwarding is when egress interface != ingress interface
<f00b4r0>
ok, but then rp_filter should address this case?
<jow>
or rather when there's any egress interface
<jow>
input is every case where the routing vertict is to deliver the packet to the local system
<jow>
*verdict
<f00b4r0>
but at the end of the day, the packet comes from the dmz interface and is sent back from an IP belonging to the lan interface
<f00b4r0>
so why is rp_filter not working in that case?
<f00b4r0>
really must eat, bbiab. thanks for the help still
<jow>
I think rp_filter might not help after all, it validates the source ip, not the intended destination ip
<jow>
arp_filter 1 sounds like it would achive the desired effect
<jow>
or arp_ignore=2
<jow>
2 - reply only if the target IP address is local address configured on the incoming interface and both with the sender’s IP address are part from same subnet on this interface
<jow>
a complementary arp_announce=1 might make sense but is not crucial the way I understand it
<jow>
so arp_ignore=2 should prevent "cross talk" between source ip in subnet X and lokal destination ip subnet !X
<f00b4r0>
jow: so basically, that means that if you have N vlan interfaces that must all be segregrated from each other in terms of available services provided by the router, you need N*N individual rules? That seems fairly brain damaged
<jow>
did you try with a reboot after setting that in sysctl.conf or whatever?
<jow>
why N*N ?
<f00b4r0>
i flushed the neigh cache but I can try a reboot
<jow>
just one per interface
<jow>
or zone/realm
<f00b4r0>
because option src doesn't take a list?
<jow>
iif $in_infce daddr != $ip_of_in_iface drop
<f00b4r0>
and you need one rule per src iface for each iface
<jow>
yeah, so N
<jow>
not N*N
<f00b4r0>
iface A, B, C. rules: block from A to C; block from B to C; block from B to A; block from B to C; block from C to A; block from C to B
<f00b4r0>
N-1 * N-1
<jow>
if the objective is to simply allow attached subnets to only reach the router address in that subnet then you'll need one rule per subnet
<jow>
the lack of a "dest" option makes it an input rule instead of a forward one
<jow>
and it should reject any attempt to reach an ip address on the router that is not part of the captive subnet for traffic received via the captive interface
jeff___m has quit [Read error: Connection timed out]
<f00b4r0>
ok so test post reboot still doesn't work
<f00b4r0>
(with the above sysctls set)
<jow>
consider adding "option family ipv4" if you do not want this rule to cover ipv6 subnets as well
<jow>
yeah, so either we're completely misunderstanding the purpose of these sysctls or something else is broken there
<f00b4r0>
when you say "option dest_ip !captive", you mean it written exactly like that? I thought it took an IP value?
<jow>
yes
<f00b4r0>
ok
<f00b4r0>
will test
<f00b4r0>
and I think something else is broken
<jow>
fw4 will resolve names to related subnets
<jow>
and the '!' negates it
<f00b4r0>
*nod*
<f00b4r0>
I assume such rules must be at the very top of config
<jow>
so !captive should expand to a negation of all ip subnets reported by "ifstatus captive"
jeff___m has joined #openwrt-devel
<f00b4r0>
after zone definitions
<jow>
yeah
<jow>
at the very least they should appear before the port opening rules
<f00b4r0>
indeed that seems to work
<jow>
you could however also restrict the opening rules
<f00b4r0>
(i still have the sysclts enabled)
<jow>
by adding a "option dest_ip captive" to it
<f00b4r0>
that's error prone
<jow>
or whatever the zone name is
<f00b4r0>
the basic assumption is that cross talk should never occur
<f00b4r0>
(on a side note I'd think enabling some of these sysctls by default would be a good idea on a router system, provided that they actually work, which doesn't seem to be the case here)
<jow>
that would require extensive testing but in principle I agree
<jow>
the behaviour of arp_ignore=2 (if it actuall matches the description) seems like a desirable default
<f00b4r0>
indeed
<jow>
there's also a "fib" expression in nftables
<jow>
which generalizes the above suggested rule semantics without the need to mention specific IPs in the ruleset
<jow>
filter prerouting fib saddr . iif oif missing drop
<jow>
nvm, this is rp_filter smenatics, not arp_filter=2
jeff___m has quit [Remote host closed the connection]
jeff___m has joined #openwrt-devel
<jow>
but one take away for me: forget about rp_filter wrt. this scenario, rp_filter just ensures that there's any route leading back to the source ip of the inbound flow
<jow>
while we want to ensure that the dest ip of the ingress flow matches the (one of the) interface subnet(s) of the ingress interface
<f00b4r0>
*nod*
<f00b4r0>
I think the default behaviour is a fairly severe security hole. Especially for users unaware of the host model (even though *I* was aware, I clearly misunderstood the implications)
<jow>
I alwas took it something given, it's basically always been this way
<f00b4r0>
when you set zone rules which do not explicitely allow forwarding between zones, you certainly don't expect router services to be accessible "cross-zones"
<jow>
users are frequently bitten by this when they port scan their wan ip from lan to test their firewall policies
<jow>
and wonder why everything is unfiltered
<jow>
in an ideal world, the kernel would treat flows terminating locally but crossing subnet boundaries as forward and not input
<jow>
but afaik there's no such mechanism
<jow>
you'll always need some sort of additional measure (sysctls, nft filters, ...) to differentiate the "input" vs. "input but different subnet" case
<f00b4r0>
I suppose it makes sense in a server context. It certainly doesn't in a router one.
<jow>
if this lands we could build default nft rules that compare src and dest subnets in the input case
<jow>
maybe this is also a topic worth discussing in #netfilter
<jow>
not sure if there's a good solution yet that doesn ot require spelling out involved subnets
<f00b4r0>
it seems really weird that there isn't a knob to enforce the strong host model
<f00b4r0>
which AIUI is all that's really needed
<jow>
also there's IPv4
<jow>
all those sysctls (rp_filter, arp_*) only apply to IPv4
<jow>
not IPv6
<f00b4r0>
indeed
<f00b4r0>
hmm that firewall rule seems to have some side effects
<f00b4r0>
of the unwanted kind
<f00b4r0>
namely it breaks DHCP
<jow>
yeah it'll drop broadcast
<f00b4r0>
shit
<f00b4r0>
let's try restricting to udp/tcp
<f00b4r0>
which should be pretty much all that matters
<jow>
I'd suggest again to annotate your port-opening rules with a "option dest_ip $src_zone_name" - that might be the easiest and most robust fix (assuming the underlying default policy is reject or drop)
<f00b4r0>
it means I have to adjust the OpenWrt defaults, which so far I did need to
<f00b4r0>
did not*
<jow>
how so? I assumed those port popening rules are yours
<jow>
they're certainly not default
<f00b4r0>
oh you mean the captive zone port opening rules?
<jow>
yes
<f00b4r0>
hmm
<jow>
it will not prevent cross talk from lan to dmz
<f00b4r0>
this is suboptimal
<jow>
but it should prevent dmz to others
<f00b4r0>
it will also marginally increase firewall load
<f00b4r0>
and shouldn't be needed since these rules are supposed to only evaluate for the given zone
<f00b4r0>
but we've been through this already :)
<jow>
well they expand to `iifname $the_src_zones_interfaces`
<jow>
they will enforce no layer 3 subnet boundaries
<f00b4r0>
i wonder if that's not going to break the port 80 redirect
<f00b4r0>
(used for CPD detection)
<f00b4r0>
since i don't know what ip address the firewall redirects to behind the scenes
<f00b4r0>
also why would that work when the src_ip filter doesn't?
<jow>
the intention is to "open tcp/80 on the dmz-facing router ip address"
<jow>
while without a specific destination ip restriction, it becomes "open tcp/80 to any local router ip address, regardless of which interface or subnet it belongs to as long as it is local and not being routed elsewhere"
<jow>
is it counterintuitive? yes
<f00b4r0>
*sigh*
<f00b4r0>
ok so a bit of careful ordering actually "fixes" this
<f00b4r0>
moving the drop rule after redirect *and* after allowing DHCP appears to have no further ill effect
<jow>
yay
<f00b4r0>
this whole charade is a trap if there ever was one ;P
<f00b4r0>
so many ways to get this wrong.
<f00b4r0>
jow: thanks a bunch for the help anyway!
* f00b4r0
notes to make a lengthy note about all that in his linux firewalling cheat sheet
autkin has left #openwrt-devel [#openwrt-devel]
autkin has joined #openwrt-devel
<rmilecki>
Ansuel: was there any follow-up for the [PATCH 1/3] dt-bindings: nvmem: u-boot,env: Add support for u-boot,env-size