4

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 127.0.0.1:4444

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

Lets check if it's ok:

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

Ok lets connect:

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

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

connect to [127.0.0.1] from xxxxxx.net [176.31.xxx.xx] 50354

So that's the problem. I have a server daemon that have to listen on localhost and checks that the ip is 127.0.0.1 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 127.0.0.1

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

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

xxxxxx ~ # grep -v ^# /etc/hosts
127.0.0.1   localhost localhost.localdomain
176.31.xxx.xx   xxxxxx.net ns1.xxxxxx.net
::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 addr:176.31.xxx.xx  Bcast:176.31.108.255  Mask:255.255.255.0
          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
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          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:127.0.0.1  Mask:255.0.0.0
          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)
skgsergio
  • 93
  • 2
  • 6
  • 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 06 '12 at 08: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 06 '12 at 08: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 06 '12 at 08:42
  • 2
    What does `netstat -nr` look like, and are you running iptables? – Cakemox Jul 06 '12 at 08:45
  • I suspect that it's just some ns confusion - you could confirm this using tcpdump – symcbean Jul 06 '12 at 08:54
  • @Cakemox I'm running IP tables with a rule that can be a problem maybe... Let me test something. Will update status. – skgsergio Jul 06 '12 at 09:03

1 Answers1

2

Solved

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 xxx.xxx.xxx.xxx:1234
/sbin/iptables -t nat -A POSTROUTING -j MASQUERADE

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

skgsergio
  • 93
  • 2
  • 6