[ovs-discuss] ovs2.6.0 conntrack and nat problem with RST?

wenxu wenx05124561 at 163.com
Mon Jan 16 06:37:51 UTC 2017


Hi all,

I meet a problem with conntrack and nat. Ovs-nat combined with commit (confirm in kernel),  so I want to do stateful firewall with conntrack then do nat


There is a simple test as fllow.

netns1 port1 has ip 10.0.0.7
netns2 port2 has ip 1.1.1.7

10.0.0.7 can access  icmp and tcp-dst_port 123 of 1.1.1.7  with src nat 2.2.1.7 (please just ignore L2 operation)


# ovs-ofctl add-flow br0  'ip,in_port=1 actions=ct(table=1,zone=1)'
# ovs-ofctl add-flow br0  'ip,in_port=2 actions=ct(table=1,zone=1)'
# ovs-ofctl add-flow br0  'ct_state=+new+trk,tcp,in_port=1,tp_dst=123 actions=ct(commit,zone=1,nat(src=2.2.1.7)),output:2'
# ovs-ofctl add-flow br0  'table=1, ct_state=+new+trk,icmp,in_port=1 actions=ct(commit,zone=1,nat(src=2.2.1.7)),output:2'
# ovs-ofctl add-flow br0  'table=1, ct_state=+est+trk,ip,in_port=2 actions=ct(commit,zone=1,nat(dst=10.0.0.7)),output:1'
# ovs-ofctl add-flow br0  'table=1, n_packets=27, ct_state=+est+trk,ip,in_port=1 actions=ct(commit,zone=1,nat(src=2.2.1.7)),output:2'


I  found that icmp can work and tcp-port 123 also can work when there is an 123 port listen on 1.1.1.7

But if there is no listen 123 port, The first RST packet reply by 1.1.1.7 (no datapath kernel rule) can't do dst-nat to 10.0.0.7.  The second one is ok.

# tcpdump -i eth0 -nnn
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
14:44:13.575200 IP 10.0.0.7.39891 > 1.1.1.7.123: Flags [S], seq 935877775, win 29200, options [mss 1460,sackOK,TS val 584707316 ecr 0,nop,wscale 7], length 0
14:44:13.576036 IP 1.1.1.7.123 > 2.2.1.7.39891: Flags [R.], seq 0, ack 935877776, win 0, length 0
14:44:14.576573 IP 10.0.0.7.39891 > 1.1.1.7.123: Flags [S], seq 935877775, win 29200, options [mss 1460,sackOK,TS val 584708318 ecr 0,nop,wscale 7], length 0
14:44:14.576657 IP 1.1.1.7.123 > 10.0.0.7.39891: Flags [R.], seq 0, ack 935877776, win 0, length 0

But I check the datapath flow is correct
# ovs-dpctl dump-flows
recirc_id(0),in_port(7),eth_type(0x0800),ipv4(frag=no), packets:0, bytes:0, used:never, actions:ct(zone=1),recirc(0x5a)
recirc_id(0x5a),in_port(7),ct_state(+new+trk),eth_type(0x0800),ipv4(proto=6,frag=no),tcp(dst=123), packets:0, bytes:0, used:never, actions:ct(commit,zone=1,nat(src=2.2.1.7)),8
recirc_id(0),in_port(8),eth_type(0x0800),ipv4(frag=no), packets:0, bytes:0, used:never, actions:ct(zone=1),recirc(0x5b)
recirc_id(0x5b),in_port(8),ct_state(-new+est+trk),eth_type(0x0800),ipv4(frag=no), packets:0, bytes:0, used:never, actions:ct(commit,zone=1,nat(dst=10.0.0.7)),7

I think it maybe a problem of packet-out and RST?

If I did the nat first then stateful firewall, it' ok for this case. But I think if the packet is reject by firewall, should not be confirm to kernel.



BR
wenxu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-discuss/attachments/20170116/4147fc81/attachment.html>


More information about the discuss mailing list