end of /etc/snmp/snmpd.conf

# group
group  usm test

Adding set zone-policy zone SERVER interface SERVER to the presented test case should solve the issue. This is because the traffic needs to pass both eth1 and its associated VRF "master" interface, in this case TEST.

See [1] from the previous post:

Note: If you don't want to install anything and don't care about some potential security problems, just enable the following 2 options to get native GRE keepalive support on Linux: […]

I care. Setting these sysctl parameters allows for relaying arbitrary traffic through the router.

@runar You're right, my bad.

I'd love for this feature to get back into VyOS. I am available for testing if needed.

I second this, I would like to be able to setup different keys for multiple wireguard interfaces too.

I would consider adding EVPN support via FRR as soon as kernel support for the inter working between vxlan and bridge interfaces is more fleshed out. Maybe I should create a new task for that.

I am very interested in this, has any work been done?

Tried on → 999.201706052137

I tried doing some basic routing with ofp and it seemed to work but the shipped dpdk version does not compile for my kernel (4.10), so I can't test that.

Just to voice my opinion, I vote strongly against implementing haproxy support. In my opinion this is feature bloat, we should be striving to do networking, not application level load balancing.
Also puppet/ansible/favourite-cf-management-system modules for haproxy exist. My guess is none of the existing users of haproxy would convert and with vyos 1.x it is difficult to support any kind of automation, so I doubt someone validating plain haproxy configuration with the help of a configuration management system would decide for vyos.

Someone created a duplicate of this task, T149.

@whiskeyalpharomeo you can do that already with the existing CLI.

Can you please post the corresponding iptables error?

Ah, good to know. So if we add a switch like transport ipv4/ipv6 to the cli which is only valid for VRRPv3 (add a switch for that too) and then exclude either all v4 or all v6 addresses, would that work?

Does it work, if you use virtual_ipaddress_excluded? Also I don't really understand how this would solve the problem? Could you please explain it?

@jbrown This only works for you because your keepalived versions are old enough.
This got "fixed" (well, at least they're standards compliant now ;)) in 1.2.20 I believe.
See https://github.com/acassen/keepalived/issues/375#issuecomment-230148110 for more information.

[root@test ~]# cat /etc/keepalived/keepalived.conf 
vrrp_instance VI_1 {
    state MASTER
    interface ens3
    virtual_router_id 51
    priority 200
    advert_int 1
    vrrp_version 3
    native_ipv6
    authentication {
        auth_type ah
        auth_pass 1111
    }
    virtual_ipaddress {
        3ffa::1/64
        192.168.100.200/24 
    }
}

Does only work for the v6 address with this configuration.

I tested with keepalived version 1.2.22 on Fedora and it didn't seem to work. I'll test again.

TODO:

• check if our keepalived version supports VRRPv3, if not, upgrade to a newer version.
• implement cli support + config generation

Your core dependecy exscript is not compatible with python3. It seems like someone started working on it but didn't finish and abandoned the port. I guess you don't want to port it, so I guess python3 support is on hold for now :/

OpenVPN 2.2.3 x86_64-linux-gnu [SSL] [LZO2] [EPOLL] [PKCS11] [eurephia] built on Apr 2 2015 on 1.2.0-beta1.

@mdsmds Yes, that should work, but if you do that, you force all traffic to be tracked by conntrack, which might not be what you what. Whereas if you apply it only to in on your internal NIC, you don't have to track all traffic, assuming you have multiple (internal) interfaces and you don't NAT all of them.

I guess we should add this to the user guide.

Yes, that should do the trick.

The important part is to discard any packets with conntrack state invalid on the internal interface. What you are seeing occurs because netfilter forwards instead of NATs packages it does not know about. see https://bugzilla.netfilter.org/show_bug.cgi?id=693#c11.

This is normal behaviour. You need to add a firewall rule to only allow established and related connections and another to drop invalid packets.

Basically create a route-map like below and apply it as the peerings export route-map.
Also please create a question instead of a task next time.

route-map EXPORT-PREPEND {
     rule 10 {
         action permit
         set {
             as-path-prepend "<your as no> <your as no> <your as no>"
         }
     }

Related/duplicate: T33.

I've tested IPsec + Ip6Ip6, everything works flawlessly for two weeks now. I suggest, we remove the check.

First tests haven't shown obvious problems, everything seem's to work. I'll do some more testing.

B rocade vyatta.

I propose adding support for named extended-community-lists, see T64.

@mickvav On vRouter 5600, it would be like I posted. I vote for adding directly under policy.

@syncer Sure.
@mickvav [1] Docs. What else do you need?

Sorry, I just didn't see, the feature was there :O

I will look into it. I think it is feasible to add to 1.x, but we have to think about the cli. We have to treat the default VRF in a way, so it doesn't come in the way of users who don't want/need to use VRFs.