But it seems not to work. As far as i found out it is due to fw4 which does not support iptables rules like this.
How can i manage, that my packages get an higher ttl values so that the survive getting out of the subnet?
Best Benjamin.
As far is I got to know, nftables does not yet support --ttl-inc ...
I just pointed you where unimplemented inc-ttl is to be found. It was never part of generated ruleset, just that with fw3 single include is more prominent.
chain .... {
hook ....
# retrieve that from `fw4 print` or `nft list ruleset`
( maybe ... iif $wan_devices,$iot_devices ) fib daddr type multicast ip ttl 1 ip ttl set 2
}
Okay. It is still a little obscure to me how such a rule should look like in /etc/nftable.d/*.ntf
Could you give me a a sample?
my devices are from the subnets are:
br-IoT and br-home
…And what do you mean by:
You can create value map to imitate inc-ttl. You need to inc-ttl in forward table, because unaltered input packets are good with ttl1
chain mangle_prerouting {
type filter hook prerouting priority mangle; policy accept;
meta nfproto ipv4 meta l4proto udp iifname { "br-IoT", "br-home"} fib daddr type multicast ip ttl 1 counter ip ttl set 2
}
Thanks for the help! I put the rules and restarted the firewall (and the router to be sure).
How can i check if the new rules are working (i still cannot see the dlna device cross subnets...)
By the way…here is my smcroute.conf
root@OpenWrt:~# cat /etc/smcroute.conf
# Enable bridge interfaces for smcroute use
br-IoT enable # IoT Devices
br-home enable # Server (DMZ)
# Allowed routing for IPv4
mgroup from br-home source 192.168.xx.xx group 239.255.255.250
mroute from br-home source 192.168.xx.xx group 239.255.255.250 to br-IoT
mgroup from br-IoT group 239.255.255.250
mroute from br-IoT group 239.255.255.250 to br-home
And my firewall rules:
config zone 'IoT'
option name 'IoT'
option network 'IoT'
option input 'REJECT'
option output 'ACCEPT'
option forward 'REJECT'
list device 'br-IoT'
config forwarding 'IoT_wan'
option src 'IoT'
option dest 'wan'
config rule 'IoT_dns'
option name 'Allow-DNS-IoT'
option src 'IoT'
option dest_port '53'
option proto 'tcp udp'
option target 'ACCEPT'
config rule 'IoT_dhcp'
option name 'Allow-DHCP-IoT'
option src 'IoT'
option dest_port '67 68'
option proto 'udp'
option family 'ipv4'
option target 'ACCEPT'
config forwarding
option src 'IoT'
option dest 'DMZ'
config forwarding
option src 'DMZ'
option dest 'IoT'
config rule
option name 'allow_iot_dmz_ssdp'
option dest_port '1900'
option src 'IoT'
option dest 'DMZ'
option target 'ACCEPT'
list proto 'udp'
list dest_ip '239.255.255.250'
config rule
option name 'allow_IoT_lan_ssdp'
option dest_port '1900'
option dest 'lan'
option target 'ACCEPT'
list proto 'udp'
option src 'IoT'
list dest_ip '239.255.255.250'
config rule
option name 'allow_dmz_iot_ssdp'
option dest_port '1900'
option src 'DMZ'
option dest 'IoT'
option target 'ACCEPT'
list proto 'udp'
list dest_ip '239.255.255.250'
config rule
option name 'allow_dmz_lan_ssdp'
option dest_port '1900'
option src 'DMZ'
option dest 'lan'
option target 'ACCEPT'
list proto 'udp'
list dest_ip '239.255.255.250'
config rule
option name 'allow_iot_dmz_ssdp_1800'
option dest_port '1800'
option src 'IoT'
option dest 'DMZ'
option target 'ACCEPT'
list proto 'udp'
list dest_ip '239.255.255.250'
config rule
option name 'allow_IoT_lan_ssdp_1800'
option dest_port '1800'
option dest 'lan'
option target 'ACCEPT'
list proto 'udp'
option src 'IoT'
list dest_ip '239.255.255.250'
config rule
option name 'allow_dmz_iot_ssdp_1800'
option dest_port '1800'
option src 'DMZ'
option dest 'IoT'
option target 'ACCEPT'
list proto 'udp'
list dest_ip '239.255.255.250'
config rule
option name 'allow_dmz_lan_ssdp_1800'
option dest_port '1800'
option src 'DMZ'
option dest 'lan'
option target 'ACCEPT'
list proto 'udp'
list dest_ip '239.255.255.250'
config rule
option name 'allow_iot_srv_nas_dlna_http'
option src 'IoT'
option dest 'DMZ'
list dest_ip '192.168.xx.xx'
option target 'ACCEPT'
list proto 'tcp'
option dest_port 'MYPORT'
br-home is a seperated into vlans and the device for the DMZ where the server is and the subnet (DMZ) which should receive the ssdp packages from the dlna device, which is in the IoT subnet.Hopefully this makes sense...
I translated ttl+1 rule, for the rest "i dont know" , as much as I set up multicast i did it with minimal interceptions in openwrt side - ie bridge, same subnet etc.
SSDP is http-in-udp , response will come from target IP directly, it is a tough work with tcpsump as the related responses in no way grip into conntrack states.
