We need to use the below topology and use nft with VRF and perform UDP session hijack in between.
Machine A (udp_client 192.168.21.209) ---- Machine B (udp_server 192.168.217.210 vrf red) ---- Target Server (IP:10.10.10.10 Port:5000)
Machine A:
- Runs a UDP client sending packet to 10.10.10.10:5000
- Route setup to reach 10.10.10.10 via Machine B .
- Traffic is NATed using nft to local ip 192.168.217.210, which receives the packet and sends back a response as if originating from 10.10.10.10.
Machine B:
Step 1: Create a VRF and run a UDP server on port 5000.
ip link add red type vrf table 1
ip link set ens38 master red
ip link set dev red up
ip vrf exec red ./udp_server
Step 2: Create NAT rules using nft to redirect the packets to local ip 192.168.217.210 on which the hijack server is running. It receives the packet and sends back a response as if originating from 10.10.10.10.
table ip nat {
chain prerouting {
type nat hook prerouting priority -150; policy accept;
udp dport 5000 dnat to 192.168.217.210
}
chain postrouting {
type nat hook postrouting priority -150; policy accept;
}
}
Problem Behavior
In the incoming direction, DNAT rule is matched and the following conntrack entry is created.
udp 17 13 src="" dst=10.10.10.10 sport=42940 dport=5000 src="" dst=192.168.217.209 sport=5000 dport=42940 mark=0 use=1 à Correct DNAT rule
When the reply packet is generated, it hits the reverse of the above entry in postrouting hook (with vrf device as the egress) and the packet is now correctly modified with source address 10.10.10.10:5000 and sent to 192.168.217.209:42940. However, NAT happens a second time (this time with the physical interface as the egress, again in postrouting hook) and another extraneous flow is created with source port NAT as below. The packet is now modified to have source address 10.10.10.10:1024 instead of 10.10.10.10:5000. This creates problems for the UDP client as it is not the expected source port for that application.
udp 17 13 src="" dst=192.168.217.209 sport=5000 dport=42940 [UNREPLIED] src="" dst=10.10.10.10 sport=42940 dport=1024 mark=0 use=1 à Additional SNAT mapping generated while reply is sent out
Any suggestions on the reason for the above behavior and how to overcome it would be appreciated.
Thanks
Anand
