https://github.com/vyos/vyos-1x/pull/2871

Yeah I'm migrating everything to 1.4, so I don't need this.

Just putting together a PR for vyos-build to integrate it.

In T5835#172989, @dylanneild wrote:

@sdev Quick question on this issue.

In order to make miniupnpd work with the VyOS firewall as it is presently configured (dedicated ip and ip6 tables), I've had to make a fork of miniupnpd. This is due to the miniupnpd folks effectively declaring that inet tables are "the way it's all going" and effectively removing any ip and ip6 table use in the daemon.

I've tested with the stock miniupnpd to try to implement all rules in a single inet chain, but this creates a problem where, per my comment above, the default-action drop steps on the miniupnpd table, and I'm back to square one.

Using my fork of miniupnpd, I've tested extensively and can see everything working with VyOS IPv4. Rules can be added, checked, and removed without issue. Secure mode works, etc. The fork itself is a fairly small patch; it just reverts some calls in the nftables code to use NFTPROTO_IPV4 rather than NFPROTO_INET for filter and NAT rule changes so as to target the correct table variants.

I can test IPv6 pinhole, which I think can still work using the ip6 tables as-is (my patch doesn't change this at all), but I'd have to setup some tunnelling to validate it as I don't have native IPv6 at my house.

So, my question is: how open is VyOS to using forks of packages as opposed to just pulling them in from Debian?

If not at all, this patch may be at a dead-end unless someone has a clean way to avoid the default-action drop using only priorities (the nftables documentation maintains this can't work)? I considered using meta marking but that would also involve patching miniupnpd to apply the marks to rules matched by it's firewall additions and then modifying VyOS to not apply the default drop when the mark is matched; but that seems a lot less clean.

+1 for this to further VyOS use in service provider networks, and hopefully as a foundation for providing Metro Ethernet capabilities.

@trae32566 Thanks for confirming

It could be priority https://github.com/vyos/vyos-1x/pull/2703 or another fix. I can't say exactly.

dhclient just straight up doesn't work with raw-ip, so there isn't really an event that I can imagine it could trigger off. Even if there was I don't know what we'd even do, I don't think it would be good to have the dhclient hooks be the thing that gets the IP from mmcli -m 0 -b 2 and configures all the associated bits if we went that way.
The wwan0 interface doesn't have a MAC address so dhclient doesn't know what to do

set service ntp leap-second [ignore|smear|system|timezone]

@Perihelion done

Yes, this is fixed.

How will it looks like if we have for example 100.64.0.0/24
R1 should announce 100.64.0.0/25
Will we add 128 entries or there better solution?

Needs to check if it works for 1.5

Hi @Viacheslav I just upgraded that router from 1.5-rolling-202312191154 to 1.5-rolling-202401200023 and it now seems to successfully boot with peth0 for the dynamic dns service address.

@c-po Can we backport this to sagitta?

Did you try those?

vyos@r4:~$ ls /usr/share/snmp/mibs/ | grep -i "TC\."
HCNUM-TC.txt
IPV6-TC.txt
NET-SNMP-TC.txt
SNMPv2-TC.txt
vyos@r4:~$

PR https://github.com/vyos/vyos-build/pull/488

@Viacheslav I am not Python developer. Settings this up with tests will take much time for me.

PR https://github.com/vyos/vyos-1x/pull/2862

Merged