Hi,
I think there is a problem in ip4_sv_reass_inline(), it does not consider
ip.save_rewrite_length when it calculates is_non_first_fragment at line 619
(master):
vnet_buffer (b0)->ip.reass.is_non_first_fragment =
! !ip4_get_fragment_offset (vlib_buffer_get_current (b0));
Let me open a pull request to fix this.
Thanks,
Miklos
________________________________
From: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> on behalf of Miklos Tirpak via
lists.fd.io <miklos.tirpak=emnify....@lists.fd.io>
Sent: Tuesday, May 26, 2020 9:25 AM
To: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io>
Subject: [vpp-dev] NAT44 does not work with fragmented ICMP packets
CAUTION: This email originated from outside of the organization. Do not click
links or open attachments unless you recognize the sender and know the content
is safe.
Hi,
we have a scenario where an ICMP packet arrives fragmented over a GTP-U tunnel.
The outer IP packets are not fragmented, only the inner ones are. After GTP-U
decapsulation, the packets are routed via an interface where NAT44
output-feature is configured.
In the outgoing packets, the source IP is correctly NATed but the ICMP
identifier (port) is not changed. Hence, the NAT session cannot be found for
the ICMP reply. This works correctly with smaller packets, the problem is only
with fragmented ones.
I could reproduce this with both VPP 20.01 and master, and could see that
ip.reass.is_non_first_fragment is true for every packet. Therefore,
icmp_in2out() does not update the ICMP header I think.
712 if (!vnet_buffer (b0)->ip.reass.is_non_first_fragment)
(gdb) p ((vnet_buffer_opaque_t *) (b0)->opaque)->ip.reass
$17 = {{{next_index = 1056456440, error_next_index = 0}, {owner_thread_index =
270}}, {{{l4_src_port = 16120,
l4_dst_port = 16120, tcp_ack_number = 0, save_rewrite_length = 14
'\016', ip_proto = 1 '\001',
icmp_type_or_tcp_flags = 8 '\b', is_non_first_fragment = 1 '\001',
tcp_seq_number = 0}, {estimated_mtu = 16120}}}, {
fragment_first = 16120, fragment_last = 16120, range_first = 0, range_last
= 0, next_range_bi = 17301774,
ip6_frag_hdr_offset = 0}}
The node trace seems to be fine:
... ip4-lookup -> ip4-rewrite -> ip4-sv-reassembly-output-feature ->
nat44-in2out-output -> nat44-in2out-output-slowpath
The NAT session is also correct, it includes the new port:
DBGvpp# sh nat44 sessions detail
NAT44 sessions:
-------- thread 0 vpp_main: 0 sessions --------
-------- thread 1 vpp_wk_0: 1 sessions --------
100.64.100.1: 1 dynamic translations, 0 static translations
i2o 100.64.100.1 proto icmp port 63550 fib 1
o2i 172.16.17.2 proto icmp port 16253 fib 0
index 0
last heard 44.16
total pkts 80, total bytes 63040
dynamic translation
Do you know if this is a configuration issue or a possible bug? Thank you!
Thanks,
Miklos
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#16488): https://lists.fd.io/g/vpp-dev/message/16488
Mute This Topic: https://lists.fd.io/mt/74473306/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
