@moepman please checkout the next rolling ISO - at least it works as expected in my LAB
Aug 1 2020
@thomas-mangin Maybe it's better to discuss it here
@thomas-mangin As mentioned in my comments, I refer to the configuration structure of H3C. In the original command structure, nptv6 does not support the division of SNAT and DNAT. In order to implement nat66, I separated it for the following reasons:
When connected via SSH to the router in question every command is run inside the VRF, thus a regular add system image will already run in the VRF. Nevertheless it would make sense to execute the command from another VRF.
It is hoped that this implementation can make the prefix translation work again. Refer to the relevant operation of H3C equipment and fully support nat66
I don't use this kind of tool to test his nftables policy, but I'm used to testing it by manually configuring nftables and replacing my nftables template file with that of the vyos system. Vyos did not report errors during its build configuration.
@c-po The related nftables policy in the local environment test did not find syntax problems, only need to be tested to verify the effectiveness of the function, so I call it experimental support.
I ask myself if it not would make more sense to get the prefix translation working again and then add new features here?
@c-po Can you take a look at this PR for me?
@c-po Can you take a look at this PR for me? At present, the command implementation of ndptool send has been canceled
This PR will provide experimental nat66 support, which needs to be tested
Jul 31 2020
@SrividyaA I just upgraded to the latest rolling image (1.3-rolling-202007311330) and I can still reproduce the exact same issue with the config above. Here's output from show log.
Will do, working on it...let you know as soon as I finished this weekend.
Maybe I just didn't encounter it. In short, please try the latest version first. If this problem still exists, please provide the detailed configuration and environment information of the error to facilitate the recurrence and troubleshooting of community members
Please try the latest version of the image, I have not encountered similar problems at present
Jack, I' am aware regarding SSH protocol to manage it remotely, I work with, but the point is:
I don't understand what you mean. If you use the SSH protocol remotely, you should be able to automatically resume the connection within the allowable time of the protocol. However, if the time is exceeded, you may need to wait for the network connection to recover and reopen the SSH connection.
And there are some PR pending on that exact code ..
If anything this code could/should be extracted in an internal library and then a tool created to replace what we have so the behaviour is consistent in both cases.
There is now some python XML code to parse the XML. m4 is not a nice tool. If better pre-processing is required, which I would not argue for, please explain the issue you are trying to solve.
@c-po According to H3C, the relevant operations are as follows:
@c-po According to H3C and the third-party information on the Internet, NPT is also called nat66. Nat66 is actually the SNAT and DNAT implementation of IPv6, and implements 1-to-1 mapping and prefix address translation. Since there is no separate configuration directory for these two directions in the configuration, this draft implements two directions. Tomorrow, we will try to modify the configuration path according to the document of H3C device, add the diff of the draft, and then propose Submit merger request.
@c-po It has been revised as follows:
Well I would just have plumbed up the commands locally before doing any templating. Please keep us updated if it works.
I didn't get any specific help. The modified pudding was set up based on the trial and limited third-party data here, and it needs to be fully tested.
@c-po This is a simple draft of my current implementation of NPT. At present, I haven't tested it, and I haven't applied for merger. I can send it here for some discussion.
Jul 30 2020
No I didn't, sorry. I'll test it and see :)
Have you tested the latest codebase? It more or less follows your design for the member ports.
This is not enough, bridge and bond members also didn't get IPv6 link-locals in the previous implementation. To have them is incorrect and a security risk.
The last bug mentioned could be due to: https://phabricator.vyos.net/T2746
TSM support has been droppen in 1.3
related to T1699
@Merijn Have such problems been repeated?
Jul 29 2020
The problem is that vti interfaces are only created when VPN is configured this is done very late with priority 900. VXLAN, bridge etc (also in 1.2) use a lower priority. The only solution will be that the vti interface is added imediately and then later bound to the VPN.
The issue did not reproduce neither in 1.2.5 nor in 1.3 version.
Try in the new release and re-open the ticket if any new information appeared.
@olofl I can't confirm this bug int the 1.2.5 LTS version.
I can't confirm this bug.
vyos@vyos# set vpn ipsec ike-group IKEv2_DEFAULT mobike disable  vyos@vyos# commit  vyos@vyos# run show version Version: VyOS 1.2.5 Built by: Sentrium S.L. Built on: Sun 12 Apr 2020 15:18 UTC Build UUID: 1695c660-d785-4b16-a54b-66d6a02ea24f Build Commit ID: 48cc9fc46569e6
That configuration does not work in 1.2.5 either - we probably should exclude vti from VXLAN source interface?
In latest rolling releases this will break b/c of:
@c-po In my vyos, the following commands run successfully, and the rule settings are normal, but the rules are not tested to be effective and correct. For reference only, if I have time, I will open the eve ng simulation environment.
@c-po Since I can't find a suitable place to use ndptool send, in this task list, cancel the implementation of this function. If necessary, the user can run it directly from the command, and now submit the correction. If possible, please re audit pr
What is here:
Although this document may not be a direct help, it may help us understand how to set up IPv6 NAT for nftables?