Topology
The topology can be saved locally, and then enlarged to view, so that it can be seen more clearly. (Drag to a new window to open it)
NAT Server test
Note: The NAT Server function was previously deployed, and 2 addresses were translated, providing corresponding WWW service and FTP service. Currently using the external network for testing.
Intranet test whether it can be accessed normally
Note: You can see that the two services are already normal.
Corresponding service for external PC access [Telecom]
The firewall has corresponding NAT session information,
WEB can't be accessed through normal FTP
Corresponding service for external PC access [Netcom]
The public network address is still used as the role of external network access.
The same cannot be opened.
Question: Why is HTTP accessible, but FTP access fails.
Note: Because HTTP is a single-channel protocol, and FTP is a multi-channel protocol, it is divided into active and passive modes. It dynamically negotiates a port number and address at the application layer according to different modes, which causes the address to change after NAT. , But the address firewall of the application layer did not perceive it, causing the access to fail.
Solution: [Enable application layer gateway function ALG]
[USG-GW] firewall interzone trust isp_dx
[USG-GW-interzone-trust-isp_dx] detect ftp
[USG-GW] firewall interzone trust isp_lt
[USG-GW-interzone-trust-isp_lt] detect ftp
description: This configuration is to enable the application layer gateway function, which is between trust and 2 ISPs. Note that this bidirectional opening does not distinguish between directions.
It can be seen that after opening, both addresses can be accessed normally.
Extension: If the PPTP server is mapped, there will be problems.
Note: In addition to mapping the port number, the PPTP server also encapsulates GRE. If it is not a one-to-one conversion, there will be problems, so the solution is the same as above, just monitor PPTP inside.
Common problems in the project: how to use public IP or domain name to access internal servers.
Note: During work, it is often necessary to access the server and provide external services. In this case, the customer will remember 2 IPs, one for the internal network and the other for the external network. This is very inconvenient, and it is also very inconvenient. It is not feasible for people who understand IT technology. So what we hope is to access directly through the external IP or domain name.
By default, there is no problem with accessing the intranet address.
Solution [Intra-domain NAT]
1. Define the address pool
[USG-GW] nat address-group 5 200.1.1.1 200.1.1.1
2. NAT within the defined domain
[USG-GW] nat-policy zone trust
Note: The address of the address pool can be defined arbitrarily, and then called in the intra-domain NAT. If it's normal, it can be over here and you can visit normally, but it still doesn't work in this environment.
3. Special attention should be paid in the case of dual ISP+policy routing.
(1) Problem: Dual ISP is bound to Zone
Description: The above two configurations are only suitable for those that are not bound to Zone, that is, the corresponding zone parameter is not added when inputting. If it is not added, it can belong to any zone. If you add it If this is done, only the packet conversion of the zone is processed, and the previously defined ones are bound to the egress ISP, so the traffic from 2 ISPs can only be converted, while the internal traffic cannot be converted normally. This will lead to failure.
Solution: no-reverse
Two binding Trust Zones are added, so that the conversion from Trust can be processed, which is actually a direct conversion within the domain. Only WWW is given here, but FTP is not demonstrated. Note that the no-reverse parameter needs to be added to the same zone, otherwise the configuration will not be possible.
4.
Analysis of the impact of policy routing : If in normal times, the above three configurations can definitely solve the problem. However, in this environment, we also deployed a policy routing, which is prioritized over NAT translation, that is to say, It will be sent according to the next hop specified by the policy routing, so the result is that the access has been converted successfully, but the next hop handed over by the policy routing is lost to the ISP, not the server.
Solution:
1、定义新的ACL
[USG-GW]acl number 3001
[USG-GW-acl-adv-3001]rule deny ip source 192.168.0.0 0.0.255.255 destination 192.168.88.251 0
[USG-GW-acl-adv-3001]rule permit ip source 192.168.19.0 0.0.0.255
[USG-GW-acl-adv-3001]rule permit ip source 192.16.21.0 0.0.0.255
[USG-GW]acl number 3002
[USG-GW-acl-adv-3002]rule deny ip source 192.168.0.0 0.0.255.255 destination 192.168.88.251 0
[USG-GW-acl-adv-3002]rule permit ip source 192.168 .20.0 0.0.0.255
Description: ACL has changed from standard to extended. It can be seen that deny is dropped first. When 192.168.0.0 accesses the server, the conversion is done. Usually it must be converted directly through the three-layer switch, without the firewall. , But if you do intra-domain NAT, you actually do a conversion on the inbound interface of the firewall, but the policy routing is called on the inbound interface. The previous match is directly passed to the ISP. This will result in the normally converted data. The packet wants to be sent to the server, but due to the existence of policy routing, it is forcibly sent to the ISP, so the deny here is to allow it to be forwarded normally according to the routing table without being controlled by the policy routing.
2. Policy routing changes [call ACL as modified]
3. Apply to the inbound interface (not in the demo)
4. Points to note about FTP.
In addition to the previous definition of NAT Server in Trust, an application layer monitoring needs to be invoked. Because it was converted between domains before, the ALG function was called between domains, but this time it is an intra-domain conversion, so it needs to be monitored again.
[USG-GW]firewall zone trust
[USG-GW-zone-trust]detect ftp
Result test
You can see that it can be accessed normally through the IP address, of course, it is also possible to use the domain name, here is just not setting up the environment to test.
Summary [Strategy, NAT, dual ISP deployment]
It can be seen that the strategy and NAT dual ISP situation will appear, and there will be many factors that need to be considered. For example, the strategy needs to consider the requirements, and the deployment must be combined with NAT, time strategy and other factors to achieve the effect. There is nothing to pay attention to the source NAT. However, there are a few points to pay attention to for NAT Server. If it is the same zone, the no-resver parameter must be added, and it is not necessary for different zones. The existence of dual ISPs requires consideration of routing switching, detection mechanism, and deployment of policy routing. Here, the policy routing ACL is strongly recommended to use extended ACLs, because it can be seen that if the requirements change, the standard ACL immediately appears helpless. The expansion can better match. Finally, if the deployment requires access to the company's internal server through the public IP or domain name , then intra-domain NAT must be deployed. But in the case of binding Zone to policy routing, you need to be very careful. The last is the ALG function of NAT. For multi-channel protocols, the application layer monitoring function must be turned on, otherwise NAT cannot be recognized. Common ones such as FTP, PPTP, QQ, etc. are available. If you find that the application is not working properly, you can add the ALG function. .
This article was first published on the public account: Network Road Blog