@c-po, Ahh! :)
You could compile the vyos/vyos-strongswan github repo, but a image is the best to test with.
i had issues with just apply'ing strongswan patches. (strongswan crashed and hung my device when restarting services)
The latest image created is http://dev.packages.vyos.net/tmp/vyos-dmvpn-0820.iso created by @dmbaturin on 21.aug ..
after that is installed change this:

@c-po did you manage to test disabling cisco-unity in a mixed vyos/cisco environment?

I think the best is to use the default from the protocoll.. (autogenerate port if none is specified) 51820 could be a completion help option on the listen-port command

@c-po, As far as i can see it does not distinguish between server and client mode.
From the manual:

@hagbard i actually haven't tried it in real life, only looked at the command syntax'es.

@hagbard
Thats much better! :D
"peer" in "peer-pubkey" is also a bit redundant, just call it "pubkey"

as far as i can see this should be possible. it looks like the cisco_unity plugin is used to automatically install routes and other things that is not needed when we are running inside a gre tunnel as is done in dmvpn. but i have not looked into the unity plugins code so i'm not completely sure.

I think that using the key as a peer identifier makes the configuration unreadable its quite hard to identify each peer when you have more than one of them. I would like to se the peer identifier to be a name/description instead and that key is added as a leafNode instead...

after @dmbaturin rolled a new image with patched opennhrp script and swanctl code dmvpn works as expected when manually disabling the cisco_unity plugin in /etc/strongswan.d/charon/unity.conf .

I got dmvpn up and running. here is the list of things to do:

To do the same example as it is running in the current-rolling devel i have reverted my patch:

The current implementation of the config interpretor does not work that way.
It is correct that your config script needs to take account of all added/removed config within your tagNode, but the script will actually run once for every tagNode instance you define.
let me take an easy example:

after intense searching i came across this:

i will try to do some work on implementing this if its possible to get it upstream if i succeed?

in my latest PR i've also added a rewrite of "show host *" in show-host.xml. this rewrite does not need any wrapper scripts.

@dmbaturin ahh, my fault.

When trying to migrate " show login " and "show history" the new syntax scripts fails to retrieve information from the current user.
The reason is that everything that is executed by the new syntax scripts are wrapped inside sudo.
(from build-command-op-templates line 140: node_def += "run: sudo sh -c \"{0}\"\n".format(command.text) . )

i've added all files i have finished now.
i also have nearly completed files for show system and show log, but they need some tweeking and completion/op_mode scripts to be finished.

Finished so far:

• reboot
• poweroff
• show arp
• show bridge
• show date
• show disk
• show configuration
• show hardware
• show raid
• show users