netdev - Re: [RFC PATCH 5/5] openvswitch: Interface with NAT.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 21 Oct 2015 16:42:12 +0200
From:	Florian Westphal <fw@...len.de>
To:	Thomas Graf <tgraf@...g.ch>
Cc:	Florian Westphal <fw@...len.de>,
	Jarno Rajahalme <jrajahalme@...ira.com>,
	netdev@...r.kernel.org, dev@...nvswitch.org
Subject: Re: [RFC PATCH 5/5] openvswitch: Interface with NAT.

Thomas Graf <tgraf@...g.ch> wrote:
> On 10/21/15 at 11:34am, Florian Westphal wrote:
> > Jarno Rajahalme <jrajahalme@...ira.com> wrote:
> > >  #define OVS_CS_F_REPLY_DIR         0x08 /* Flow is in the reply direction. */
> > >  #define OVS_CS_F_INVALID           0x10 /* Could not track connection. */
> > >  #define OVS_CS_F_TRACKED           0x20 /* Conntrack has occurred. */
> > > +#define OVS_CS_F_SRC_NAT           0x40 /* Packet's source address/port was
> > > +					   mangled by NAT. */
> > > +#define OVS_CS_F_DST_NAT           0x80 /* Packet's destination address/port
> > > +					   was mangled by NAT. */
> > 
> > I'm blind -- how does ovs deal with change of output device and the
> > ether dst mac as result of a l3 dst translation?
> 
> I assume you are referring to rewriting of L2 and the forwarding decision
> after NAT. As NAT is performed in combination with conntrack, the packet
> is recirculated and hits the flow table again after NAT. That 2nd
> stage flow must take are of performing L3 by rewriting L2, decrementing
> TTL, etc.

> Is this what you are referring to?

Yes, exactly, thanks for answering my question.

[ in classic bridge netfilter this requires route lookup & neigh stunts
  to deal with the consequences of dnat, i.e.

- route says dst is reachable via some other interface not part of
bridge
- route says that dst is localhost
- route says its on same bridge, but neigh has no idea what the new
dst mac address is,etc.

I was kinda disappointed to not see similar tur^W hacks ;)
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html