search

sonic-net / sonic-swss

SONiC Switch State Service (SwSS)
https://azure.github.io/SONiC
Other
170 stars 510 forks source link

[NAT] ICMP reply packet cannot forward in dynamic NAPT #1351

Closed chaoskao closed 3 years ago

chaoskao commented 4 years ago

Description ICMP packet should perform NAT on both request/reply in dynamic NAPT, but in our test only received NATed ICMP request packet but switch cannot forward ICMP reply packet

Steps to reproduce the issue: Configuration:

config nat feature enable config nat add interface Ethernet0 -nat_zone 0 config nat add interface Ethernet4 -nat_zone 1

config interface ip add Ethernet0 172.10.0.3/16 config interface ip add Ethernet4 172.27.0.3/16 ip route add 140.0.0.0/16 via 172.27.0.5 ip neigh add 172.10.0.101 lladdr 00:11:11:00:00:01 dev Ethernet0 ip neigh add 172.27.0.5 lladdr 00:11:11:00:00:09 dev Ethernet4

config nat add pool nat_pool 172.27.0.101 101-103 config nat add binding nat_test nat_pool

Topology:

+-----+       +----------------+       +-----+
| PC1 | +---> |     Device     | +---> | PC2 |
+-----+       +----------------+       +-----+
           Ethernet0    Ethernet4

Packets injected from PC1: Packet A: source IP address = 172.27.0.101, destination IP address = 140.0.0.101, ICMP requst

Packets injected from PC2: Packet B: source IP address = 140.0.0.101, destination IP address = 172.27.0.101, ICMP reply

Describe the results you received: Packets received at PC2: Packet A: source IP address = 172.27.0.101 (NATed), destination IP address = 140.0.0.101, ICMP request

Packets received at PC1: Packet B: None

Describe the results you expected: Packets received at PC2: Packet A: passed.

Packets received at PC1: Packet B: should receive packet: source IP address = 140.0.0.101, destination IP address = 172.10.0.101 (NATed), ICMP reply

Additional information you deem important (e.g. issue happens only occasionally): Note: another case (dynamic SNAT and static SNAT in same 'twice_nat_id' group) has same problem.

 admin@sonic:~$ show version

    SONiC Software Version: SONiC.master.346-8ea03eed
    Distribution: Debian 10.4
    Kernel: 4.19.0-9-2-amd64
    Build commit: 8ea03eed
    Build date: Sun Jul 12 18:10:30 UTC 2020
    Built by: johnar@jenkins-worker-4

    Platform: x86_64-accton_as7712_32x-r0
    HwSKU: Accton-AS7712-32X
    ASIC: broadcom
    Serial Number: 771232X1909084
    Uptime: 03:35:01 up 2 min,  1 user,  load average: 3.42, 1.40, 0.52

    Docker images:
    REPOSITORY                    TAG                   IMAGE ID            SIZE
    docker-teamd                  latest                5bdc27151693        380MB
    docker-teamd                  master.346-8ea03eed   5bdc27151693        380MB
    docker-router-advertiser      latest                f6374644f094        350MB
    docker-router-advertiser      master.346-8ea03eed   f6374644f094        350MB
    docker-lldp                   latest                e05765635c6a        377MB
    docker-lldp                   master.346-8ea03eed   e05765635c6a        377MB
    docker-dhcp-relay             latest                a608b2765e7e        357MB
    docker-dhcp-relay             master.346-8ea03eed   a608b2765e7e        357MB
    docker-database               latest                9980932086f5        350MB
    docker-database               master.346-8ea03eed   9980932086f5        350MB
    docker-orchagent              latest                f6a438e40754        393MB
    docker-orchagent              master.346-8ea03eed   f6a438e40754        393MB
    docker-sonic-telemetry        latest                46aad5a40cf9        414MB
    docker-sonic-telemetry        master.346-8ea03eed   46aad5a40cf9        414MB
    docker-sonic-mgmt-framework   latest                153f5b212b31        473MB
    docker-sonic-mgmt-framework   master.346-8ea03eed   153f5b212b31        473MB
    docker-sflow                  latest                accd44e81959        383MB
    docker-sflow                  master.346-8ea03eed   accd44e81959        383MB
    docker-snmp                   latest                f7f8604477ca        390MB
    docker-snmp                   master.346-8ea03eed   f7f8604477ca        390MB
    docker-syncd-brcm             latest                36db5c9c35f6        442MB
    docker-syncd-brcm             master.346-8ea03eed   36db5c9c35f6        442MB
    docker-platform-monitor       latest                0b6901e8073f        358MB
    docker-platform-monitor       master.346-8ea03eed   0b6901e8073f        358MB
    docker-nat                    latest                3636bd7994a4        317MB
    docker-nat                    master.346-8ea03eed   3636bd7994a4        317MB
    docker-fpm-frr                latest                628c62893a8e        335MB
    docker-fpm-frr                master.346-8ea03eed   628c62893a8e        335MB
monipko commented 4 years ago

@chaoskao we do not observe this behavior with your steps. Do you have created dynamic NAT entry(i.e. perform TCP handshake) for PC1 -> PC2? We observe another issue with ICMP traffic, please take a look SNAT does not perform translation for ICMP packet in static NAT/NAPT

chaoskao commented 4 years ago

@monipko No, I send ICMP packet from PC1 -> PC2, why need to handshake first? It's ICMP packet should be perform NAT by iptables.

AkhileshSamineni commented 4 years ago

@chaoskao @monipko

I have verified the ICMP echo request and echo reply with the same configuration and I didn't see any issue here.

ICMP using Dynamic NAPT, it translates the IP-address and also Identifier (ID) in the ICMP packets.

IP-Tables output after addition pool and binding:

root@sonic:/home/admin# iptables -t nat -nvL Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination
1 36 DNAT all -- 0.0.0.0/0 0.0.0.0/0 to:1.1.1.1 fullcone

Chain INPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 8 packets, 720 bytes) pkts bytes target prot opt in out source destination

Chain POSTROUTING (policy ACCEPT 7 packets, 660 bytes) pkts bytes target prot opt in out source destination
1 60 SNAT tcp -- 0.0.0.0/0 0.0.0.0/0 mark match 0x2 to:172.27.0.101:101-103 fullcone 0 0 SNAT udp -- 0.0.0.0/0 0.0.0.0/0 mark match 0x2 to:172.27.0.101:101-103 fullcone 0 0 SNAT icmp -- 0.0.0.0/0 0.0.0.0/0 mark match 0x2 to:172.27.0.101:101-103 fullcone

Chain DOCKER (0 references) pkts bytes target prot opt in out source destination
root@sonic:/home/admin#

Packets injected from PC1: Packet A: source IP address = 172.10.0.101, destination IP address = 140.0.0.101, ICMP request with Identifer as 1.

Packets received at PC2: Packet A: source IP address = 172.27.0.101 (NATed), destination IP address = 140.0.0.101, ICMP request with Identifer as 101 (NATed).

Conntrack NAT output after Packet A :

root@sonic:/home/admin# conntrack -j -L tcp 6 75 SYN_SENT src=10.0.0.36 dst=10.0.0.37 sport=43216 dport=179 [UNREPLIED] src=10.0.0.37 dst=172.27.0.101 sport=179 dport=103 mark=0 use=1 icmp 1 25 src=172.10.0.101 dst=140.0.0.101 type=8 code=0 id=1 [UNREPLIED] src=140.0.0.101 dst=172.27.0.101 type=0 code=0 id=101 mark=0 use=1
conntrack v1.4.4 (conntrack-tools): 2 flow entries have been shown.
root@sonic:/home/admin#

Packets injected from PC2: Packet B: source IP address = 140.0.0.101, destination IP address = 172.27.0.101, ICMP reply with Identifier as 101.

Packets received at PC1: Packet B: source IP address = 140.0.0.101, destination IP address = 172.10.0.101 (NATed), ICMP reply with Identifier as 1.

If you send the ICMP Reply Packet B from PC2 with Identifer as 1, then Packet B won't get translated.

Conntrack NAT output after Packet B :

root@sonic:/home/admin# conntrack -j -L tcp 6 74 SYN_SENT src=10.0.0.36 dst=10.0.0.37 sport=43290 dport=179 [UNREPLIED] src=10.0.0.37 dst=172.27.0.101 sport=179 dport=103 mark=0 use=1 icmp 1 13 src=172.10.0.101 dst=140.0.0.101 type=8 code=0 id=1 src=140.0.0.101 dst=172.27.0.101 type=0 code=0 id=101 mark=0 use=1 conntrack v1.4.4 (conntrack-tools): 2 flow entries have been shown. root@sonic:/home/admin#

I suspect the Identifier field in your ICMP reply packet is not updated, could you please check it ?

arlakshm commented 3 years ago

@chaoskao, based on the analysis from @AkhileshSamineni, looks like there is no issue. Please double check and close this issue

googleweb commented 2 years ago

if you only send reply packet ，data can not pass gateway ,command is

sudo nping --icmp -c 100 --icmp-type 0 --icmp-code 0 --source-ip 192.168.231.128 --dest-ip 1.116.7.10 --icmp-id 48879 --icmp-seq 114 --data-string 'client'

i think gateway create nat record only with request packet. reply packet do not create ,and find nothing record,will drop packet.