I have included the requested configs (some portions of configs have been censored for security purposes). I have since rolled back to 1.1.8 for this and other reasons but I can confirm that this configuration works on 1.1.8 but not on 1.2.0.

Can you share your config please, with the statement that breaks your config. thx.

Well that is interesting, the package versions are still the same but now it works.

Unfortunately, this works only for default route, but not for any other.

e.g. could indeed be tested to make sure that it works

I think the issue you found might still be a valid one, even though it was not the same one that was originally talked about on IRC.

Needs more testing. I might have been testing the wrong thing. :(

The only packages i manually build are vyatta-cfg-firewall and vyatta-nat, the rest of the packages directories are empty so the packages get downloaded.

Why not use a combination of two?

Root cause is the inability of tftpd to listen on multiple addresses.

Will test with the next rolling before I close off the task.

Yeah, I agree.

As there is no recorded bug in this behavior on 1.2 we only would increase the risk on the LTS versions without legitimate benefit.

We should NOT backport this to VyOS 1.2 crux

We should NOT backport this to VyOS 1.2 crux

Yes, please migrate that function, too. One more migrated command.

/opt/vyatta/share/vyatta-cfg/templates/system/static-host-mapping/host-name/node.def writes the entry, I think the functionality should be integrated into host_name.py. I contacted @c-po to hear his opinion.

http://dev.packages.vyos.net/repositories/current/vyos/pool/main/v/vyatta-wanloadbalance/vyatta-wanloadbalance_0.13.70+vyos2+current1_amd64.deb
solving the issue
it may be closed

@hagbardIt fixes the issue with WANLOADBALANCE_PRE chain, but we still observe unexpected behavior.
I will write a little bit more letter.

@zsdc Is it working for you with the package above?

@zsdc All right, http://dev.packages.vyos.net/repositories/current/vyos/pool/main/v/vyatta-wanloadbalance/vyatta-wanloadbalance_0.13.70+vyos2+current1_amd64.deb should solve the issue you are seeing. The code of the binary is good for another dozen bug tickets =)
Pls let me know if it works as expected, since I only tested your particular use case.

LBDecision::execute(): applying command to system: iptables -t mangle -A WANLOADBALANCE_PRE -i eth1 --proto all --destination ! 192.168.0.0/16 -m state --state NEW -j ISP_eth1
Bad argument `192.168.0.0/16'
Try `iptables -h' or 'iptables --help' for more information.
LBDecision::execute(): applying command to system: iptables -t mangle -A WANLOADBALANCE_PRE -i eth1 --proto all --destination ! 192.168.0.0/16 -j CONNMARK --restore-mark
Bad argument `192.168.0.0/16'
Try `iptables -h' or 'iptables --help' for more information.

Happens in /opt/vyatta/sbin/wan_lb.

I checked the 'server' options for 'push-route' and 'name-server' and even with these configured as opposed to the openvpn-option configuration entry, it still gives the "Options error" complaint about the push command.

I checked and $ show system kernel-messages | grep pppoe0 did not return any output.

I will have to re-test tonight (when nobody else is using the Internet) and get some log output.

Interface name is ppp0 but will later be renamed to pppoe0

I’ll add that I think this is happening because of the .252 and .254 addresses. The 254 address connects, but the 252 address is marked in a constant state of connecting.

In T1226#32102, @hagbard wrote:

@Maltahl Let me know if you still need help, please. I put the task meanwhile on-hold.

@Maltahl Let me know if you still need help, please. I put the task meanwhile on-hold.

Configured protocols does not match Proposed protocols. Try without pfs configuration on the VyOS side.

http://dev.packages.vyos.net/repositories/current/vyos/pool/main/v/vyos-1x/vyos-1x_1.2.0-12_all.deb next rolling release has it.

In T1226#32033, @hagbard wrote:

@Maltahl Did you try the same with the rolling release? I don't see any issue with your config in particular, did you check that the wg traffic is actually getting to your router02?

@Maltahl Did you try the same with the rolling release? I don't see any issue with your config in particular, did you check that the wg traffic is actually getting to your router02?

That is not how wireguard works ? that is how ipsec and openvpn works.

This is how ipv4 works :) and have nothing to do with wireguard, ipsec etc. Actually the config you have applied eill in some situations work, but that relies on the handling of the packets inside the kernel and is not following the tcp/ip principles... If you take a look on the quick start guide on the wireguard webpage you se it there aswell... https://www.wireguard.com/quickstart/.

In T1226#32008, @runar wrote:

Hi! I see that your tunnels does not resides inside the same subnet, one devise is '10.0.90.1/24' and the other one '10.0.100.1/24'.. please move one of then to ip .2 in the subnet belonging to the other router.

Hi! I see that your tunnels does not resides inside the same subnet, one devise is '10.0.90.1/24' and the other one '10.0.100.1/24'.. please move one of then to ip .2 in the subnet belonging to the other router.

Forgot to add version for both routers, sorry.