hi Giedrius,
consider the following scenario:
PC----------------(fa0/0)Router(ser0/0)-----------------------Internet
|
|
myServer.com
host- 192.168.1.2/24
ip address on the router: fa0/0---192.168.1.1/24 ser0/0:1.1.1.1
server:192.168.1.10 ; public IP address for server 1.1.1.2
-PC goes out to the internet after getting PATed on the router.
-server is mapped using static NAT rule to the public IP address 1.1.1.2
say the PC is trying to access myserver.com after resolving it to its public IP address(1.1.1.2)
here is how the packet will flow:
1. Host 1 browses to the internal Web Server using its URL
(myserver.com).
2. Host 1s browser sends a DNS request to the external DNS server to
resolve myserver.com to its IP address.
3. The external DNS server replies with the global IP address of
1.1.1.2
4. Host 1s browser now attempts to make a connection with 1.1.1.2
and sends the traffic to its default gateway, fa0/0.
5. Routing takes place, and the router sends this traffic out the s0
interface. As this occurs, the source IP address is translated since it has
traversed both a NAT inside and outside interface.
6. The ISP notes the destination address (1.1.1.2) is routed back
out the same interface it came in on, and the traffic comes back to the s0
interface.
7. Since s0 is a NAT outside interface, the source and destination
addresses are translated. The packet now has a source of 192.168.1.2 and a
destination of 192.168.1.10.
8. The Web Server receives the TCP request from Host 1 and, noting that
it is a local address, replies directly to Host 1.
9. Host 1 receives a reply from its TCP request; however, since it
receives it from 192.168.1.10 and not 1.1.1.2 as it was expecting, it drops
the packet.
this is why you see this issue.
one workaround is to configure an internal DNS server so that the internal hosts resolve the URL to internal IP address. you could configure the DNS on the router itself.
you could also try NAT-ON-A-STICK config but that has been known to lead to high CPU issues.