Here is a post published by created a markdown file.
Problem Description:
The service at 192.168.10.24:5010 needs to be accessible via a WAN IP (115.x.x.x) for users from the Untrust Zone (Internet), Zone1 (192.168.20.x), and Zone2 (192.168.10.x). The Destination NAT policy has been configured (Any to 115.x.x.x:5010 NAT to Any to 192.168.10.24:5010), and the Security Policy has been bypassed. While 115.x.x.x:5010 is accessible from the Untrust Zone (Internet) and Zone1 (192.168.20.x), it is not accessible from Zone2 (192.168.10.x). Refer to the simplified network diagram below.
Analysis and Validation:
The Destination NAT Policy and Security Policy seem to be functioning correctly, as evidenced by the accessibility of 115.x.x.x:5010 from the Internet and 192.168.20.0/24. However, the issue arises with users from the same subnet as the server(192.168.10.0/24.).
The problem only occurs with users of the same subnet of the server. One possible explanation is that when 192.168.10.24 sends a packet back (SYN+ACK) to 192.168.10.19, the packet (SYN+ACK) is directly sent to 192.168.10.19, instead of going through the firewall. This occurs because the source IP and destination IP are within the same subnet.
So the packet has not been processed by NAT of the Firewall, the source IP of back-packet (SYN+ACK) is 192.168.10.24. That makes 192.168.10.19 confused. It might think: Wait! 192.168.10.24? who are you? I don’t want to talk to you, I am talking with 115.x.x.x !
These suspicions were confirmed by analyzing captured network packets on 192.168.10.19 using Wireshark.
Packet No.266 is the wrong-way packet.
Solution:
To address this issue, the SYN+ACK packet needs to be sent back to the firewall and processed by NAT.
The following NAT Policy can make the SYN+ACK packet return to the firewall and then be processed by NAT.
| SRC ip | DST IP&Port | NAT To | SRC ip | DST IP&Port |
|---|---|---|---|---|
| 192.168.10.0/24 | 115.x.x.x:5010 | → | Gatway of 192.168.10.0/24 | 115.x.x.x:5010 |