[ovs-discuss] Conntrack and unexpected change in source IP

Ben Pfaff blp at ovn.org
Tue May 7 22:10:13 UTC 2019


On Tue, May 07, 2019 at 02:30:25PM -0700, Thiago Santos wrote:
> On Tue, May 7, 2019 at 1:58 PM Ben Pfaff <blp at ovn.org> wrote:
> 
> > On Tue, May 07, 2019 at 12:05:43PM -0700, Thiago Santos wrote:
> > > Hello,
> > >
> > > I've been using OVS Conntrack integration for Source NAT and setting the
> > > Destination IP directly but this is having the side effect of overwriting
> > > the Conntrack set SNAT IP. I simplified my rules to look like this to
> > > reproduce the problem:
> > >
> > > cookie=0x0, duration=90070.633s, table=0, n_packets=32266,
> > > n_bytes=48644792, idle_age=1716, hard_age=65534,
> > > ip,in_port=1,nw_dst=1.1.1.2 actions=ct(table=1,zone=2,nat)
> > > cookie=0x0, duration=89993.501s, table=1, n_packets=32266,
> > > n_bytes=48644792, idle_age=1716, hard_age=65534,
> > > ct_state=+new+trk,ip,in_port=1,nw_dst=1.1.1.2
> > > actions=ct(commit,zone=2,nat(src=10.1.1.1)),resubmit(,2)
> > > cookie=0x0, duration=1757.194s, table=2, n_packets=0, n_bytes=0,
> > > idle_age=1757, priority=601,ip,nw_src=10.10.10.10 actions=drop
> > > cookie=0x0, duration=1808.236s, table=2, n_packets=5361, n_bytes=8105832,
> > > idle_age=1716, priority=600,ip actions=mod_nw_dst:10.1.1.2,output:2
> > >
> > > If I change the last 2 rules priorities so that they are in reverse
> > order,
> > > it seems to work.
> > >
> > > ovs-appctl dpctl/dump-flows shows me this:
> > > recirc_id(0x2),ct_state(+new+trk),eth(),eth_type(0x0800),ipv4(src=
> > > 0.0.0.0/248.0.0.0,dst=1.1.1.2,frag=no), packets:59, bytes:89208,
> > > used:0.168s, actions:ct(commit,zone=2,nat(src=10.1.1.1)),set(ipv4(src=
> > > 0.0.0.0/248.0.0.0,dst=10.1.1.2)),4
> > >
> > > So it looks like it is doing a set on the source IP because of the
> > matching
> > > on source IP of the 3rd rule above. Is there a way around this or am I
> > > doing something wrong?
> >
> > Here's an easier to read table:
> >
> > 0 32768 ip,in_port=1,nw_dst=1.1.1.2
> >         actions=ct(table=1,zone=2,nat)
> >
> > 1 32768 ct_state=+new+trk,ip,in_port=1,nw_dst=1.1.1.2
> >         actions=ct(commit,zone=2,nat(src=10.1.1.1)),resubmit(,2)
> >
> > 1   601 ip,nw_src=10.10.10.10
> >         actions=drop
> >
> > 1   600 ip
> >         actions=mod_nw_dst:10.1.1.2,output:2
> >
> > Indeed, if nw_src is 10.10.10.10, the packet gets dropped.  That's what
> > the flow table says.  Can you explain what you expect?
> >
> 
> If the packet is to hit the last rule, sending a packet with source IP
> 1.1.1.1 and destination IP 1.1.1.2, the result should be a packet with
> source ip 10.1.1.1 and destination ip 10.1.1.2 but the source IP ends up
> being 2.1.1.1 because of the masked source IP set in the datapath rule.
> 
> I believe it builds that without considering what the conntrack would be
> setting to the source IP when it does the NAT.

Thanks for the clarifications, I missed some things.  ct isn't my
specialty.

This use of ct breaks the rules, documented in ovs-action(7), which say
that 'commit' and 'nat' may not be used together.  I don't know what is
supposed to happen in this case.  Maybe OVS should disallow it entirely,
or maybe the documentation should be updated.


More information about the discuss mailing list