IP Forward Using ipTables not working

[halsafar]

So I want to take all traffic directed at a 'fake ip' address to a 'real one'. By this I mean 192.168.1.106 is a server hosting a few services. Using dnsmasq I have a set of local redirections going on pointing some sites to an unused 'fake' ip address 192.168.1.222.

Is it not possible to use ip tables to redirect all LAN traffic destined for 192.168.1.222:80 and send it to 192.168.1.106:8181

The following does not work:

iptables -t nat -A  PREROUTING -p tcp -d 192.168.1.222 --dport 80 -j DNAT --to 192.168.1.106:8181
iptables -t nat  -A POSTROUTING -j MASQUERADE

Next, the following works on the router and allows me to ping the fake ip address but get a response from the real one. No other machines on the LAN can though.

iptables -t nat -A OUTPUT -d 192.168.1.222 -j DNAT --to-destination 192.168.1.106

A solution would be having the router redirect 192.168.1.222:80 to 192.168.1.106:8181 for all clients.

I have done this before but it is not working on this router running merlin-wrt. Likely a chain name or interface issue.

 

[Grump]

LAN traffic is switched, not routed.

 

[halsafar]

So is there a rule chain for that? Any tips? I am not an iptables expert.

 

[Nerre]

No, because it does not pass the kernel. The "router" part of the router never see local-to-local traffic.

 

[Grump]

Since .222 is on the connected subnet (192.168.1.0/24), the source network card will ARP out for it. ARP is 1 packet asking everyone on the network if they are .222 and to please provide their MAC address for communication. If a device responds to ARP saying "I'm .222!" the source network card will send traffic directly there. The switching portion of the ASUS will keep track of which MAC addresses are connected to which physical ports and have them talk directly instead of tying up the rest of the network. If no device responds to ARP, the traffic does not get sent.

If the destination IP is not part of the connected subnet, the source network card will send it to the gateway to be routed/NAT'd etc. iptables comes in when the gateway & routing are in play.

The reason it works from the router is because iptables can apply to traffic sourced from the router. Your rule changes the destination address from .222 to .106 on the fly. The router only needs to know ARP for .106 and not for .222.

 

[halsafar]

Thanks for the explanation. This makes perfect sense.

So choosing an ip address not in the same subnet appears to work. Chose 10.10.10.10 as the 'fake ip' and was able to ping it locally and have the real server at 192.168.1.106 respond.

 

[halsafar]

I was wrong. While the 10.10.10.10 fake ip address is responding to pings. When trying to access a service like apache on port 80 it just gets stuck 'waiting' forever, as in it made the connection. With my previously I would just get stuck 'connecting'. Watching netstat the connection is indeed made now 10.10.10.10:80->192.168.1.106:80 but it cannot seem to respond back.

 

[Grump]

It's likely because the client sent the syn to 10.10.10.10, but the syn-ack is coming from 192.168.1.106.

 

[halsafar]

So how would one fix that?