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 =)

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 yoyr tunnes 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.