Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have a DMZ server set up to forward specific ports to a couple of machines. The intended behavior is for me to send a request to the DMZ on a specific port, and have the machine that's inaccessible publicly respond with data. In this example, I'm forwarding port 10001 to the non-pub server on port 80.

I can see that the forward is working, because I can see the packets come in via tcpdump on the server. For whatever reason, the packets it responds with aren't making it back to my terminal (I'm curling).

iptables-save:

# Generated by iptables-save v1.4.10 on Fri Dec 23 17:36:10 2011
*nat
:PREROUTING ACCEPT [5609:332934]
:INPUT ACCEPT [5609:332934]
:OUTPUT ACCEPT [5231:376507]
:POSTROUTING ACCEPT [5248:377595]
-A PREROUTING -i eth0 -p tcp -m tcp --dport 10001 -j DNAT --to-destination 192.168.1.11:80
COMMIT
# Completed on Fri Dec 23 17:36:10 2011
# Generated by iptables-save v1.4.10 on Fri Dec 23 17:36:10 2011
*filter
:INPUT ACCEPT [119300:24294441]
:FORWARD ACCEPT [183:10688]
:OUTPUT ACCEPT [118926:28442933]
-A INPUT -i eth0 -p tcp -m state --state NEW -m tcp --dport 10001 -j ACCEPT
COMMIT
# Completed on Fri Dec 23 17:36:10 2011

Note: I took my ip out and replaced it with 10.10.10.10 Legend:

  • 192.168.1.3 = DMZ
  • 192.168.1.11 = Non-public server
  • 10.10.10.10 = me from a remote network.

tcpdump from the DMZ:

17:44:45.039273 IP 10.10.10.10.64090 > 192.168.1.3.10001: Flags [S], seq 2710805211, win 65535, options [mss 1460,nop,wscale 3,nop,nop,TS val 1211306586 ecr 0,sackOK,eol], length 0
17:44:45.039365 IP 10.10.10.10.64090 > 192.168.1.11.www: Flags [S], seq 2710805211, win 65535, options [mss 1460,nop,wscale 3,nop,nop,TS val 1211306586 ecr 0,sackOK,eol], length 0

Based on the above, the forwarding appears to be working.

tcpdump from the non-public server:

17:51:14.260134 IP 10.10.10.10.64110 > 192.168.1.11.www: Flags [S], seq 722619659, win 65535, options [mss 1460,nop,wscale 3,nop,nop,TS val 1211694763 ecr 0,sackOK,eol], length 0
17:51:14.260378 IP 192.168.1.11.www > 10.10.10.10.64110: Flags [S.], seq 3171485713, ack 722619660, win 14480, options [mss 1460,sackOK,TS val 4294937443 ecr 1211694763,nop,wscale 3], length 0
17:51:14.260470 IP 10.10.10.10.64111 > 192.168.1.11.www: Flags [S], seq 483447265, win 65535, options [mss 1460,nop,wscale 3,nop,nop,TS val 1211694763 ecr 0,sackOK,eol], length 0

My curl from a remote network (obfuscated IP):

$ curl -vv remote-unit:10001
* About to connect() to remote-unit port 10001 (#0)
*   Trying 99.99.99.99... Operation timed out
* couldn't connect to host
* Closing connection #0
curl: (7) couldn't connect to host
share|improve this question
    
This will not fix your problem, but will help debug, you can use the rule -j LOG on a rule to log the connections and traffic, very helpful in visualizing what is going wrong. –  Tim Dec 23 '11 at 18:46
    
It seems to me that it is a routing problem. –  Khaled Dec 23 '11 at 19:43
add comment

1 Answer

Since you are performing DNAT, in order for the non-public server to reply, it must have a route (whether specific or default) via the machine performing DNAT - If the route is asymmetric (i.e. replies do not go out via the machine that performed DNAT) or there simply is no valid route to reply on, your client will resultantly not get the reply.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.