- User Since
- Sep 15 2018, 11:31 PM (65 w, 21 h)
Wed, Dec 11
T1846 fixes this
Tue, Dec 10
@hagbard Confirmed fix. Migration worked perfectly.
Mon, Dec 9
Related to T1844, which should correct the original problem in this ticket
Fri, Dec 6
Trying to apply the fix manually:
Built a fresh rolling. It failed with:
Okay, so this problem just got a LOT more bizarre.
Thu, Dec 5
When the config was gone, the processes still seemed to be running
Wed, Dec 4
It actually does work, if only by accident
This should be all of the relevant configs from the ASA side
Thu, Nov 21
I guess I'd ask the question of whether we have any complaints of performance type issues that perf could pinpoint? I don't know if I've ever seen any of those kind of complaints in the circles I hang out in.
Mon, Nov 18
PR166 should fix this.
Oct 31 2019
Oct 30 2019
Oct 27 2019
This eliminates the redundant interfaces.py and merges the op_mode displaying code into ifconfig.py
Oct 25 2019
Oct 24 2019
This pull request rewrites all the functionality of ioctl.pm and lays the framework for the rest of Interface.pm
VyOS 1.2-rolling-201910210211 boots perfectly.
Oct 22 2019
Example output. Note this is all programmatically generated in Python now instead of parsing the output of wg
Superseded by T1759
Oct 21 2019
Oct 15 2019
Okay, after working with this for a while, I believe the whole 'vyatta-webproxy` should be a candidate for deletion in equuleus (see T1732).
Oct 14 2019
To be fair, that’s what prompted this. The logs go to a different file already.
This PR should address those concerns
Oct 1 2019
This is going to become more and more of a problem as wireguard adoption continues. Most major Wireguard VPN services provide a FQDN as their endpoint, not IP:
This should be reverted, as the change is breaking. After more testing, I found some problems due to things like static routing being applied before wireguard now. So the wireguard tunnel works, but in some cases any routing that shouldbe going over the tunnel does not work.
Sep 30 2019
Yep. Changing the priority fixes the issue completely
@runar This isn't a routing issue though.
Changing when the tunnel comes up isn’t an option? For whatever reason the tunnel comes up before DNS resolution works. Using a hostname when the system is running works perfectly
Sep 29 2019
Guess? Wireguard coming up before vyos-hostsd?
Sep 24 2019
Can confirm. All my routing tables now have 0.0.0.0/0, no matter what the device is. This is just in 1.2.3.
Sep 23 2019
At this point I've moved all my ASAs to VyOS, and all my tunnels to Wireguard. Unfortunately I cannot test this setup anymore.
Sep 20 2019
PR132 fixes this problem
Sep 19 2019
Sep 18 2019
Sep 16 2019
There are a number of strange things going on here, and I suspect there are multiple bugs:
Sep 9 2019
Sep 6 2019
Sep 3 2019
I took a look, but was unable to figure out how to finagle VyOS to fix it.
Jul 25 2019
Attached are the pcap and debug logs from a simple setup as outlined above, two hosts. "Master" distributing the route.
Mar 17 2019
Yep. Can confirm issue is fixed with the latest hot fix.
Feb 13 2019
Strange. I’ve seen that error a lot. Every time it’s been when I’ve forgotten to checkout current after cloning the repo.
@Merijn make sure you git checkout currenton everything.
Feb 6 2019
Can you describe the system and disks involved?
Yeah, it wasn't really a workable solution for me either and I too had to roll back. But it would be good to confirm that is the problem.
@lbv2rus There might actually be a few problems here. We might have hacked out that it's the interface-route with the custom routing table that's causing the problem.
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.
Feb 1 2019
There might actually be a bit of a deeper problem here, somewhat conditional on some static interface routing. On an broken system, it does say something about staticd starting
Jan 31 2019
And more info:
I tracked down what is causing this.
Jan 30 2019
Too add, routes are present in FRR
Jan 29 2019
Jan 27 2019
Jan 26 2019
THis shows up in the logs:
Unfortunately that seems to have made the problem worse. Before, at least each host was seeing one other host. Now most of them see no hosts.
Sure. I'll set a reminder to check it out tomorrow when I have a free minute. Thanks
Jan 25 2019
Sorry. Spent the week restoring almost half a petabyte of data from backups due to a ZFS crash.
Jan 22 2019
Yeah. I remove the initial vyos user and add an admin and an ansible user. The admin is just for consistency across different devices.
@hagbard I remove/change the vyos user too. So it's definitely a breaking change.
Jan 21 2019
The latest rolling did seem to correct the base problem. That being cron scripts running breaking the ability to edit config afterwards.
@hagbard Note that a reboot does fix the ability to edit configuration again until the next time the cron script runs.
Jan 20 2019
Okay, spent the whole day messing with this and I've tracked it down so it's reproducible.
Jan 14 2019
Superseded by T1178
Seems to be a problem with just that build. I'll install a newer rolling when I get a chance and see if that corrects it.
Edit... actually I can't update anything:
Jan 13 2019
I was mistaken. Seems to have lost the route again.