Page MenuHomeVyOS Platform
Create Task
Maniphest T6683

NAT64: can't add match fwmark value
Open, NormalPublicBUG
Actions

Description

I try to limit the traffic translated by NAT64.
For this I set a fwmark to relevant traffic using "policy route6" and then try to match the fwmark in the nat64 rule.

vyos@vyos# show nat64 source rule 10
+match {
+    mark 1064
+}
 source {
     prefix 64:ff9b::/96
 }
 translation {
 }
[edit]
vyos@vyos# commit
[ nat64 ]
VyOS had an issue completing a command.

Report time:      2024-08-27 19:42:56
Image version:    VyOS 1.5-rolling-202408231729
Release train:    current

Built by:         [email protected]
Built on:         Fri 23 Aug 2024 17:29 UTC
Build UUID:       1ce1f64b-ed7e-452f-b640-c2a6a5da8d4a
Build commit ID:  c5c6a1347c1533

Architecture:     x86_64
Boot via:         installed image
System type:      KVM guest

Hardware vendor:  QEMU
Hardware model:   Standard PC (Q35 + ICH9, 2009)
Hardware S/N:
Hardware UUID:    ba602e12-5842-4508-bfb9-22720c542a94

Traceback (most recent call last):
  File "/usr/libexec/vyos/conf_mode/nat64.py", line 220, in <module>
    verify(c)
  File "/usr/libexec/vyos/conf_mode/nat64.py", line 73, in verify
    if is_node_changed(config, base_src + [f"instance-{num}", "mode"]):
                       ^^^^^^
NameError: name 'config' is not defined

[[nat64]] failed
Commit failed

Details

Difficulty level
Unknown (require assessment)
Version
VyOS 1.5-rolling-202408231729
Why the issue appeared?
Will be filled on close
Is it a breaking change?
Unspecified (possibly destroys the router)
Issue type
Bug (incorrect behavior)

Event Timeline

ruffy91 created this task.Tue, Aug 27, 7:55 PM
pasik subscribed.Tue, Aug 27, 8:25 PM
Viacheslav triaged this task as Normal priority.Wed, Aug 28, 6:28 AM
Viacheslav subscribed.Tue, Sep 3, 7:32 AM

Try to delete whole nat64 config and re-configure again (not change)
Also I do not see the translation address.
The comment says that changing an instance fails https://github.com/vyos/vyos-1x/blob/c78c5bd7e65b19e0e50ef6944dc74fb33660ff71/src/conf_mode/nat64.py#L71-L74

ruffy91 added a comment.EditedTue, Sep 3, 6:18 PM

This made it possible to commit the change
Additionally I set a pbr rule like this:

vyos@vyos# show policy route6
 route6 pbr6 {
     interface bond0.1001
     interface bond0.1002
     interface bond0.1003
     rule 10 {
         destination {
             address 64:ff9b::/96
         }
         set {
             mark 1064
         }
     }
 }

This should only mark traffic going to the nat64 prefix.
however as far as I can see all traffic is still going through/to jool and the "match mark" is ignored.
Where would I be able to verify if it has been set in the backend configs?

As seen from "jool -i instance-10 stats display", JSTAT_POOL6_MISMATCH increases even when traffic is sent to non nat64 destinations, which means that jool still tries to translate it.

Causa translation address:
I only have a single dynamic public WAN IP (VDSL/G.Fast with DHCP or PPPoE). I cannot use it for nat64 as it is changing from time to time and if I hardcode it in the config it will fail eventually. However having a empty pool4 is perfectly fine for this: https://nicmx.github.io/Jool/en/usr-flags-pool4.html#empty-pool4 it uses port 61001-65535 on the outgoing interfaces universal scoped address.

However I would like to restrict traffic going to nat64 which is why I want to mark it with pbr and then only send it to nat64 if it matches the mark.

dmbaturin added a project: Restricted Project.Sun, Sep 15, 5:03 PM
ruffy91 added a comment.EditedWed, Sep 18, 6:07 PM

So I investigated further and it is like this in jool:
mark is only used to select between pool4 instances.

As a consequence it should be like this:

  • set mark is only usable when translation has been defined -> this should be restricted when committing a wrong config
  • when setting translations with mark there is always also an implicit translation for no mark/mark 0 with the empty translation address, which uses the universal scoped address on the outgoing interface on port 61001-65534 -> this rule should probably automatically be added in the config as it cannot be suppressed. so that it is clear to the user that the rule exists and that corresponding traffic will be translated to the interface address and bypasses forward firewall rules.

This could also be improved by switching to iptables jool: https://www.jool.mx/en/intro-jool.html#iptables
This would allow to decide in PREROUTING which traffic to translate instead of translating all traffic on the configured interfaces.