Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm having a problem with a dedicated server, I don't known if it's the default behavior but this is the problem:

If I connect to a service located on the server with localhost the service gets as source IP the external IP.

Let me show an example, I use netcat for listening on

xxxxxx # nc -vv -l -s -p 4444
listening on [] 4444 ...

Lets check if it's ok:

xxxxxx ~ # netstat -atnp | grep 4444
tcp        0      0*               LISTEN      14038/nc        

Ok lets connect:

xxxxxx ~ # nc -vv 4444    
localhost [] 4444 (?) open

Return to the tty that have the listening process and I get this:

connect to [] from [] 50354

So that's the problem. I have a server daemon that have to listen on localhost and checks that the ip is when the client connects but for some reason when I connect to localhost it reports the external ip...

If I do the same with IPv6 it works as excepted... Detects connection as localhost (::1).

Some info that can be useful:

"localhost" resolves without problems to

xxxxxx ~ # ping -c1 localhost
PING localhost ( 56(84) bytes of data.
64 bytes from localhost ( icmp_req=1 ttl=64 time=0.086 ms

Nothing weird on my hosts file, I think...

xxxxxx ~ # grep -v ^# /etc/hosts   localhost localhost.localdomain
::1     ip6-localhost ip6-loopback
feo0::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts

And ifconfig reports all ok...

eth0      Link encap:Ethernet  HWaddr e0:69:95:d8:30:a1  
          inet  Bcast:  Mask:
          inet6 addr: 2001:41d0:8:xxxx::/64 Scope:Global
          inet6 addr: 2001:41d0:8:xxxx:x:xx:xx:xx/64 Scope:Global
          inet6 addr: fe80::e269:95ff:fed8:30a1/64 Scope:Link
          RX packets:16916 errors:0 dropped:0 overruns:0 frame:0
          TX packets:16914 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:8410679 (8.0 MiB)  TX bytes:10539881 (10.0 MiB)
          Interrupt:28 Base address:0xe000 

lo        Link encap:Local Loopback  
          inet addr:  Mask:
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:5570 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5570 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:744490 (727.0 KiB)  TX bytes:744490 (727.0 KiB)
share|improve this question
That is weird. I don't get the same behaviour on my Debian machine. I don't know what you've done, but you'll learn a lot in the process of finding out. – womble Jul 6 '12 at 8:24
@womble On my work Debian machine I don't get the same behavior, really really strange I don't know where to start... – skgsergio Jul 6 '12 at 8:39
Yeah, nothing's immediately coming to mind for me, either. Serverfault isn't a good place for this sort of problem-solving, although you might find someone to help you in chat. – womble Jul 6 '12 at 8:42
What does netstat -nr look like, and are you running iptables? – Cakemox Jul 6 '12 at 8:45
I suspect that it's just some ns confusion - you could confirm this using tcpdump – symcbean Jul 6 '12 at 8:54
up vote 2 down vote accepted


Thanks to @Cakemox that advised me about iptables. I have the following rule which caused the unexpected behavior:

/sbin/iptables -t nat -A PREROUTING -p tcp --dport 1234 -j DNAT --to-destination
/sbin/iptables -t nat -A POSTROUTING -j MASQUERADE

I will address that redirect in a proper way to avoid problems in the future...

share|improve this answer

Your Answer


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.