Changes can be seen here: https://github.com/c-po/vyos-1x/commits/ssh-rewrite

oh. since this was still open and seemed to have died I assumed there wasn't any image for GCE yet. Well that's good - is the image public?

It's still missing cloud-init part and google agent (not recall how called that piece of software)
otherwise it's working on gcp and azure

I've started to try to convert the official ansible playbooks used to build the AMI for use on building a GCE image. Hopefully I'll have something working this weekend and can post here for some wider testing. I'm starting from the method here: https://github.com/vyos/build-ami Not the method mentioned earlier in this task using Packer.

With install_routes disabled so that VTI works I've managed to recreate the route for prefix based tunnels using iproute2.
ex: ip route add <remote_prefix> via <default_route> dev <ipsec_interface> table 220 proto static src <local_prefix_addr>
It seems we already have all the required information to manually create the routes outside of strongswan.
This would mean that VTI and other IPSec tunnels could co-exist.

For IP address or network checking I tried Python ipaddress package. https://github.com/c-po/vyos-1x/blob/current/src/conf-mode/vyos-config-ntp.py#L22

@c-po install_routes = 0 can be added to any strongswan.conf (/etc/strongswan.conf, /etc/strongswan.d/*) file as long as it's inside the charon section I believe.

@Watcher7 must this always be added into /etc/strongswan.d/charon_vti.conf?

Looks very good!

Tested on 1.2.0-rolling

I think we can use Debian jessie package for 1.2.0-rolling. But for 1.1, we have to build special version, because there is no upstream package.

Feedback welcome: https://github.com/c-po/vyos-1x/tree/t623-ntp-rewrite

in theory we need to use hostnames there along with ips

@dmbaturin @UnicronNL @syncer Is there any reason why NTP should be restarted when DNS changes? https://github.com/vyos/vyatta-cfg-system/blob/current/scripts/system/vyatta_update_resolv.pl#L232-L237

Integrated in latest rolling release. Thanks for reporting the problem and solution.

@syncer my bad ... then we have to integrate the fixes manually or better, identify why we have to use a special version and decide if this is still necessary. A lot of patches from the past have been removed in the latest Kernel update, too which were no longer necessary.

@c-po vyatta-quagga is our package

c-po, does it mean that the fix will be included in an upcoming 1.1 release and in 1.2.0 when released ?

The peer-address option doesn't work quite well in keepalived 1.2.x from jessie. VRRP transition works, but then it goes into an endless loop of sending an ARP who-has request for checking availability of the virtual address.

Thanks for sharing. Debian security updates get automatically pulled in every night diring creation of the rolling release ISO.

From a 1.2 build last night:

For VyOS 1.2 please see T582. We use Debians upstream open-vm-tools package as of this change.

There is a vyos-open-vm-tools git repo. The 'make iso' installs that package. In the process of building the iso (Setting up open-vm-tools-dkms) it tries to rebuild a kernel module. If we don't rebuild that there are two issues:

We already have set system ntp allow-clients address 172.16.0.0/12 which can become a brother to a new command named set system ntp listen-on.

@carl.byington I'm using this snipped as foo.sh to build the kernel:

I confirmed qemu-ga works correctly on libvirt with vagrant-libvirt.

Sounds reasonable ... but I have nothing to test.

@c-po Looks like Debian has it for all platforms that support KVM, including ARM (though, oddly, not Aarch64). Perhaps we should move it from the x86 package list to vyos-world or another platform-independent place at some later point.

Will be in the next rolling version.

Scrolling back in show log I see some additional lines:

I am running several Vyos instances on Hyper-V and can confirm that 1.1.7 and 1.1.8 are running without issues.
For memory we use 512MB and never have any issues.

Fixed in latest ISO

Working again...

As interim solution I created https://ci.vyos.net/job/xl2tpd and forked xl2tpd to github.com/vyos (containing a backported patch from me).

As interim solution I created https://ci.vyos.net/job/xl2tpd and forked xl2tpd to github.com/vyos (containing a backported patch from me).

Hmm..
I added RAM to VM (256MB->300MB) and booted without error.
Tested on vyos-1.2.0-rolling+201804200337

I have updated to V1.2.0-rolling+201804200337. After that the configuration node 'service dns forwarding' has disappeared from the config tree.
I reconfigured this and the 'listen on'-part is ok now. Thanks for fixing this one Christian.

@syncer I vote for "Wontfix"

VyOS 1.1.8 is not supported on Hyper-V (lack of drivers inside the Kernel).
You should start of by getting a copy of VyOS 1.2.0+rolling.

Fixed in vyos-1x ... new ISO will be available shortly.

Fixed in vyos-1x ... new ISO will be available shortly.

I just tried. The config tree looks like before:

With 2 and more interfaces same problem:
Config:

[edit]
ec@vyos# show service broadcast-relay
+id 1 {
+    interface vtun0
+    interface vtun1
+    interface eth0
+    port 65000
+}

Error:

ec@vyos# commit
[ service broadcast-relay id 1 ]
Traceback (most recent call last):
  File "/opt/vyatta/sbin/vyos-config-bcast-relay.py", line 118, in <module>
    c = get_config()
  File "/opt/vyatta/sbin/vyos-config-bcast-relay.py", line 45, in get_config
    intfs_names=intfs_names.replace("'", "")
AttributeError: 'list' object has no attribute 'replace'

What happens if you do: delete service dns forwarding

This is essentially a implementation and configuration bug.