The new firewall implementation makes this no longer relevant.

In T1019#26665, @runar wrote:

Hmm, please enligthen me. Google BBR is a new way to handle congesition instead of the traditional way tcp deals with it. This functionallity needs to be enabled in the end host systems starting the tcp session to have any impact on troughput and congestion control.. as vyos is a router and are not responsible to start tcp sessions on behalf of any end system, what is the benefit of adding this functionallity?

This bug has been raised for 2 years and has not been closed yet. Is it because it has not been resolved?

Just my thoughts - there are situations where rp_filter is not sufficient, and it was not clear to me how to do this cleanly with the zone firewall, so I ended up hacking a few iptables commands in rc.local instead.

I need to modify the file(/etc/swanctl/swanctl.conf) manually, from emote_ts = dynamic[gre] to remote_ts = 0.0.0.0/0[gre].

I test that issue on 1.2.5. but not work

You can consider submitting a PR request in a rolling branch that has requested a merge.

I'm still seeing this in VyOS 1.3-rolling-202004170117

Pull Request: https://github.com/vyos/ppp-upstream/pull/2

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8597

I send a pull request to fix it:

We took other steps that allows us to take the image back to a manageable size, and this task lost its immediate relevance.

I think we can close this task.
Nothing like that has happened in the last few months.

This is confusing. While NTP used to work (listen on all interfaces) without any listen-address set, now it doesn't. This means any old config without listen-address set will now have a non-working NTP without any warning. There was no migration script to migrate the old behavior to the new. ntp should have a mandatory listen-address if this new behavior is kept.

Hello!
Please also add "single-session" to
set service pppoe-server ppp-options

Do you know what the outcome of this old task was?

While "interface ignore wildcard" configured, we got:

ntpq -c lpeer
 remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 10.255.0.1      .INIT.          16 u    -   64    0    0.000    0.000   0.000

Yes, this _was_ still a problem but the workaround solves the issue for
me. I've been able to upgrade the 1.1.8 instances to 1.2.3 after adding
this extra interface route.

You are absolutely right. Was a stressful morning sorting this out, thanks for the response.

@LBegnaud if I read the source correct the command set vpn ipsec options disable-route-autoinstall is what you are looking for, it was implemented in T71.

Yes definitely just ran into this myself. I think i had the opposite problem of OP. I have only ipsec VTI on the router, but whenever a reset vpn ipsec-peer command was run, the peer IP was being added as default route for table 220. Furthermore, this was being respected as the default route for the system (I'm not sure how route priority works with tables, but i'm guessing table 220 has preference over table main?)

@UnicronNL , no need to apply the patch, it is already applied to the codebase. this issue needs to be something else

In T1070#41443, @runar wrote:

@UnicronNL could you apply my patch to the codebase?

@UnicronNL could you apply my patch to the codebase?

I an confirm as well this is happening in 1.2.2. Is there anyway to cronjob a restart of the process to re-establish connectivity to the hub as a workaround?

@dmbaturin ok, will address that in the next rewrite

@alkersan Looks good, thanks!

A pair of PRs were made in vyos-1x and vyatta-op.
Thought they would get linked to this task by phabricator automatically, but that didn't happen.

xe-daemon.service is missing, please add it

@bmtauer is this still a problem for you?

that commit should be reworded to have the task id in front.

Hi Guys,

@dmbaturin is there any reason the IPv6 peer-group is under address-family ipv6-unicast and the IPv4 peer-group is not? Seems this one was missed during migration?

@syncer @dmbaturin - I'm experiencing this on upgrade from 1.1.8 to 1.2.1, is this expected behaviour that you have to chown it?

Attempt two of the fix, so disregard everything in above attempt.

I have a working fix, which is comprised of earlier suggested fixes I mentioned in T1028 and T894:

I want to set this ticket back to "Needs testing" or even "Open", I have downloaded and tested vyos-rolling-2019-04-16 and it seems it is not properly fixed.

This requires fix, since workaround not fully acceptable

Hi all,