Re: NAT issue with iptable

From: Bill Davidsen (davidsen_at_tmr.com)
Date: 06/22/05 

Date: Wed, 22 Jun 2005 17:10:46 GMT

crowl@gmx.de wrote:
>>>I am using iptables for nat.
>>>iptables -t nat -A POSTROUTING -o $IFACE_EXT -j MASQUERADE
>>>iptables -A INPUT -i $IFACE_EXT -s $myPublicIP -j ACCEPT
>>
>>
>>You accept packets from external machines pretending to be your ext-IP?
>>Why? Who is sending them?
>
>
> Sorry for the confusion. In fact $myPublicIP is the IP range provided
> by our ISP. $IFACE_EXT is eth0 and is bind to two IP addressed. One IP
> from $myPublicIP and one from our private IP range 192.168.x.x.
> $IFACE_EXT is in our DMZ. The machine has also a second nic which is
> connected with our intranet protected by iptables. In $myPublicIP range
> exist two machines we need for testing purposes. Therefore we have this
> second rule. I know I have to be more specific with this rule. But this
> adjustment was a quick hack for testing purposes during setup the DMZ.
> I think we can neglect the second rule, because it is not important for
> the original issue, isn't it? Once again, sorry for the confusion.
>
>
>>>iptables -t nat -A PREROUTING -i $IFACE_EXT -p tcp -d $myPublicIP
>>>--dport 443 -j DNAT --to-destination $myInternalWebserver
>>
>>
>>>Issue: In the web server logs I get only the ip of myPublicIP. It seems
>>>that nat rewrite the original ip address. The original ip of the client
>>>is very important for the running web server application.
>>
>>>How can I avoid the rewrite of the original ip address?
>>
>>Run tcpdump on all NICs, You would see this if you were using the
>>external NIC to talk to the "$myInternalWebserver" and using the MASQ.
>
>
> I am a little bit confused about that. I have run tcpdump and see the
> IP from the external client. I am not familiar with tcpdump maybe I
> overlook something. But how can tcpdump help me to solve my issue (see
> the IP address of the client in the logs of the webserver and in the
> running applications instead of the IP of the machine itself)? Or
> should tcpdump give me a clue to find the right way?

You need to see everything at the same time, so you need two copies of
tcpdump running. Something like this:
  tcpdump -i eth0 >eth0.tcpd &
  tcpdump -i eth1 >eth1.tcpd &
  ...run your tests...
  killall tcpdump
  for n in eth0 eth1; do
   tcpdump -r$n.tcpd -v | sed 's/ / $n /'
  done | sort -n | less

That looks a bit arcane, but it allows you to see the packets in time
order, so you can tell where each packet came in, with what addresses,
and where it went out, and the results of any NAT rewriting.

You can post that info which may allow someone to see your problem sooner.
>
>
>>>Thanks for your help.
>>
>>Not much help, I don't understand the 2nd rule. But you should just
>>trace this all out, and display the overall packet flow to understand
>>what's happening.
>
>
> Thanks for your assistance.
>
> cl
> 

-- 
bill davidsen <davidsen@tmr.com>
   CTO TMR Associates, Inc
   Doing interesting things with small computers since 1979