i agree, but when im a client such as 192.168.6.x and i try to access the public ip of the same router, with a specific port, the router has to be told where to redirect that port to.
you cannot just redirect 192.168.6.x to 192.168.6.198. you should move 192.168.6.198 to another interface, or use split DNS, so that external users resolve you server’s name to public IP and internal users resolve it to private IP
hi,
i was talking about redirecting the PUblic IP to a port. thus when internal client 192.168.6.x accesses http://public_IP it goes to 192.168.6.198 port 8300.
or they could: http://my_static_set_dns.com
the site works fine for people on the internet.
to clear up the layout:
Public IP is on ether2 \ router is 192.168.6.1 on ether1. \ all 192.168.6.x clients are on a switch plugged into ether1
all 192.168.6.x are nat Masqueraded to use ether2’s public ip
(and to be clear, the issue is fixed we are just discussing the idea)
to be clear, the issue is not solved, it’s worked-around
now your server receives requests from the address of your router, i.e. you cannot determine, who exactly asks your web-server for some page
let’s consider in more detail what happens in both cases.
case 1: someone from an external network sends a packet to your_public_ip:80. router receives this packet, processes NAT rules, changes dst-address of packet to 192.168.6.198:8300 and sends it to the web-server. the web-server sees a packet from external_user_ip to 192.168.6.198:8300, processes it and sends the response to external_user_ip. router receives a packet from 192.168.6.198:8300 to external_user_ip, changes src-address to your_public_ip:80 and sends a packet to external user. all is good.
now,
case 2: internal user. for example, 192.168.6.2. he sends a packet to your_public_ip:80. router receives this packet, processes NAT rules, changes dst-address of packet to 192.168.6.198:8300 and sends it to the web-server. the web-server sees a packet from 192.168.6.2 to 192.168.6.198:8300, processes it and sends the response to 192.168.6.2. but this response do not pass the router, so 192.168.6.2 receives a packet from 192.168.6.198. but he don’t want a packet from 192.168.6.198 - he asks for connection to your_public_ip, so he simply drops the packet. oops…