Web Server Unreachable from the Internet - NAT Is Working, Routing Is Not

The translation is fine; the return path is not. This is a one-way failure with three distinct legs to separate.

1. Inbound: the external SYN arrives on G0/0/1, matches the NAT server entry, destination is translated to 192.168.10.20, and the router forwards it on the LAN. A session entry is created - which is exactly why display nat session all looks healthy.
2. Server reply: the server answers the translated source, and sends it to its configured gateway, 192.168.10.1. That address belonged to a firewall that no longer exists, so nothing answers ARP and the packet dies. The router never sees the reply, the client never gets a SYN-ACK, and the TCP handshake times out.
3. Reachability from 192.168.10.50 works because both hosts are in 192.168.10.0/24: the PC ARPs directly for 192.168.10.20 and the reply comes back at layer 2 without ever touching a gateway. Same reason the server's own outbound update traffic fails - every non-local destination needs the (dead) gateway.

The NAT entry and ACL 2000 are both blameless here. Confirm with display arp on the router (no ARP entry for 192.168.10.1 if it is really gone), display ip routing-table on the server side, and by testing an outbound connection from the server to any internet host, which will fail identically.

Fix: change the server's default gateway to 192.168.10.254, either directly on the host or by adding the removed address as a secondary address on the router LAN interface (ip address 192.168.10.1 24 sub) if touching many servers at once is impractical. The proper fix is the host setting; the secondary-address workaround hides the misconfiguration and should be time-boxed.

Validation ladder - each step isolates a layer:

1. Server → 192.168.10.254 ping: proves the gateway is now correct.
2. Server → an internet host (e.g. 8.8.8.8 or an NTP server): proves NAT outbound and the routing path work.
3. From an external host, telnet 200.1.1.2 80 or curl -v http://200.1.1.2/: proves the NAT server entry end-to-end.
4. display nat session all again: with the fix, the session should show both directions' counters incrementing, not just the initial packets. A session that exists and stays half-open with zero return bytes is the signature of a return-path problem, not of a NAT or ACL problem.
5. If it still fails, check ACL 3000/other inbound filters in the order they are actually applied - but do that only after step 2 passes, because a failing outbound test proves the problem is behind the router, not in the ACL.

This is the classic hairpin case. The PC sends the SYN to 200.1.1.2 with source 192.168.10.50. The packet arrives at the router (its own interface address), the NAT server entry rewrites the destination to 192.168.10.20, and the router forwards it back out the same LAN interface. The server receives a SYN from 192.168.10.50 and replies - but it replies directly at layer 2 to 192.168.10.50, because both are in the same subnet. The reply carries source 192.168.10.20, so the client sees a response from an address it never contacted and discards it. The router is bypassed and the translation is never reversed.

What is required: hairpin (also called NAT loopback) behaviour on the internal interface - on VRP, nat hairpin enable on the LAN interface, in addition to the existing NAT server entry. With hairpin enabled the router also translates the source of the re-forwarded packet to its own LAN address, so the server replies to the router, the router reverses the translation, and the client sees a reply from 200.1.1.2.

Judgement: this is often a bad fix to reach for. It adds session load, breaks the server's ability to log real client addresses, and frequently gets forgotten during migrations. Prefer split-horizon DNS - resolve the service name to 192.168.10.20 for internal clients and to 200.1.1.2 externally - and keep hairpin only for clients that cannot be given internal DNS.