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 webserver hidden behind a firewall. A DNAT rule on my firewall makes it reachable for visitors from the internet. The rule works for traffic from the internet. Unfortunately it doesn't work (or only in parts) for traffic coming from the same subnet as the real destination. For some reason netfilter doesn't restore the orginal destination address and therefore the client/sender disregards the answer packet.

What am I doing wrong?

Network Layout

192.168.101.0/24  # LOCAL Lan

192.168.101.16  # Client
192.168.101.18  # Server
192.168.101.254 # firewall
144.256.256.1   # firewall (Not the real IP)


          (Internet)
      | 144.256.256.1 |
              |       |
      |   Firewall    |
              |       |
      | 192.168.101.254 |
              |
              |
    ----------------------
    |                     |
192.168.101.16        192.168.101.18
  (Client)            (Server)

iptables Rules

-t nat -A PREROUTING -d 144.256.256.1 --dport 81 -j DNAT destination 192.168.0.2
-t nat -A POSTROUTING -s 192.168.0.0/16 ! -d 192.168.0.0/16 -j MASQUERADE (Should be irrelevant)

Szenario not working

(Client) 192.168.101.16 trying to reach (Server) 144.256.256.1/81

tcpdump on firewall

192.168.101.16.57631 > 144.256.256.1.81: Flags [S], seq 1884612678 
192.168.101.16.57631 > 192.168.101.18.81: Flags [S], seq 1884612678 
192.168.101.16.57631 > 144.256.256.1.81: Flags [S], seq 1884612678 
192.168.101.16.57631 > 192.168.101.18.81: Flags [S], seq 1884612678
(Seems okay. tcpdump was on -i any. Incoming packet to orginal destination 144.xx Outgoing packet to new destination. But for some reason we're not seeing the responses)

tcpdump on destination (server)

IP 192.168.101.16.57874 > 192.168.101.18.81: Flags [S], seq 4243879528,
IP 192.168.101.18.81 > 192.168.101.16.57874: Flags [S.], seq 595099059, ack 4243879529,
IP 192.168.101.16.57874 > 192.168.101.18.81: Flags [R], seq 4243879529, win 0, length 0
(Seems good)

tcpdump on source (client)

IP 192.168.101.16.57874 > 144.256.256.1.81: Flags [S], seq 4243879528
IP 192.168.101.18.81 > 192.168.101.16.57874: Flags [S.], seq 595099059, ack 4243879529, (WTF packet. The source should be 144.x again. For some reason netfilter didn't restore the orignal destination address for the response packet.)
IP 192.168.101.16.57874 > 192.168.101.18.81: Flags [R], seq 4243879529
share|improve this question

1 Answer 1

You don't see any response packet on the firewall, because there is none. The server does not send the response to the firewall, because the client is in the same subnet.

Request: Client -> Firewall -> Server

Reply: Server -> Client

Therefore the client discards the response, because it does not expect any response from the server, but from the firewall.

Either try some crazy routing magic or set the internal IP for your URL in the client's hosts file. Or get rid of NAT at all...

share|improve this answer
    
As mentioned, NAT is horrible; this is an ugly hack at best. One way to make this work is to SNAT the traffic from the internal hosts so the webserver sees the firewall's address as the source address for the requests. iptables -t nat -A POSTROUTING -s 192.168.101.0/24 -d 192.168.101.18 -p tcp --dport 81 -j SNAT --to 192.168.101.254 –  fukawi2 Nov 24 '13 at 0:18

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.