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

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

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.

PR https://github.com/vyos/vyos-1x/pull/91

@bmtauer is this still a problem for you?

Thanks for the contribution

@c-po @dmbaturin I created two pull requests, one for 1.2.2, one to fix a problem on current branch

@zsdc I'm thinking of partially rewriting show_dhcp.py soon. You can wait a few days if it's not urgent.
@dongjunbo please attach your /config/dhcpd.leases as a file so we can test the code against it. You can sanitize it manually of MAC addresses if you prefer.

In T1416#38750, @dongjunbo wrote:

Seem like static counting still not right

@dongjunbo, show please the configuration of this router so we could check why gcdomestic pool does not count correctly.

Should we backport this into 1.2.2?

This bug must be fixed in current rolling, because of T1416. @dongjunbo, check this, please.

Please test latest rolling release

I've put in the suggested kernel parameters for my install to disable the broken functionality. Hopefully this will keep it stable until a version with an upgraded kernel is available :)

This debian bug shows the same issue:

Full lspci -vv

Its the intel broadwell one:

it seems somehow related to supermicro servers
can you also provide a storage controller model, please

Its a pair of supermicro servers, each containing:

Please provide HW model(s)

@fromport http://dev.packages.vyos.net/repositories/current/vyos/pool/main/v/vyos-1x/vyos-1x_1.3.0-3_all.deb or Feb 23rd rolling release. If it's urgent I can trigger a build for you.

The last rolling worked great. Saw the module was loaded on boot and MSS was clamped correctly.
Thanks!

Thank you!
I'll test the next rolling asap and report back.

Latest rolling should autoload the module

Yes! That's what i need.
In my script above i had to put modprobe br_netfilter so it loads on system boot.

modprobe br_netfilter
iptables -t mangle -I POSTROUTING -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1400

If we could have br_netfilter loaded on boot in the image that would be great and would fix this problem.

br_netfilter should already be compuled as a module. Can you sudo modprobe br_netfilter? To see if it fits your purpose? If so we can autoload it on system bootup

Sorry i'm not sure we're on the same page.

This will be part of a bigger workpackage when the whole firewalling is rewritten. There is yet no ETA.

@c-po thanks for mentioning the PPPoE connection, really got me thinking about the word POSTROUTING!
The solution is this -

In T1245#32694, @c-po wrote:

Your second command does kot specify any output interface whereas the first command speciefies tun0. Especially on ESXi you see almost no difference compared ro a vietual Box.

I myself run 1.2.0 in both a Physical and ESXi instance on PPPoE and use the clamping commands successfully on both nodes

Your second command does kot specify any output interface whereas the first command speciefies tun0. Especially on ESXi you see almost no difference compared ro a vietual Box.

I was not able to test sooner. But i confirmed it works properly with rolling release vyos-1.2.0-rolling+201902060337-amd64.

My fault for not having the time to test this as one of the users who has a need for RFC compliant VRRP. The use of + for interface matching is less than ideal but if we do so we should take care to recommend that use of 802.1Q VLAN sub-interfaces not make use of the parent (untagged) interface else traffic matching will not be obvious.

Does this mean it can now listen on "outer" transport IPv6 addresses now that it is using 2.4.0 (even if it is just a special "option" and not yet in the VyOS CLI)?

@jmlccdmd Ok, I'll re-test with in/out then.

@thinkl33t Would you mind testing your use case with https://downloads.vyos.io/rolling/current/amd64/vyos-1.2.0-rolling%2B201901312041-amd64.iso or later? This iso is using the bpo package of openvpn (2.4.0).

@thinkl33t http://dev.packages.vyos.net/repositories/current/vyos/pool/main/o/openvpn/openvpn_2.4.0-6+deb9u1~bpo8+1_amd64.deb

@c-po imported and test against latest rolling, I couldn't find any issue with 2.4.

@c-po it only affects clients which enforce tls 1.0 or 1.1, at least what I have tested. The perl code needs quite some rework, so I think I split the task into getting a newer release of openvpn into the build. Newer versions have tls 1.0 and 1.1 disabled per default from what I have read, so I think it might be more a changelog announcement that with the new version only tls 1.2 is automatically supported and you have the option to enable weak ciphers via opt .... or so. I'm not too sure yet, I think I have to wait a little on the response once the newer version is in rolling and the feedback I receive.

I confirm that in yesterday's rolling image, the problem is corrected.

I reopen this bug.

Sounds more reasonable (enable than disable). Will this affect backwards compatibility or will there be a migrator?

In T1051#27092, @c-po wrote:

set interfaces openvpn vtun0 disable-weak-tls-ciphers

On my systems, the problem persist with today's rolling release.

Still seems to be present in VyOS 1.2.0-GA...

Unfortunately I still see the problem when the blackhole routes are set with a distance of 240 and the 0.0.0.0 route is distance 1.

@syncer Currently we ship in the iso openvpn from main, we could use it from bpo which would be 2.4 (2.6 is the latest), or we replace it with a self-compiled 2.6, or do you just want cpo's solution implemented?

@hagbard can you please bump version of openvpn

Since this is a trivial cosmetic issue, we are about to freeze 1.2.0, and the installer is due for a rework in 1.3.0, I'm going to ignore this for now.