User Details
- User Since
- Jul 20 2016, 7:56 AM (451 w, 2 d)
Aug 2 2017
Jul 26 2017
That's one way to get it done.
You can also support multiple regions by copying the uploaded AMI using aws ec2 copy-image if you like.
I left comments suggesting improvement by using awss own --query flag to extract the output instead of filtering through jq (thus reducing the need for yet another tool).
I gave instructions in the comment as much as I can without testing the specific command.
Jul 6 2017
Hi Julian,
Mar 7 2017
Feb 18 2017
Just posting here in case someone can help me out -
Feb 8 2017
I'm not building the VyOS from source but extract it from the nightly .iso file.
This works great for me with VyOS 1.1.7.
Debian Jessie doesn't have the kernel 3.18 which is required for OverlayFS.
Feb 7 2017
I'm building the VyOS disk image under another OS (latest test using Ubuntu 16.04 LTS) and was testing the extra configuration script under chroot. Your response would explain that the missing unionfs packages on the host OS could explain the error I get. I'll install them and try again.
I managed to get past the OverlayFS issue by adding:
Feb 6 2017
Feb 4 2017
@syncer yes please split it off. Sorry for taking over the ticket.
I got the VyOS 1.2 AMI built by Packer but it doesn't get the ssh key pulled from the metadata and stored in the configuration. With lots of manual testing I got to a stage where "/bin/cli-shell-api setupSession" fails with a core dump.
I've updated https://github.com/amosshapira/thermal to let you specify VPC ID and subnet ID required to run Packer in AWS.
Feb 2 2017
How do you get the code for 1.2 into your image? I use the ISO of 1.1.7 and started work for 1.2.0 and made some progress but stopped when I hit too many problems and realised that 1.2 isn't stable (that was a few months ago).
I've just verified that the AMI gets built and runs correctly after making sure that the VPC ID and Subnet ID are set correctly in packer.json. I'll update my code when I get home. The issue to track this is https://github.com/amosshapira/thermal/issues/5
Feb 1 2017
ami-72343365 is Ubuntu official public trusty AMI in us-east-1, name "ubuntu/images/hvm-ssd/ubuntu-trusty-14.04-amd64-server-20161205" owner id "099720109477"
@silverbp have you considered using Packer? I got Packer building AMI's of VyOS on AWS here: https://github.com/amosshapira/thermal/tree/master/vyos-image, perhaps you can use it as a basis for a GCE image. Let me know if you need help with understanding the code there (it uses a trick to work around Packer's lack of support for creating the final image from a "side-mounted" volume by switching volumes and rebooting).
Nov 10 2016
This is different but might be a little related - FoxPass publishes a one-line tweak to VyOS 1.0 to let them support two-factor authentication for IPSec VPN at https://foxpass.readme.io/docs/vyatta-vyos-ubiquity-vpn-clients
It would be nice to have this change possible via an option.
Sep 30 2016
I'm not sure how much this will help, but I have a branch on a fork of vyos-build to build AMI's from ISO files: https://github.com/amosshapira/vyos-build/tree/make-ami
Sep 17 2016
Sep 9 2016
I think the usual short name for Google Cloud is "GCE" (Google Cloud Engine).
Sep 7 2016
I have a python script which will read a VPN Connection configuration from a Virtual Gateway and emit VyOS commands to configure it as a client to that VPN connection.
The 169.254/16 is a special link-local subnet which by definition can't be routed outside the immediate link (as far as I follow it). See https://tools.ietf.org/html/rfc3927 for authoritative definition.
Aug 31 2016
Thanks for the update.
Where can I get 1.2 to help testing?
Aug 27 2016
Thanks. I'll try to find how to follow this advice.
Aug 25 2016
Aug 17 2016
Thanks for your research and findings.
Aug 16 2016
@jeffbearer how about policy routing and telling Linux that traffic should only use local 169.254/16 source address if its destination is also on 169.254?
That (using iptables to munge the DNS traffic) sounds like a great work-around. I like it because if it works then I can set it as part of the VyOS standard configuration.
I have BGP tunnel up over the IPSec tunnel between the VyOS and the AWS Virtual GW.
Aug 12 2016
I'm not an expert but my understanding of the definition of 169.254/16 is that it's a "link local" address and shouldn't be used for "real traffic", e.g. AWS uses it to pass EC2 metadata through 169.254.169.254, or see https://tools.ietf.org/html/rfc3927 for how this network is defined.
So I think that the solution should more in the direction of somehow telling VyOS to prefer the local interface address over the 169.254 address.
Aug 6 2016
Thanks but I can't use GRE or OVPN since the other side is AWS virtual gateway (more specifically, I use it as a Virtual CloudHub connecting offices and multiple VPC's).