I'm going to implement it into the configuration, which will assure that is it going to be the last step executed after a reboot.

wireguard identifies peers on their key, improve the command for sh int wireguard wg01 peers etc. so that the peer name from the config is visible as well.

@ekim https://downloads.vyos.io/rolling/current/amd64/vyos-1.2.0-rolling%2B201901181924-amd64.iso should address the dhcp issue, can you please test? I only tested on VMs yet.

@yun https://downloads.vyos.io/rolling/current/amd64/vyos-1.2.0-rolling%2B201901181924-amd64.iso should address that issue, can you please test? I only tested on VMs yet.

pending ci netplugd integration, local tests were quite successful, I think it can be release into rolling in the next few days.

http://dev.packages.vyos.net/repositories/current/vyos/pool/main/v/vyos-vmwaretools-scripts/vyos-vmwaretools-scripts_1.0-1_all.deb

T1181 will fix that issue.

All right @ekim I have that feature working in an experimental package. If you want to test it you can build it from here:
https://github.com/hagbard-01/vyos-netplug via dpkg-buildpackage -b -tc -uc -us and install it on any rolling iso. I used the latest for my tests, but it should work on older ones too. It will still take a little time to have that pushed into the normal build process, since it requires some integration work.

@ekim Yeah, that is a known issue I was looking into a while ago already. disable/enable in eth interfaces should now work in the latest rolling, the plug-in and unplug will still need a little. I'll keep this task here open for it.

I think I know what you mean now, it also starts translating the global address on the external interface. Can you send a PR for the changes you've made please?

At the first quick review it works:

@Merijn I haven't added anything. I just tested nptv6 and it was working as expected. I used your setup you have initially posted, I just used a different interface for the outgoing traffic. I confirmed via tcpdump that NAT did work.

@ekim I think I found it. When I put the interface into disabled mode and then delete disabled, the dhcp client isn't started anymore if the address is supposed to be received via dhcp, correct?

Have you checked on the server DHCP server side for issues?

I've tested it without doing anything on the code and everything is working properly.

That's all to test. I did test it based on the config you provide above, I just want to see if there are any corner case I did not consider.

I got a bit further. uacctd seems to have an issue, I started manually pmacctd on pppoe0 and everything is working well. Uacctd shows that it gets hit with something when I check via strace, but it doesn't show anything.

merged and closed on @kroy 's behalf. (https://phabricator.vyos.net/R5:749d923ee9704624a476bef17d66d752aff6bf0d)
thx @kroy

The latest rolling has now 'net.ipv4.conf.all.send_redirects = 0', can you please test if that would solve that issue?

But wouldn't that be a n SA issue in strongswan?
Found their bugreports, I think the best and safest way is to turn redirects entirely off and set an option in interfaces to turn it on. That way we can assure that a warning messages is also read and understood. agree?

Hmm, I don't like the leaking part :D (I doubt that it will be unecrypted, but haven't tested it yet) . Per default redirects are enabled on every interface, which is the default.

@zsdc if I understand you correctly, you want that /proc/sys/net/ipv4/conf/all/send_redirects is always 0 unless configured on purpose, correct?
Per default router should do that.

Sorry for the delay @Barrysdca , please test the rolling release January 8th. or alternativly you can install http://dev.packages.vyos.net/repositories/current/vyos/pool/main/v/vyatta-cfg-system/vyatta-cfg-system_0.20.44+vyos2+current17_amd64.deb as well, which should fix the issue.
Please provide feedback as soon as you can, I tested the config you have posted above and everything appears to be working well now with the new package.

https://phabricator.vyos.net/R3:15a9a405e03165b798776b9f779426bdfa779d03

https://github.com/vyos/vyatta-cfg-vpn/commit/8365c04cccb6e0216b048ca30e289081f0c0ae44
https://github.com/vyos/vyos-1x/commit/ac7c868dcba4dd6738eb0087c4f414b92bf10c9d

@syncer I was thinking to add a cli menu for vmwaretoolsd mitgation like these things. It seems that not many were affected by that but if there is anything in the cli available, it can configure the toolsd to prevent things like that plus the toolsd has tons of options. So, I'm not really sure how I should go forward with this one.

Next rolling will have the fix applied:
https://github.com/vyos/vyos-1x/commit/76fe726e3530158ee175d34b9cb74209ccca2345

@c-po I have access to it, let me know if you need a pdf out of it.

I stumbled over the same issue and since then I contribute to @UnicronNL and @c-po documentation. I think the old wiki will go away at one point, have a look at the github link @c-po posted above, it's also way easier to maintain the new documentation.

Hi @rherold , these messages are verbose debug messages, change to virtio-net or to a different emulated driver to have them disappear. In general I recommend to use the virtio one which has a better performance too compared to emulated ones, plus less complex code. (https://github.com/MorteNoir1/virtualbox_e1000_0day)

Thanks for testing that guys.

@MrXermon , yes that sounds reasonable. I found in the code that they limit it to 100 routes, can you please try the following:
(https://github.com/vmware/open-vm-tools/blob/master/open-vm-tools/lib/include/conf.h#L138)

Hi @Barrysdca did you have a chance to test again?

Hi @danhusan, did you ever try another poll value, like 3 secs or 5 or anything like that? If set to 0, the host system won't show you any updated meta data, like if you change the ip address etc.
(https://github.com/vmware/open-vm-tools/blob/master/open-vm-tools/services/plugins/guestInfo/guestInfoServer.c#L1662)
I'm therefore not entirely sure if that should be treated as a special case scenario (we could publish a kb if you run into that condition), or if it is a general issue since you 2 were the only ones experience that issue as far as I know.
I'm also not sure it only is triggered by your situation (full bgp table) or if it can happen on other occasions as well, if you came across more issues regarding that value, please let me know.

I have a look into it but I doubt that this will be an issue. Charon is usually taking care of the routes if an IPSec tunnel has been established and you have a valid SA. The redirects from the settings above shouldn't interferer with it at all. If a mode tunnel is being used with public IPs, the packets will leave the system unencrypted anyway as long as no valid SA exists, so they will go the default route. I'll check if the perl script is actually changing these settings, that would be not so nice since you will face a race condition which would explain why I can't reproduce your issue, since I never tested with a working IPSec tunnel :). I'm having the flu right now, so please give me a few days to have a look.

Can you check ig you have any postscripts running or any manual sysctl variable set? Or do you experience that on new insatllations?

Yes, that's correct. When I enable redirects, it automatically disables receive redirects, which I didn't know but makes sense.
I have only set the redirect and dhcp on eth0, commit && save and rebooted, all looks good.

I still have no luck reproducing it, I loaded your config on a vm, runni9ng the smae version as you do but if I enable and disable redirects it switches between 1 and 0, as expected.

@zsdc I can't reproduce it, can you please share your config? I have only enable send redirects set, nothing else in the config and everything works like expected. I suspect that something is overwriting your variables. We'll find out.

Next rolling release tonight will have the bugfix in place. Thanks for reporting.

@Barrysdca Can you please test with the latest rolling release, please?

@Unicron Can you please integrate the package below into ci?
https://github.com/vyos/vyos-vmwaretools-scripts

@hexes Should be fixed now. (https://downloads.vyos.io/rolling/current/amd64/vyos-1.2.0-rolling%2B201812171828-amd64.iso)

https://phabricator.vyos.net/R11:9e03aa762bac9919db2dae774062b179f9478b70

Uh, yeah, that sucks. I'm implementing the kernel variables for wireguard at the moment and have a look into the other interfaces after that.

@runar I should have something ready tomorrow or at the weekend at the latest you could test for IPv4. I basically started implementing the 'set interfaces <intf> ip' options including the kernel vars which you can set on other interfaces since wireguard is using that interface and looks like a normal network interface to the kernel.

Ahh, I think I found it. Usually sysctl sets it to 1, or at least it must have that done in 1.1. I think the command should be called then enable-arp-filter to correct it.

Unless I misunderstood you, int(0) does disable (no source validation) rp_filter.

After playing around with it, I think I create an extra script just for that task, it'll be easier to maintain until that parts are moved out to 'set protocol'.

Oh I see, so it would be then in /opt/vyatta/share/vyatta-cfg/templates/interfaces/wireguard/node.tag/ip/ospf/cost/node.def.
What do you mean with moving it into the protocol subtree?
I also would then handle it within the wireguard code, like I did for the firewall stuff.
(https://github.com/vyos/vyos-1x/commit/51f61991092a163f680e4ec8f122e73f4074ddf9)
Let me know what you think, would be just an extra node and leavenode to handle.

Hi @Barrysdca , can you please test if the issue persists with https://downloads.vyos.io/rolling/current/amd64/vyos-1.2.0-rolling%2B201812120337-amd64.iso
I tested it on the image and it appears that I can't reproduce it anymore.

@runar How do you set it on other interfaces?

the new syntax is being applied to the config file.

I've tested it successfully multiple times and pushed the fix upstream, the configured MTU is now being requested with the first PADI.

Thanks for testing and confirming. @trystan

All right, thanks bunch. I think I found the issue but before I expose it into the image, I'd like to test with you the functionality.