I’m trying out the vyos(v1.5) router for the first time. I want to receive UDP (VXLAN 4789) packets on eth0 of vyos and then forward these packets to two remote servers (dst port: 4789) via multicast. Could you please tell me how to configure this?
That sounds like an odd solution.
Why not let these two “remote servers” have their own dedicated VXLAN-tunnels towards that first device generating the VXLAN packets?
This way you wouldnt be dependent on multicast to be functional in between.
Thank you for your response. The packets are already encapsulated with VNI from the front-end server to the VyOS. Tunneling operations for the mentioned destination servers are challenging, as they involve setting up solutions. Therefore, I am considering simply forwarding these packets simultaneously to both servers.
The two end servers at the final destination already have decapsulation capabilities
You are doing it wrong…
It wont be less challenging when you involve multicast into this.
Since the destination servers already have unique IP-addresses I would go for that instead of complicating stuff by involving multicast for no good reason.
Could you show me the sample configuration you think?
What do you have to deal with as in which components are involved and what is the purpose?
The task is simple. We just need to forward the same UDP packet to two backend servers simultaneously through the VyOS router.
So VyOS is a simple router in your Szenario?! VXLAN is just a coincidence. You should consult your endpoint demo about multicast and then do multicast routing I assume - Disclaimer: I am not a multicast expert
Yes, in my opinion, whether it’s simple routing (NAT?) to both servers or forwarding packets to both servers after port mirroring, as long as the same UDP packets are forwarded to both servers, the goal will be achieved. I’m new to VyOS, so this is my first time dealing with these settings.
If someone could provide guidance on the setup, it would be really helpful.
For example, if I set up the following configuration to forward traffic using DNAT to only one side, I should be able to verify UDP traffic on the destination server using tcpdump. However, if the packets are not arriving, there might be an issue.
vyos@vyos# set nat destination rule 10 description ‘DNAT to backend server’
vyos@vyos# set nat destination rule 10 destination port ‘4789’
vyos@vyos# set nat destination rule 10 inbound-interface name eth0
vyos@vyos# set nat destination rule 10 protocol ‘udp’
vyos@vyos# set nat destination rule 10 translation address ‘10.0.0.100’
vyos@vyos# set nat destination rule 10 translation port ‘4789’
vyos@vyos# commit
To me that sounds more of a case of port-mirroring (and can be done without involving multicast):
https://docs.vyos.io/en/latest/configuration/interfaces/ethernet.html#port-mirror-span
Nftables (used by VyOS since 1.4 I think) also have the capability to mirror specific packets/flows but I dont know if that command is exposed through VyOS config:
https://wiki.nftables.org/wiki-nftables/index.php/Duplicating_packets
The port mirroring was configured as described in the document you provided, and packet mirroring from eth0 to eth1 is successfully working. However, the forwarding to the backend servers is still not happening. Is there anything else I should check?
set nat destination rule 10 description ‘DNAT to backend server 1’
set nat destination rule 10 destination port ‘4789’
set nat destination rule 10 inbound-interface name eth1
set nat destination rule 10 protocol ‘udp’
set nat destination rule 10 translation address ‘10.0.0.100’
set nat destination rule 10 translation port ‘4789’
set nat destination rule 20 description ‘DNAT to backend server 2’
set nat destination rule 20 destination port ‘4789’
set nat destination rule 20 inbound-interface name eth1
set nat destination rule 20 protocol ‘udp’
set nat destination rule 20 translation address ‘10.0.1.100’
set nat destination rule 20 translation port ‘4789’
commit
I may be wrong, but I don’t believe the Linux kernel includes the capability for unicast to multicast translation. At least in the past, a separate daemon was required for this.
The term “mirroring” is probably being used too liberally here, and it doesn’t smell like that is what you are looking for. The first link that @Apachez posted above is “mirroring”, which is standard ingress/egress mirroring implemented on the TC subsystem. The mirrored packet will not touch any Netfilter hooks, so you will not to be able to do anything in NFT with it (e.g NAT). That second link is probably what you want… packet “replication/duplication” where you can rewrite the destination on the duplicated packet. As was already stated, I don’t think vyos has commands for this, so you’d likely need to add the rules in NFTables manually.
1 Like
Is the first mirroring method using Linux traffic control? As I was testing, I found out that when using two Ethernet interfaces (eth0, eth1) on my VyOS router, separate settings are needed for copying the internal Ethernet interface traffic to send it externally.
It seems that VyOS internally uses nft, so I thought this could be resolved with settings, but it’s not easy. Thank you for your response. I’ll have to manually test that second part
In regards to the second link, I tested it but it didn’t work well, so I tried the following. Still, it doesn’t work as intended
nft add table ip mangle
nft add chain ip mangle prerouting_server1 { type filter hook prerouting priority 0 ; }
nft add chain ip mangle prerouting_server2 { type filter hook prerouting priority 0 ; }
nft add rule ip mangle prerouting_server1 udp dport 4789 dup to ip daddr map { 172.16.1.202 : 172.16.1.47 }
nft add rule ip mangle prerouting_server2 udp dport 4789 dup to ip daddr map { 172.16.1.202 : 172.16.2.10 }
Yes the first method uses the traffic control (TC) system for mirroring.This is actual SPAN type mirroring where the packet is mirrored out another interface exactly as it was sent or received (L2/L3 headers and all). It’s only useful where the hosts are directly connected, listening in promiscuous mode, and intended for monitoring/inspection systems.
Try this for the NFT rules:
sudo nft add table ip duplicate
sudo nft add chain ip duplicate input ‘{ type filter hook prerouting priority filter ; policy accept; }’
sudo nft add rule ip duplicate input ip daddr 172.16.1.202 udp dport 4789 dup to 172.16.1.47 dup to 172.16.2.10
The table should end up looking like:
$ sudo nft list table ip duplicate
table ip duplicate {
chain input {
type filter hook prerouting priority filter; policy accept;
ip daddr 172.16.1.202 udp dport 4789 dup to 172.16.1.47 dup to 172.16.2.10
}
}
The nft syntax you provided was applied without any errors. However, I still haven’t received the packets on the two servers. Both servers have the firewall allowing port 4789, and I also confirmed ‘net.ipv4.ip_forward = 1’ on the server where the nft command was used. If you have any experience with this command, is there anything else I should check?
It could be a number of things so it’s hard to say. I would probably start by adding a “counter” to those NFT rules to make sure they are indeed being hit, and then also make sure you don’t have any other rules in place (e.g the NAT you referenced previously) that may be interfering, and then just use tcpdump to see where traffic is occurring, or if you see any traffic replicated at all. Vyos does have a tcpdump wrapper… e.g: monitor traffic interface any filter “port 4789”. Or tcpdump can be called directly.
In any case, it seems difficult to send duplicated packets to the outside through conventional means
Worth trying a trick from the WOL book:
Port forward to subnet broadcast address , like 192.168.1.255
Add static MAC entry ff.ff.ff.ff.ff.ff.ff for 192.168.1.255
Now entire network receives the traffic.
1 Like