Access a server using his public IP from the internal LAN (same net)

For whatever service type you are making these rules for.. have you allowed outbound traffic of this type from your LAN to your WAN?

From your LAN can you connect to another server on the internet that offers the same type of service running on the same port?

- the service is a custom type (not standard type), and we have allowed our lan to use it in the packet filter...


the problem is very specific : 

- the station output a request on the public ip
- the astaro do his job (DNAT) : change the public ip with private address of the server
- (we saw in "green" the new packet in live log of the packet filter because dnat is done before packet filter)

--> the new packet is strictly local ( soucre and dest are in the same subnet !) so the server recive it and respond but the client drop the answer : he tries to open a communication on public ip, not on the private address which isn't know at his point !

For me the problem is the same of that :
---------------------------------------
From iptables help :http://iptables-tutorial.frozentux.net/chunkyhtml/x4033.html

 Now, we will consider what happens if the packet was instead generated by a client on the same network as the HTTP server itself. The client has the IP address $LAN_BOX, while the rest of the machines maintain the same settings.

   1.      Packet leaves $LAN_BOX to $INET_IP.
   2.      The packet reaches the firewall.
   3.      The packet gets DNAT'ed, and all other required actions are taken, however, the packet is not SNAT'ed, so the same source IP address is used on the packet.
   4.      The packet leaves the firewall and reaches the HTTP server.
   5.      The HTTP server tries to respond to the packet, and sees in the routing databases that the packet came from a local box on the same network, and hence tries to send the packet directly to the original source IP address (which now becomes the destination IP address).
   6.      The packet reaches the client, and the client gets confused since the return packet does not come from the host that it sent the original request to. Hence, the client drops the reply packet, and waits for the "real" reply. 

The simple solution to this problem is to SNAT all packets entering the firewall and leaving for a host or IP that we know we do DNAT to. For example, consider the above rule. We SNAT the packets entering our firewall that are destined for $HTTP_IP port 80 so that they look as if they came from $LAN_IP. This will force the HTTP server to send the packets back to our firewall, which Un-DNAT's the packets and sends them on to the client. The rule would look something like this:

iptables -t nat -A POSTROUTING -p tcp --dst $HTTP_IP --dport 80 -j SNAT \
--to-source $LAN_IP


I tried several SNAT (I the webadmin of course) but nothing was successful [:@]

So if somebody has any idea ? 
Thanks in advance.

- the service is a custom type (not standard type), and we have allowed our lan to use it in the packet filter...


the problem is very specific : 

- the station output a request on the public ip
- the astaro do his job (DNAT) : change the public ip with private address of the server
- (we saw in "green" the new packet in live log of the packet filter because dnat is done before packet filter)

--> the new packet is strictly local ( soucre and dest are in the same subnet !) so the server recive it and respond but the client drop the answer : he tries to open a communication on public ip, not on the private address which isn't know at his point !

For me the problem is the same of that :
---------------------------------------
From iptables help :http://iptables-tutorial.frozentux.net/chunkyhtml/x4033.html

 Now, we will consider what happens if the packet was instead generated by a client on the same network as the HTTP server itself. The client has the IP address $LAN_BOX, while the rest of the machines maintain the same settings.

   1.      Packet leaves $LAN_BOX to $INET_IP.
   2.      The packet reaches the firewall.
   3.      The packet gets DNAT'ed, and all other required actions are taken, however, the packet is not SNAT'ed, so the same source IP address is used on the packet.
   4.      The packet leaves the firewall and reaches the HTTP server.
   5.      The HTTP server tries to respond to the packet, and sees in the routing databases that the packet came from a local box on the same network, and hence tries to send the packet directly to the original source IP address (which now becomes the destination IP address).
   6.      The packet reaches the client, and the client gets confused since the return packet does not come from the host that it sent the original request to. Hence, the client drops the reply packet, and waits for the "real" reply. 

The simple solution to this problem is to SNAT all packets entering the firewall and leaving for a host or IP that we know we do DNAT to. For example, consider the above rule. We SNAT the packets entering our firewall that are destined for $HTTP_IP port 80 so that they look as if they came from $LAN_IP. This will force the HTTP server to send the packets back to our firewall, which Un-DNAT's the packets and sends them on to the client. The rule would look something like this:

iptables -t nat -A POSTROUTING -p tcp --dst $HTTP_IP --dport 80 -j SNAT \
--to-source $LAN_IP


I tried several SNAT (I the webadmin of course) but nothing was successful [:@]

So if somebody has any idea ? 
Thanks in advance.