My network topology is as follows - enter image description here

My problem, is that the Purple Red Green and Orange PC's are actually hard coded industrial systems, and i have no possibility of changing any settings on them.

I require to intercept and manipulate the UDP packets with the addition of the interception PC.

Example - RED PC sends a UDP packet to the purple PC. This actually arrives at my Interception PC (Ubuntu 16.04) where i receive and reply to the packet. I then construct a different message and deliver to the purple PC.

The problem is, that the network is all on the same subnet, and the kernel has no idea which NIC to send my outgoing packet as i already own the ip i am trying to forward to.

I have tried creating separate namespaces to own the NICS , and wrote several separate processes to communicate via Dbus between the namespaces, before realising they can not communicate. I can purchase more hardware if required, but im looking for suggestions about how i might achieve this outcome.

  • If the problem is just knowing which interfaces the ip addresses are on, then you can just set /32 single ip static routes. Apr 13, 2018 at 12:43
  • Do the red, green, and orange PCs really need to talk to the interception PC via separate NICs? Can't you put a switch there instead? Apr 13, 2018 at 13:01
  • @RobotHumans - Yes i can attach a switch at this location, and forward all traffic to a different ip address at the interception PC. However i have a couple of queries - i need still visible to the RGO pc's, and i am wondering if packets destined for the purple will still be forwarded in the wrong direction. My second query is that effectively a router is a group of nic's so i'm wondering why i cant locally achieve the same goal. I do appreciate the suggestion though and i will test this option and report back.
    – Wharbio
    Apr 13, 2018 at 14:13
  • It's achievable, it's just not plug and play. It's the same reason cable installers come to your house instead of just saying "line's hot" over the phone. Apr 13, 2018 at 15:19

2 Answers 2


Yes, using a network namespace to isolate the two "same" networks would work.

For example, you have one network namespace for the right-hand side, with all the three interfaces in that namespace, and in addition, you have a bridge in the namespace and a tap for the traffic interception and forwarding. Add the tap and the three NICs to the bridge, and assign only to the tap. Thus, no IP assignments to the NICs; only to the tap. The bridge will take care of channeling all traffic to on the right-hand side to the tap, and all traffic to 192.168.0.{20,21,22} through the apprioriate NICs.

Write your interception program to read/write the tap (Level 2), and forward packets through stdin/stdout (unbuffered). Also write a similar simple transfer program to channel stdin/stdout packets to/from a tap (another tap), which you put in the left-hand side global namespace. The programs must forward all packets, with your interception applied to some of them.

The left-hand side namespace (the global namespace) is arranged in a corresponding way, with a bridge for the NICs and a tap, and then add all the IP addresses 192.168.0.{20,21,22} to the tap.

Next, use the dpipe program from the vde2 package (or write your own) to start the two tap connectors such that their stdin/stdout are mutually connected. With dpipe the command for this would be something like the following:

# dpipe program1 tap1 = ip netns exec RHS program2 tap2

for the effect that stdout of program1 goes to stdin of program2, and stdout of program2 goes to stdin of program1. (I've included notionally tap name arguments for the programs just for the sake of illustration)

All in all, that would be a way to intercept and transfer packets between the two namespaces without needing to mess with IP translations.

Note that the set up would work equally well with a single NIC at each side, plus a switch on the right. Thus, there is no need for two triplets of NICs, but you can get away with just two: one to the left and one to the right, plus of course a switch for the right-hand side network, which has 4 physical hosts.

  • - Thanks Ralph. i was hesitant to spend too much more time on the namespace solution without some confirmation that it can be done. I'll attempt this setup next.
    – Wharbio
    Apr 13, 2018 at 14:08
  • I edited the answer to include the required "ip netns" part that makes program2 execute within the right-hand side network namespace. Apr 14, 2018 at 0:49
  • 1
    Just some feedback for those who helped me out, Ralph i used your advice, and after discovering network namespaces on Linux were handled per thread, i managed to merge the it into a single application, using setns() on separate threads. I created sockets per thread also, and i can now talk to each NIC separately, albeit with some small multithreading overheads. Thanks all.
    – Wharbio
    Apr 16, 2018 at 14:30

I unable to comment, so adding another answer. I'm writing from my own experience : it is absolutely doable with network namespaces, but there is no generic solution. So it would be tighten to the requirement and actual network topology. And in most case will also require writing few scripts to automate such network initialization & configuration.

But again, it absolutely doable

  • Thanks. Mentioned in accepted answer.
    – Wharbio
    Mar 26, 2023 at 22:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .