<div style="line-height:1.7;color:#000000;font-size:14px;font-family:Arial"><div style="line-height:1.7;color:#000000;font-size:14px;font-family:Arial">Hi all,<br><br>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<br><br># ovs-ofctl add-flow br0 'ip,in_port=1 actions=ct(table=1,zone=1)'<br># ovs-ofctl add-flow br0 'ip,in_port=2 actions=ct(table=1,zone=1)'<br># 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'<br># 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'<br># 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'<br>#
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'<br><br>netns1 port1 has ip 10.0.0.7<br>netns2 port2 has ip 1.1.1.7<br><br>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)<br><br>I found that icmp can work. tcp-port 123 also can work when there is an 123 port listen on 1.1.1.7 <br><br>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.<br><br># tcpdump -i eth0 -nnn<br>tcpdump: verbose output suppressed, use -v or -vv for full protocol decode<br>listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes<br>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<br>14:44:13.576036 IP 1.1.1.7.123 ><span style="color: rgb(255, 0, 0);"> 2.2.1.7.</span>39891: Flags [R.], seq 0, ack 935877776, win 0, length 0<br>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<br>14:44:14.576657 IP 1.1.1.7.123 > <span style="color: rgb(255, 0, 0);">10.0.0.7</span>.39891: Flags [R.], seq 0, ack 935877776, win 0, length 0<br><br>But I check the datapath flow is correct<br># ovs-dpctl dump-flows <br>recirc_id(0),in_port(7),eth_type(0x0800),ipv4(frag=no), packets:0, bytes:0, used:never, actions:ct(zone=1),recirc(0x5a)<br>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<br>recirc_id(0),in_port(8),eth_type(0x0800),ipv4(frag=no), packets:0, bytes:0, used:never, actions:ct(zone=1),recirc(0x5b)<br>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<br><br><span style="color: rgb(255, 0, 0);">I think it maybe a problem of packet-out and RST</span>?<br><br>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><br><br><br>BR<br>wenxu</div></div>