[ovs-discuss] Changing Destination IP and MAC Address for TCP Connection

[Darrell Ball]

From: <ovs-discuss-bounces at openvswitch.org> on behalf of karthik karra <karrakarthik88 at gmail.com>
Date: Thursday, December 6, 2018 at 5:35 PM
To: "ovs-discuss at openvswitch.org" <ovs-discuss at openvswitch.org>
Subject: [ovs-discuss] Changing Destination IP and MAC Address for TCP Connection

Hi All,

I have three VMs
VM1 - 192.168.1.101
VM2 - 192.168.1.102
VM3 - 192.168.1.103
I am using netcat for testing the flows between the VMs.

My scenario is, the netcat server listens on both VM2 and VM3. From VM1, I will provide "nc <vm2_ip_address> <listen_port>".
But I have a rule in OVS which mentions if source IP is VM1 and destination IP is VM2, then change the destination IP and MAC address to the VM3's such that the flow is redirected to the VM3.

This is working fine for UDP flows.

>>>>>>> really ?

For TCP, when I have searched for solution, I have found conntrack. I am using OVS 2.6 version as I have seen in one of the videos that from this version it supports the conntrack in user data path.


>>>>>> What is the o/p of  ‘sudo ovs-vsctl get bridge <your bridge name> datapath_type’ ?

>>>>>> What is the o/p ‘sudo ovs-vsctl show’ ?


This is the flow rule I am using to match and change the addresses for TCP. I have followed the conntrack tutorial provided in OVS site.
ovs-ofctl add-flow ovs_bridge "table=0,priority=50,ct_state=-trk,tcp,nw_src=192.168.1.101,nw_dst=192.168.1.102,tp_dst=8001,idle_timeout=0,actions=ct(table=0),mod_nw_dst=192.168.1.103,mod_dl_dst=08:00:27:be:ce:e0,normal

>>>>>> Are you trying to use conntrack for NATing or you don’t care ?; right now, you are doing NAT outside of conntrack and
              anyways conntrack NAT is not in 2.6, assuming you are really using the userspace datapath ?

>>>>>> The above rule sends a packet thru conntrack that will not be very successful, but another copy of the packet will be subjected to nw_dst/dl_dst
              modification and be sent to the other VMs
               Normally endpoints talk bidirectionally, but your one rule seems to imply otherwise; can you explain ?
               What is the full o/p of ‘sudo ovs-ofctl dump-flows <your bridge name> ?

The SYN packet is still being sent to 102 rather than to 103.

>>>>>>  You mean the addresses are changed but the packet goes to VM3 or the addresses are not even changed from your POV ?
             Maybe the mac binding is not what you expect; first try sending to the openflow port of VM3 in
             the above rule first and see if that works; i.e.  change ‘normal’ to the ‘VM3 port’
             You could check ‘sudo ovs-appctl dpif/dump-flows <your bridge name>’

I have read that even the order of actions is important and I have put the "ct(table=0)" at the end. But its of no use.

Can anybody please help.

Thanks
Karra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-discuss/attachments/20181207/784b476a/attachment-0001.html>