I have sent a pull request.

@rps I think he needs a more modern version of squid with sslbump support. I wouldn't put any effort in WCCP, it seems fairly legacy to me.

Patch for HTTPs filtering.
I have to remove the existing version and install a new patched version from source.

@hmkias Patch Squid for what?

I would start with PBR in the first phase for supporting the external proxy.

In theory, you could have the web filter be a pair of servers using VRRP.

@mickvav @dmbaturin @EwaldvanGeffen
should we write to that jool tool developers?
It's looks pretty nice

The last one seems to be really interesting - it's a kernel module, should be fast and so on.

We need to rename this maybe,
as it actually have nothing to do with HAproxy

As an engineer working using vyos and HAproxy in many customer environments I would say to keep those solutions apart. Vyos is a great network appliance and HAproxy is an load balancer. They can work together really nice and I dont see a reason to tie them up together.

Just to voice my opinion, I vote strongly against implementing haproxy support. In my opinion this is feature bloat, we should be striving to do networking, not application level load balancing.
Also puppet/ansible/favourite-cf-management-system modules for haproxy exist. My guess is none of the existing users of haproxy would convert and with vyos 1.x it is difficult to support any kind of automation, so I doubt someone validating plain haproxy configuration with the help of a configuration management system would decide for vyos.

or do a fallback to another device.

I prefer opt-in options over 'enable by proxy'.
use-host-decl-name [no-prefix]
and future get-lease-hostnames?

Welcome on board @CBRjack
@dmbaturin can we ship this on by default maybe ?

Hi, I'm the guy from the reddit thread.

@hexes
check this thread
https://www.reddit.com/r/homelab/comments/535fa6/vyos_dhcp_weirdness/d7q6e6g

@EwaldvanGeffen have you given the method I described a try on VyOS? I know it works on EdgeOS and pre- 6.4 releases of Vyatta and honestly haven't tested it on VyOS because it's not something I have a need for... so it very well could work differently/be broken on VyOS, but that would be surprising.

I've added a quick note in the SNAT section of the Wiki to explain this. Feel free to edit if it seems unclear or could be worded better.

Could you provide the contents of "sudo vi /opt/vyatta/etc/dhcpd.conf"? It could be related to previously fixed http://bugzilla.vyos.net/show_bug.cgi?id=334 / Reading into it.

Short answer: not really.

as per @rps request
marking this as solved

You can use policy routing to match HTTP and HTTPS traffic and point it at a next-hop that is an external transparent proxy.

Can we move this to "wontfix". This is the normal behavior of Linux and doing any sort of global drop of invalid state traffic by default is not a realistic change.

After VRRPv3 (with some intelligent way to handle radvd) this is the major blocker for using VyOS as a production IPv6 firewall in my environment.

https://github.com/vyos/vyatta-op-vpn/commit/8a80669f305983de512466e3e2bad0924d7f37a0

This is the fix for the config issue...

@afics this ticket at least have description
i will merge all to one soon

Someone created a duplicate of this task, T149.

Thanks both.
As suggested, is there a way to check the device is live and then forward traffic or do a fallback to another device.

And if you have any other known https destinations with different port numbers - redirect corresponding traffic explicitly.

this hostname is coming from the DHCP-server upstream

You would have to forward traffic to your device. Preferably it handles all types of traffic. Otherwise you can forward dport 443 towards a specific IP.

Keep in mind that the specification has not yet been standardised. If you commit to implementing, make sure you only release it as a 'beta' or 'test release'.

Interested in this too. We will be multi-homing soon and requesting an AS number from ARIN. I doubt we will be getting a 2-byte ASN.

Renamed to platform project name, will change to gce task title
since engine only relates to vms while platform also covers all that networking stuff

I think the usual short name for Google Cloud is "GCE" (Google Cloud Engine).

Will do,

Hey, could you rename the task to make it more obvious what it's about. The default meaning of GCC is GNU Compiler Collection. ;)

Most likely postinst, but I can't find that file in the git repos.

Aha!. I've tried 999.201609070235 (current). Things look quite a bit better; /opt/vyatta/etc/config/scripts/vyatta-postconfig-bootup.script is now persisted, and things seem to start up and run quite nicely.

It should be safe to start a getty on ttyS1 (in addition to the one on ttyS0) for all devices, shouldn't it? Even on devices that don't have a ttyS1 (or even a ttyS0), that shouldn't cause any failures.

Aha! I think I have found the cause. In vyatta-boot-image.pl, there is this code:

Ooh. I see that the script that copies over the ssh keys is vyatta-cfg-system/scripts/install/install-image-existing, but it's run on the old system--the one you're upgrading from. So putting the fix in there would require upgrading the old OS first.

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 entire issue is a ripple effect of allowing the duplicate prefix into the same prefix list.
If we can prevent that, the route-map issue shouldn't occur.

Let me know if you require any additional information. I'm happy to help you with interop testing

@dmbaturin what do you think?

@whiskeyalpharomeo maybe in your scope of interest

Welcome @whiskeyalpharomeo !
No code required(but of course welcomed if any)
After all this project not only about the code!
I like to think that is about giving access to advanced networking to everyone out there!
Since it not like 10 years ago, now technology(hardware) more accessible

Dare I suggest SVN as well?

From the looks of the script it seems this hostname is coming from the DHCP-server upstream. I wonder if this behaviour is controlable.

FTP/SCP also.

I pushed the priority changes I had to do on my T132 branch.

Solution taken from this commit:
https://anonscm.debian.org/cgit/pkg-ssh/openssh.git/commit/?h=debian/7.2p2-6&id=b66f1de1c94fcf912b3a1bc0cd73c3b73cdae8a1

Hello @EwaldvanGeffen
can you check this whenever you have time,
we traced it to a static host mapping(but i'm not sure)

Looks like a worthy endeavor.

Attached is the patch I'm using.

Hello, any updates?

Looks like this has been implemented in EdgeMAX as of v1.8.5: http://community.ubnt.com/t5/EdgeMAX-Updates-Blog/EdgeMAX-EdgeRouter-software-release-v1-8-5/ba-p/1591710

In T115#2189, @UnicronNL wrote:

persistent net rules is not used in vyos? where do you get that from?
it uses hw-id from config file.

In T136#2224, @dmbaturin wrote:

I have some ideas why can it be... We'll have a look.

I have some ideas why can it be... We'll have a look.