@sergei yes, please put it here for records

I found VPN tunnel with esp lifetime of 43200 sec (12 hrs) is stable. Can share my config if necessary.

Found workaround for ESP lifetime issue, need monitoring for 24 hrs to verify.

@sergei can you check 1.2 behaviour too please

@xrpixer thank you very much for the clarification. Hopefully other users can benefit from it, too.

Sorry for the late response on this.

@xrpixer thanks for submitting. Any change you could double check it on a recent nightly build of VyOs 1.2.x? => https://downloads.vyos.io/?dir=rolling/current/amd64

Already triggered CI builds su it will be in tonights version.

Ah ok, sorry, i'm bit slow today.
Awesome!

Nope, this is the output after binding it to eth0 only. It always binds to the loopback interface!

so it still there ?
weird thing

After adding the bind-interfacesparameter to the configuration, movng the configuration file from /etc/dnsmasq.conf to /etc/dnsmasq.d/vyos.conf and switching to systemd, this is the result:

Yes, can do

Want to look into that?

In Q122, @aopdal wrote:

With prefix delegation you have a static prefix on your inside, but the "wan" interface on the router is using DHCP.

With prefix delegation you have a static prefix on your inside, but the "wan" interface on the router is using DHCP.

In Q122, @aopdal wrote:

Are your addresses managed from Comcast using prefix delegation?

Without routing you probably can't get it to work. Are your addresses managed from Comcast using prefix delegation?

In Q122, @aopdal wrote:

@beamerblvd have you added routes for your vif 100,200 and 900 in your "COMCAST BUSINESS IP GATEWAY"?

@beamerblvd have you added routes for your vif 100,200 and 900 in your "COMCAST BUSINESS IP GATEWAY"?

So the attempts with /56 and /60 were part of my hundreds of different combinations/attempts to get this to work. I have one /56 assigned to me (2603:xxxx:xxxx:8700::/56) with one gateway assigned to me (2603:xxxx:xxxx:8700:7454:7dff:feb1:d391). Skipping the WAN for just a second because I believe(d) it to need different configuration, I expected to be able to break that /56 up into /64s and use them like so:

I am willing to give some advice but it's an issue to understand your infrastructure based on a very fuzzy set of details.
The basic rule of thumb that I can think of is that you cannot assign ip addresses with the same or overlapping prefix on two interfaces and route between them.
I do not know if the VyOS kernel supports IPV6 NAT feature but this should be a very last resort for specific scenarios.
If you need some examples on how IPv6 prefixes are being used you can try to peek at some IPv6 brokers such as Hurricane Electric.
They give you a very specific IPv6 address and prefix for the WAN side with a specific default route,
Then they give you a different prefix to assign the internal network which is behind the main gateway.
Is your setup different then what HE offers?

Perhaps you could make a drawing of what you try to get working? With proper interface naming etc. eth0 - wan, eth1 - dmz, eth2 - lan or whatever you are using. It makes it easier to understand what you try to do. And for the interfaces why do you want to use the /60?

In Q122, @aopdal wrote:

Maybe this is relevant? https://phabricator.vyos.net/T421

Maybe this is relevant? https://phabricator.vyos.net/T421

So, I ended up handling my IPv4 addresses using 1:1 NAT. It works, and I don't love it, but I think it's the best it's going to get with Comcast's clunky static IP infrastructure. But I'm having no luck with IPv6, and could really use some help with someone who understand's static IPv6 and VyOS a little better. I have a static IPv6 prefix, and I need to statically assign some of those to public-facing servers behind my firewall/router, but it's like pulling teeth from a rhinoceros.

Uhmm, I guess, we may have a hard row to hoe here:

Triggered Jenkins build https://ci.vyos.net/job/vyatta-cfg-system/281/changes, will be in the next nightly build

maybe it can have something to do with old vyatta appliances, not sure.
i agree with you @c-po, in case we may need something like that, we can reinvent the wheel later.

A FAT16 partition is created that is not formated? As It's also broken in 1.1.8 and nobody knows what it does I opt for removal of this "feature"

Use "set load-balancing wan sticky-connections inbound".

Use "set load-balancing wan sticky-connections inbound"

@dmbaturin any comments on this?

Anyone having any ideas to how to solve this problem?

@dmbaturin do you know what is for?

This is a drawing of my current lab environment.

@Unicron check please

The lldpd package had really insufficient dependencies, it didn't even list libssl. This is why it wasn't rebuilt, we used apt-cache rdepend to find the packages that depend on libssl0.9.8, and due to missing dependencies this one didn't show up.

@UnicronNL can you rebuild it ?

I've done pkg-release in that package to include the latest commits into debian changelog and update the package version (helium4 now).

The issue was with variable scoping, the variable for server subnet that was supposed to be global was instead updated in the local scope.

@UnicronNL Just to make sure, the package included in helium now is also patched?

This did the trick. Just build a fresh ISO:

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

@UnicronNL maybe this will fix this issue:

Our nightly builds ships wpasupplicant 2.3-1+deb8u4, according to https://www.debian.org/security/2017/dsa-3999 it's fixed in 2.3-1+deb8u5.

Thank you Fatihusta, dmbaturin.

If you want multiple interfaces with the same properties as the loopback, use dummy interfaces.

Hi
You can use dummy interface.
It's like a loopback interface.

@jbeisser cloud init was integrated much later and still require testing
1.2 will be using cloud-init for that purpose