This bug has been raised for 2 years and has not been closed yet. Is it because it has not been resolved?
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Oct 23 2021
Sep 29 2021
Sep 11 2021
Sep 10 2021
Sep 3 2021
Feb 5 2021
Jul 11 2020
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
Sep 27 2019
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.
Aug 31 2019
Jul 19 2019
Jul 12 2019
@bmtauer is this still a problem for you?
Jul 3 2019
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
Jun 26 2019
@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:
@dongjunbo, show please the configuration of this router so we could check why gcdomestic pool does not count correctly.
Jun 22 2019
Should we backport this into 1.2.2?
Jun 4 2019
This bug must be fixed in current rolling, because of T1416. @dongjunbo, check this, please.
May 12 2019
Mar 26 2019
Mar 16 2019
Mar 12 2019
Please test latest rolling release
Mar 11 2019
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:
Mar 7 2019
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)
Feb 22 2019
@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.
Feb 14 2019
The last rolling worked great. Saw the module was loaded on boot and MSS was clamped correctly.
Thanks!
Feb 13 2019
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.
Feb 12 2019
Feb 11 2019
I was not able to test sooner. But i confirmed it works properly with rolling release vyos-1.2.0-rolling+201902060337-amd64.
Feb 8 2019
Feb 7 2019
Feb 5 2019
Feb 4 2019
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.
Feb 2 2019
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)?
Feb 1 2019
@jmlccdmd Ok, I'll re-test with in/out then.
Jan 31 2019
@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).
Jan 30 2019
@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?
Jan 29 2019
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...
Jan 28 2019
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?
Jan 27 2019
@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.