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

wenxu wenxu at ucloud.cn
Mon Jan 16 06:23:00 UTC 2017


Hi all,

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

# 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'

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)

I  found that icmp can work. 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/61b8c039/attachment-0001.html>


More information about the discuss mailing list