I've implemented this in our ansible-derived vyos configuration by allowing the static addresses to be generated with the VLAN prepended and adding a system static-host-mapping for the fqdn to ip.

Attached video shows the issue using PuTTY and SecureCRT.

Please test the latest rolling

Since the vyos-build readme was updated, i was able to update and test the change I requested above.
It fixes the issue presented above.

Second this. Came here looking for MPLS support as its supported in FRR.

Can you reproduce this with some other emulator, except SecureCRT and make video with this bug?

The fault is found in the vyos-strongswan codeset,

vyos@core1:~$ tput cols ; tput lines
80
24

Running in GNS3 and connecting via telnet. Using SecureCRT 8.3.4 as the terminal emulator.

Hi, @knozzle !
Provide, please, output of next command, executed in the same terminal as defected show ip bgp summary:

tput cols ; tput lines

Hi, @rizkidtn!
Policy route wouldn't work if it will be assigned to any other interface, except those from which incoming traffic will be received.
Why do you can't set policy to eth1.2400 interface? Is there some problems or errors related with this occurs?

@rps what about changing the minimum supported MTU from "68" to "1450" which is the default that is used in VyOS.

Thanks for your contribution. It will be included in the next EPA and rolling images.

I found another bug in the dhcp generator. Here is the full fix.

@merjin @c-po please have a look to the debian wiki page especially to the mibs-downloader.

https://www.shrubbery.net/mibs/BGP4-MIB.txt
We can start with this like @rherold suggests since FRR supports BGP4 MIB.

Where to get those MIBs? should be simply to test before adding it to the iso

Seems duplicate with https://phabricator.vyos.net/T366
If we use the Cisco BGP MIBv2 we solve both issues.

We should have an eye on https://community.openvpn.net/openvpn/ticket/208 cause this will change the config logic again completly.

It is not a bug in VyOS self. If you look inside the description of this oid:

Please retest on latest rolling

I agree that this should become part of the CLI. The current method is too dangerous and has always been too loose for good syntax checking. It always used to be that you had to use " to embed quotes. That has not worked of late.

A user on the forum informed me that a temporary work around that gets one step closer with the current code base is:

I can confirm, that problem with connection tracking is exist. Reason in this change in Linux kernel. Now, by default, all connection helpers is disabled. You may try to search in your log files something like:

kernel: nf_conntrack: default automatic helper assignment has been turned off for security reasons and CT-based  firewall rule not found. Use the iptables CT target to attach helpers instead.

If you want, you may read more about this here.
So, we need to add all helpers by hand. You may try next workaround. Add this to /config/scripts/vyatta-postconfig-bootup.script:

sleep 10
iptables -t raw -I VYATTA_CT_HELPER 1 -p tcp --dport 1723 -j CT --helper pptp
iptables -t raw -I VYATTA_CT_HELPER 2 -p tcp --dport 21 -j CT --helper ftp

Then reboot or, if you want tot apply it without rebooting, just execute all commands in root shell.

I can confirm that this is broken everywhere "get_response" is used, where the default should be "no". GPU signatures are ignored, disks are deleted, etc. I'll work on making up a sane replacement.

I can confirm that this problem also exists in VyOS 1.1.x when trying to upgrade to 1.1.8. I consider this a pretty big security vulnerability, and this should be fixed in 1.1.x, not just in 1.3 or 1.2.

I suppose problem in conntrack modules. Not only PPTP doesn't work. Publishing of FTP server after upgrade to version 1.2.0 from 1.1.8 also stop working. Disabling/Enabling ftp conntrack do not solve problem too.

I can confirm that this seems to only affect VTI's. Regular IPSec will take dynamic peer just fine. Any update on what the limitation is with VTI's?

Yes that it, thank you @Line2

It was at 2GB because it is a test router running in the production network.
I increased memory and will check to see if this resolves it.

i think 2 gigs not enough for several full tables
will recommed to 4gb at least

@syncer
It is a virtual machine on Hyper-V 2016 with 2 cores, 2GB memory.
I compared the output from top over te past week and the only changes are in the uacctd processes.

.1.3.6.1.2.1.2.2.1.2 is IF-MIB::ifDescr

@Merijn can you provide specs (is that HW deployment?)

So far:

I've been using my branch for a few daily upgrades now, and it seems flawlessly, minus one thing.

Here's a branch that makes this work on an upgrade. For now, it wouldn't cover the initial install, but only subsequent upgrades. This covers a MAJOR pain point for me where I lose my bash history on an upgrade.

@c-po i've updated the Dockerfile and added build notes in README.md to build the vyos-strongswan module in this PR: https://github.com/vyos/vyos-build/pull/31 . please test it out

@gadams:

In T421#27132, @gadams wrote:

2. Is there a way, in the embedded shell scripts in a node.def file, to get the type of the interface? I need to look up the dhcpv6-pd configuration nodes programmatically (in a Python program I've called /usr/libexec/vyos/conf_mode/dhcpv6_pd.py), so I need the path, such as 'interfaces ethernet eth0 dhcpv6-pd'. I can get the 'eth0' part as $VAR(../@), but how can I get the 'ethernet' part? Or is there a way to get to the dhcpv6-pd without it?

Would it make sense to create this as a separate partition during installation? Instead of trying to preserve? Given my recent work on the EFI stuff, I've got an idea where this might happen.

I found an AMI I had built from 1.1.8 back on July 7th. I can create functional 1.1.8 instances from that, so it looks to be something unique to 1.2.0, but I can't say for sure because I don't have a working way to build 1.1.8 AMIs currently. The 1.1.8 playbooks rely on modules that have been removed from Ansible, so I would have to rewrite them or downgrade my ansible install.

Also tried 1.2.0-rolling-201812080337. My best guess is that its not copying the SSH key into the system properly to allow the vyos user to login, as the system responds, accepts the username, rejects the key then disconnects with no further auth method.

I tried the build with 1.2.0-rc9 and rc10 with the same results. The instance boots up without issue, but rejects any login attempts with the SSH key the instance was launched with. The error it gets back suggests its not configured for key or password login, or any other method for some reason.

@dmbaturin Did you forget to merge the other PRs (migration code) ?

A new description could be:

I agree this is becoming increasingly necessary as vendors turn to AWS for hosting services and IP addressing becomes less static for services.

Juniper and Cisco use a global configuration of "vxlan port" or "vxlan udp port". A per-interface configuration is more flexible and likely makes sense.

Will set interface vxlan vxlan0 remote-port 12345 be appropriate? Using destination-port would also work but the remote address is called remote and also openvpn utilizes remote-port