I have a debian linux firewall/gateway connecting my wan and lan working with iptables. I have eth1
as the wan with dynamic address 190.200.229.102
attached to somehost.com
via DYNDNS and eht0
as the lan with address 192.168.128.2
. Everything works as expected. Traffic coming in gets rejected for all ports except the ones specified with ACCEPT and the port forwarding works as expected redirecting traffic to the inside machines.
The problem is that when I try to connect to somehost.com
from the inside network I don't get redirected to the internal machines as I expect. My firewall rules for port redirection are attached to the wan interface (eth1
). I'm assuming that when I try to connect to somehost.com
I'm coming from the lan connection and that is why the redirection does not work. I have experimented with REDIRECT, DNAT, INPUT and other tags without success. Any hints on how to achieve this?
I don't know the answer to your question. However as a work around why not had a fake DNS entry internally for somehost.com pointed at the LAN IP instead?
you have to masquarade the forwarded packets to appear as if they are comming from the firewall
iptables -t nat -A POSTROUTING -s 192.168.128.0/24 -o eth0 -j MASQUERADE
otherwise the return packets will be coming to you from the internal hosts itself who are seeing internal adresses and sending the packets directly back. So you are sending requests to 190.200.229.102 but getting the replies from 192.168.128.x, its quite normal that your machine doesn't know what to do with them :)
You should try adding a local DSN entry as stated by Mr. Joel Mansford, in Debian edit the file:
/etc/hosts
add entries in this format:
10.10.10.10 dyndns.com 11.11.11.11 someother.com other.sameline.com
;)
I can guess that the problem is that you are doing ip masquerading (SNAT) and DNAT on the packets.
Let's say you connect from internal host 192.168.128.3.
The original packet would be:
Then because of DNAT it would get translated to:
I guess this is where the problem is: from and to addresses are the same.
You should run tcpdump or tshark in the connecting machine, every interface of the firewall and the receiving machine. Then try to connect and try to see in which interface the packets are lost and the from and to addresses as they get translated.
Once you understand it, you can create a filter to address that specific problem in the correct interface.
Otherwise you can use the DNS solution stated by joelmansford which may be a cleaner solution.