If you manually partition you need to keep in mind 2 things.
the filesystem label needs to be "persistence" (mkfs.ext4 < device > -L persistence)
and in the root of the filesystem you must create a persistence.conf file containing "/ union"
(echo "/ union" > /persistence.conf) on your partition meat for vyos.

@bjtangseng so changing that remote_ts = 0.0.0.0/0[gre] fixed it right?

@bjtangseng
On the HUB, can you change in /etc/swanctl/swanctl.conf
remote_ts = dynamic[gre] to remote_ts = 0.0.0.0/0[gre]

can you do:
sudo swanctl --list-sas

@bjtangseng, Ah that is the problem. I do not know if there is an option allow any network, have to do some research.

@bjtangseng,
Does your nat address change everytime?

can you put log from hub?
ipsec log

@bjtangseng
I think you replaced the wrong ip in the swanctl.conf

@bjtangseng Can you post the output, than i can maybe look and mod things.

@bjtangseng thanks!

@bjtangseng The spoke, and do not reboot.
make sure hub is up and do changes mentioned in previous post on the spoke (no reboot)
and post the output of:

@bjtangseng
can you please edit your swanctl.conf file and put the local_ts to 115.60.62.155/32[gre] ( local_ts = 115.60.62.155/32[gre] )
after editing swanctl please run:
sudo swanctl -q
then please check if you can connect with:
sudo swanctl -i -c dmvpn -S 100.64.161.96 -R 116.90.86.181 -l 2
or:
sudo swanctl -i -c dmvpn -S 0.0.0.0 -R 116.90.86.181 -l 2

@bjtangseng could you try with IKEv2 on both hub and spoke?
set vpn ipsec ike-group IKE-HUB key-exchange ikev2 for hub
set vpn ipsec ike-group IKE-SPOKE key-exchange ikev2 for spoke.

@bjtangseng This is definitely a NAT issue, if i change the local_ts = dynamic[gre] in /etc/swanctl/swanctl.conf to local_ts = *.*.*.*/32[gre] i can replicate the error you get.

@bjtangseng I do not know if dmvpn was in rc.10.
Can you please try the same in the last roling release?

added the patch! thanks

@m.tremer added the patch, thanks... was under the impression cloud-init added the user as it is stated as default user, but clearly it does not.

Do you also create the iso yourself or dowload it?
In 1.2 we will be using cloud-init and the ec2 init script was removed.

@vtsingaras I merged it in to our repo.
@syncer i see we have no crux branch for pmacct i slacked @dmbaturin

@syncer i added a branch in vyos-build, after testing, do you think we can merge to current/crux and update the live-build package on the build server?

@commo @Raeven I updated the kernel to support the filesystems. But what @syncer mentioned 'win32diskimager' is a better tool for 1.2 as it is hybrid-iso which works if you directly write the iso to usb.

@syncer If we use kernel 4.19 driver version for ethernet is DRV_VERSION "5.1.0-k"
Also cpu should be supported without enabling something i guess.

Will mod the script to update rate on the fly.
vyos@vyos:~$ stty -F /dev/ttyS0 115200 cstopb

@kroy
If you would like to test:
git clone https://github.com/vyos/vyos-build.git
cd vyos-build
git checkout current-uefi
docker build -t vyos-builder .
docker run -it --privileged -v /HOST_PATH_OF_VYOS_BUILD_REPO:/vyos -w="/vyos" vyos-builder bash
./configure
make iso

@kroy what kernel is it now you use? I updated the kernel 4.14.75 and 4.19.0
https://github.com/vyos/vyos-kernel/commit/32f3f5caaec8bff6f372ab22801cfaaa30a766cd

@syncer will check @kroy thanks a bunch!!

@commo How did you prepare the usb drive?
On which os, and what tools did you use?

This was fixed some time ago.
https://github.com/vyos/vyos-strongswan/commit/2cfa2c5f85babbfae11898888d6e8c7ca99cdeb5#diff-ab17f7fac35ebad14feb31b720eba1b0R173

@vtsingaras I see it is merged in upstream, try to merge in vyos asap.

@Watcher7 Ah i see, was confused... tnx

do you mean like:

set protocols static table 10 route 192.168.0.0/24 next-hop 192.168.0.1 interface ethx

If so could you please create a new task for creating new syntax?

@Watcher7 I do not really understand what you mean, can you share your configs or a way to reproduce and elaborate a bit more?

Found that already :)

Haha tnx!

image vyos-1.2.0-rolling+201807301123-amd64.iso

@hagbard and then install the packages on that. (download and install)

@syncer he means the edgOs one :) package i build are only the wire guard tools and kernel module. Those packages are good.

@hagbard http://dev.packages.vyos.net/repositories/current/vyos/pool/main/w/wireguard/
here are the packages

@hagbard I have created the wireguard package https://github.com/vyos/vyos-wireguard

These are the pachtes i took from old vyatta, seems like you got them all.
https://github.com/vyos/vyos-kernel/commit/4c8de1009e13a978bacd5066024d194be983ecbd
https://github.com/vyos/vyos-kernel/commit/e8b8c70f0e20666824f33083d7aa76a3f1a1f6f5
https://github.com/vyos/vyos-kernel/commit/fc58d4a339537765585855a9b793b953c7c984f1
https://github.com/vyos/vyos-kernel/commit/e59dab9f2985869cfdbf9b74cb5c8034c218707b

fixed this couple of days ago.

Nice!

package is now in the vyos repo and used in images

support added,
only need Jenkis up to build te kernel.
https://github.com/vyos/vyos-kernel/commit/b72a65de9fd1c68c8d371152cfdcbc85d2b0dbd9

@syncer This tasked can be moved to finished, i do not have the rights.

What to so with this task, requests were closed.

@dmbaturin , why you reverted?

https://github.com/vyos/vyos-build/commit/e5259ccb17e93e110d1dcdeb98f4dc1b9d1df192
This seems to have done the trick thanks.

+1 removal

I added new pmacct package (https://github.com/vyos/pmacct/tree/current) but now we also need to update vyatta-netflow package.

https://github.com/vyos/vyatta-op-dhcp-server/commit/b3d40f53c12ec5639c6f399206121833a43014c3

https://github.com/vyos/build-iso/commit/51b1f8faf84b8071c8413af1baa76d976528c440

added to helium branch

added jessie one. https://github.com/vyos/dnsmasq
need to test in 1.1.8 rc1

@higebu @syncer squeeze is added to ci, only there is no repo to upload.

@dmbaturin @syncer Where can i find the lithium repo?

@dmbaturin @syncer Where can i find the lithium repo?

In T379#7550, @dmbaturin wrote:

And now that I've actually looked into it... ;)

There are some bad practices that I think should be changed before we call it complete as well.

First, now that the Python configuration library and the templates convertor work, can we stop adding new Perl code? Those scripts are short at least.
There are some very good reasons to do that as well. For example, now that we are using systemd, why should we have start-stop-daemon? We should never had it right in Perl code to begin with.
Second, I'm strongly against mixing VyOS configuration code with applications it configures. Let's move that out of this, and if we are going to move the configuration code to vyos-1x package, it will come naturally. We can merge the bcast-relay and mDNS repeater into one package perhaps.

The features are appreciated, but let's add them in a fashion that will make VyOS easier to maintain, not harder.

merged to lithium

@syncer can we close this task? see @higebu fix..