You’re doing it wrong or putting it in the wrong place. Hard to tell from the example you gave. 
There’s this useful tip from @InkblotAdmirer earlier in the thread for debugging.
1 Like
Yea, i can see your thoughts being a possibility especially the "putting it in the wrong place" statement. I can see how the rule list is set up how easy it would be to confuse placement.
I am assuming if i was using the webui to open the port, then it should in theory be placing the rule in the correct spot. This is using the nftable layout.
Why don’t you show us the rule from /etc/config/firewall and the resulting rule from nft list ruleset? I don’t think the LuCI interface is geared toward IPv6 port forwards (NAT6). You might need to manually insert a family option in your rule.
As per my original question, I am merely trying to open a port. It is intended to access a local service on the router over ipv6. Wan side. So i used the webui to set up such a rule on firewall traffic page. I chose ipv6 as the family.
The problem is, even after opening the port, it is not visibly open. I run a scanner on the port and it comes back unreachable.
Did you confirm the rule is being hit in the input_wan chain by observing the counters? Is the service on the router even listening on a IPv6 address and udp port in netstat -nlup?
Dave,
Here is what I can tell,
netstat -nlp | grep 51821
udp 0 0 0.0.0.0:51821 0.0.0.0:* -
udp 0 0 :::51821 :::* -
it is showing it is listening at udp port 51821.
I have the port listed as open for nftables. I did split rules where one ipv4 family rule opens the corresponding ipv4 port, and I did a separate ipv6 family rule that opens the udp port. I am able to see the counter for the ipv4 family rule go up. The counter for the ipv6 rule never goes up. I even disable the ipv4 rule and leave only the ipv6 rule. Still the counter never goes up. I even do a port scan, and I results that tell me the port is unresponsive. Is there something I may need to do to the sysctl that I might be missing
Setup the trace and see what happens to the traffic, since it doesn’t seem to reach the input chain.
nft add rule inet fw4 mangle_prerouting meta nfproto ipv6 udp dport 51821 meta nftrace set 1
nft monitor trace
https://wiki.nftables.org/wiki-nftables/index.php/Ruleset_debug/tracing
1 Like
I followed your suggestion. Something externally (or internally -nftables) is inhibiting a connection from being made over ipv6 port. Very weird. I see no ipv6 attempts to make connection over that port. No accepted traffic flows. No traffic flows at all.
When I test the port over ipv4, then there is no issues. All traffic flows are allowed and accepted.
I am wondering if there is a bug or something. Weird.
Time to scrutinize your testing methodology and IPv6 configuration.
Not much I can tell from the actual nftables since i deleted any custom chains for the actual testing purposes. I used just the default firewall. I added the port opening using the traffic rules tabs of the firewall webui page. I scanned the port with port scanning tools to see if the port was open, it said unresponsive. I then used your diagnosting post trace, saw the only port getting traffic was the ipv4 version of the rule. The ipv6 rule never recieved any ipv6 traffic eventhough i was attempting to access it from an external connection over ipv6. As far as i can tell, ipv6 port opening is not working correct and i have no way to troubleshoot it past what i have already tried.
That is what made me wonder earlier, is there any other kernel level variables that may be at play. For example, sysctl options that need to be changed.
I even started to scrutinize the imcp6 to verify that the firewall was not being too strict.
You should still be able to see the inbound udp traffic on the WAN interface with tcpdump if it’s even reaching your router (which I doubt). That’s why I think you need to describe your test in detail and which IPv6 address you use.
On the other hand, this has morphed beyond a tip or trick for firewall4/nftables and should probably be its own thread.
I suppose you are right. I guess we will just have to wait until another person finds the same problem. This is definitely beyond my technical understandings. These were rules that worked in fw3. I guess they just don't work with fw4. ( i added more pictures of my method. )
[Edit]
@dave14305
It turns out the DDNS service provider was presenting itself as ipv4 first. Switching the DDNS service to only ipv6 resolved the issue.
Destination zone should be Input, correct?
Here is a good place to answer that question.
I was providing you a suggestion to the problem. Unless I've mistaken, your screenshot doesn't specify Input.
It seems you specified "Forward" accidentally.
Because the way the default nftables are setup, it forwards from the wan side of rules. I agree, it is weird, but that is how the default tables read it. I personally didn't select forward, it was the only choice.
[edit]
I see what happen, it selected forward because I put the forward in for the destination. If I had left it at input, it would have been input.
Oddly enough, the forward rule works as well, but I expects it exposes more than just the device himself.
Thanks a lot! Your example for ipv4 has been working successfully for me for many months. ipv6 requires slight adjustment:
chain mangle_ttl_out {
type filter hook postrouting priority mangle;
meta nfproto ipv4 oifname wwan0 ip ttl set 64 comment "!fw4: IPv4 - Set output TTL on WWAN"
meta nfproto ipv6 oifname wwan0 ip6 hoplimit set 64 comment "!fw4: IPv6 - Set output hoplimit on WWAN"
}
chain mangle_ttl_in {
type filter hook prerouting priority mangle;
meta nfproto ipv4 iifname wwan0 ip ttl 1-9 ip ttl set 10 comment "!fw4: IPv4 - Increase incoming TTL on WWAN"
meta nfproto ipv6 iifname wwan0 ip6 hoplimit 1-9 ip6 hoplimit set 10 "!fw4: IPv6 - Increase incoming hoplimit on WWAN"
}
1 Like
Hey community! I think by now this thread has run its course. Most of the replies these days should actually be raised as new, focused topics for better visibility and on-topic resolutions.
Please open additional forum topics as needed for true issues with FW4 going forward. Thanks to all who dropped great tips and tricks in here over the past few months!
1 Like
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.