拓扑如下：
环境描述：
内网两个网段通过防火墙的NAT功能上网，内部WEB服务器：10.1.20.200 映射到公网80端口，配置信息如下：
acl number 2000 description NAT_SOURCE rule 5 permit source 10.1.20.0 0.0.0.255 rule 10 permit source 192.168.10.0 0.0.0.255
interface GigabitEthernet0/0 port link-mode route nat outbound 2000 nat server 20 protocol tcp global current-interface 80 inside 10.1.20.200 80 ip address 124.133.33.223 255.255.255.0
interface GigabitEthernet0/1 port link-mode route ip address 172.19.10.253 255.255.255.0
经过以上配置后，公网可正常访问WEB服务器，但如果内网用户使用公网地址124.133.33.223访问WEB服务器时会失败，网上大多数参考资料分析的流量过程如下图：
分析：
客户端发出的请求经过防火墙的映射转换，修改了数据包的目的地址，数据最终由WEB服务器直接发送到了客户端，而此回复被客户端判定为非法的（请求的是124.133.33.223但得到的10.1.20.200的回复），导致访问失败。
我使用的H3C F100-SG 防火墙， 在10.1.20.200 WEB服务端通过抓包发现，此过程并未发生，即客户端的请求数据并未达到WEB服务端，而是在达到防火墙后便中断了传输。此现象说明，数据包在到达防火墙之后，防火墙并未做相应的端口映射操作，而是经过了路由判断之后作为访问本地的服务进行了处理。
说明：正常情况下，访问124.133.33.223的80端口会经过映射转换，但此时并未发生，而是直接当做访问本地80端口这一操作进行了处理，例如： 如果防火墙的web管理端口是80，此时我们内网通过公网地址访问80端口时，会得到防火墙的web管理界面，此操作已经过实验证实。
其实通过配置信息也能看出来，我的DNAT是在WAN（0/0）口上做的配置，外网用户的请求从此端口进入首先会经过DNAT的映射转换，然后经过路由判断之后转发给了WEB服务器，而内部客户端的流量是从LAN（0/1）口进入，所以并未发生DNAT转换，而是直接进行了路由判断（发送给自己，自己处理）。
以上现象流量图如下：
如果想实现内网客户端正常访问WEB服务器，首先要做的就是实现DNAT的转换，既然此配置只在所属接口上起作用，那么就在LAN口上做一下配置即可； 实现此操作之后，流量便引到了WEB服务器上，即文章中第二张图所显示的流量过程，此时访问失败的原因就是WEB服务器直接回复了客户端的请求，如果让WEB服务器的回复数据再次经过防火墙，并进行DNAT的映射还原操作即可，我们通过配置LAN口的SNAT来实现，配置如下（其他配置不变，只修改LAN口配置）：
interface GigabitEthernet0/1 port link-mode route nat outbound 2000 nat server 20 protocol tcp global 124.133.33.223 80 inside 10.1.20.200 80 ip address 172.19.10.253 255.255.255.0
流量图如下：
客户端的请求流量被防火墙的DNAT引到WEB服务器，因为防火墙的之前的SNAT操作，使得WEB服务器的回复数据必须再次经过防火墙，防火墙经过NAT的映射关系进行还原操作，最终回复数据达到客户端。