https://vyos.readthedocs.io/en/latest/vpn.html#pptp-server

Please test latest rolling release

Sorry I can't replicate your issue, tested it with VyOS 1.2.0-rolling+201903110337.

After more testing, this does look more like an upstream regression wrt this particular hardware:

I've finally managed to test this (apologies, we've had a super busy couple of months) and don't appear to be able to connect to the VPN anymore :(

http://dev.packages.vyos.net/repositories/current/vyos/pool/main/v/vyos-1x/vyos-1x_1.3.0-14_all.deb or tonights rolling. systelog will still run and will log journalctl messages.

journalctl needs systlsog since it's supposed to it's messages there, so the above commands won't stop rsyslog, but I'll fix the error for the cli.

I managed to reproduce this earlier. These were the generated iptables rules and pinging from any source IP except the first one did not work. https://phabricator.vyos.net/P66
I could see the responses in tcpdump but they were getting blocked (so I assume. They did not reach the running ping program)

moving 'set protocols static arp' into it's own python script. - done-

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:

From the man page:

You can put the server into the PARTNER-DOWN state either by using the omshell (1) command or by stopping the server, editing the last peer state declaration in the lease file, and restarting the server.

I did a pull-request.

@varesa You are mixing VirtIO which needs offloading, ESXi doesn't need that, nor it's driver. It's related to native KVM mostly.

Revert to the original config, since the tighter default restrictions make trouble with pooled addresses.
http://dev.packages.vyos.net/repositories/current/vyos/pool/main/v/vyos-1x/vyos-1x_1.3.0-12_all.deb

I'm going to revert the for default restrict

That's what I thought. Thanks for testing it.

Not work, ntp queries another ip from pool.

In T1276#33655, @syncer wrote:

Wondering if we should disable all offload stuff in virtualized environments (which not make sense anyway)

@zsdc How quickly needs that to be resolved? It requires quite some work on the backend for the cli.

Ok, I resolve the IP during config time and wite it into the file, please note that it will be only 1 of the pool IPs, so it should work for you.
Please test: https://github.com/hagbard-01/vyos-1x/releases/download/v1.0/vyos-1x_1.3.0-11_all.deb and let me know if that works for you.

Both use cases mentioned above have been solved in a different maner.

@c-po i think we should bump it to 1450
also need a recommendation for 1600 for production use
maybe at time you create vxlan it should check upstream interface

How should we proceed?

Same goes for DHCPv6 server

I don`t block. Problem exist if use pool of ntp servers like 3.pool.ntp.org. If use domain name with one A record, all work.

In T1276#33738, @ddiguru wrote:

Something interesting - The above configuration launches isc-dhcp-relay as:

/usr/sbin/dhcrelay -q -4 -a -m discard -i eth4 -i eth0 192.168.4.40

This has the bad behavior w/ the extra DHCPREQUEST that has the local giaddr.

When i launch it as:

/usr/sbin/dhcrelay -q -4 -a -m discard -i eth4 192.168.4.40 -i eth0

I no longer get the extra DHCPREQUEST with the local giaddr (which gets DHCPNAKed)

So, it's as if the last -i <interface> is treated as the upstream interface. The man page on dhclient does not detail that!

NOTE: I have not tested adding additional interfaces i.e. /usr/sbin/dhclient -q -4 -a -m discard -i eth1 -i eth2 -i eth3 -i eth4 192.168.4.40 -i eth0 to see if that works as well.

An aside - ISC is actively developing KEA DHCP as the next generation DHCPv4 and DHCPv6 server. Currently, there is no DHCP Relay Agent in the KEA code as of version 1.5.0. The ISC has also stated that ISC dhcpd version 4.4.x is the last code train.

Something interesting - The above configuration launches isc-dhcp-relay as:

/usr/sbin/dhcrelay -q -4 -a -m discard -i eth4 -i eth0 192.168.4.40

This has the bad behavior w/ the extra DHCPREQUEST that has the local giaddr.

I'd like to weigh in on this, as I have seen a couple of issues. I'm running the following:

Version:          VyOS 1.2.0-rolling+201903072319
Built by:         [email protected]
Built on:         Thu 07 Mar 2019 23:19 UTC
Build ID:         4861161f-4f33-4b22-900e-524f241625ca

Interesting, it did work during my tests and my implementation was based on the offical ntp documentation.

I think restrick option in ntp.conf not support domain name. After install new package

dimka@vyos-rtr# show
 allow-clients {
     address 192.168.5.0/24
 }
 listen-address 192.168.0.30
 server 1.pool.ntp.org {
 }
[edit system ntp]

thx for testing.

Tested using new rolling vyos-1.2.0-rolling+201903072319-amd64.iso

configure
set system syslog global preserve-fqdn
commit
save

searched these two files:

• /etc/rsyslog.conf
• /etc/rsyslog.d/vyos-rsyslog.conf

this and it's a global rsyslog option only. (https://www.rsyslog.com/doc/v8-stable/configuration/global/index.html)

oh sorry, i was simply curious as to why you suggested adding the "global" node?

Can you clarify please, I can't follow what you mean.

OOC why the term "global"? Do you foresee add'l global directives that you'd like added to that node or simply to keep things tidy under the syslog node?

What about:
set system syslog global preserve-fqdn

@Dmitry here you go: http://dev.packages.vyos.net/repositories/current/vyos/pool/main/v/vyos-1x/vyos-1x_1.3.0-10_all.deb, or the rolling release created tonight.

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

@Dmitry Oh ok, I didn't see the trees in the woods. Yeah, that needs to be fixed, I see that I can squeeze it in today.

I made it.

Its a pair of supermicro servers, each containing:

Please provide HW model(s)

Tested this now using snapshot vyos-1.2.0-rolling+201903070337 and my usecase with OSPF via OpenVPN-Site-to-Site tunnels. Built up test setup using two vpn endpoints connected via a router (w/o firewall).

I`l try this package, but have problem with sync time on this vyos machine, because absent allow restriction for ntp server. State always INIT

I didn't find any issues so far, aside from the fact that I think no one is using pptp anymore, I'll keep this task still open for a few days just to make sure the replacement was successful.

@syncer you need it on Hypervisor tap level not in the VM itself.

found in the old documentation that mppe is always set to the highest, will implement it as a config option with the default of mppe require.