-2

Asked this in network-engineering in stack exchange and was redirected here.

I have a couple of servers with the below config

server1:

eno1: 127.15.0.1/16 scope global
eno2: 5.0.0.1/24

server2:

lo: 127.0.0.1/16 (it had /8. I changed the subnet mask using 'ip addr del 127.0.0.1/8 dev lo; ip addr add 127.0.0.1/16 dev lo')
eno2: 5.0.0.2/24

eno1 of server1 is connected to a completely different L2 network and is completely isolated.

eno2 interfaces of both servers are connected to the same L2 network. Now i have to access 127.15.0.1 from server2.

Server1 was deployed long back and i dont have permissions to change any sort of config. I dont know why some one used 127.x.x.x subnet with scope global. Not sure if it is a valid config but i have to live with it. I have complete control on the server2 and i can change anything.

Both servers are linux based.

connectivity between 5.0.0.1 <-> 5.0.0.2 is good.

My first try was to add a route in server2 as below

ip r add 127.15.0.1/32 via 5.0.0.1 pinged 127.15.0.1 from server2. I see the ping requests and replies in tcpdump on server2, but ping command is showing 100% loss.

I disabled rp_filters

sysctl.cnf:

net.ipv4.conf.all.rp_filter=0
net.ipv4.conf.default.rp_filter=0
net.ipv4.conf.lo.rp_filter=0
net.ipv4.conf.eno2.rp_filter=0

rebooted after updating sysctl.conf

And i flushed out the iptables. (iptables -F)

Same result. I thougt may be server2 doesnt like using 127.x.x.x series. So i added the below rule on server 2

iptables -t nat -A OUTPUT  -d 5.0.0.1 -j DNAT --to-destination 127.15.0.1

this rule is supposed to replace destination ip to 127.15.0.1 if packet is destined to 5.0.0.1.

pinged 5.0.0.1 from server2. Iptables replaced the destination ip with 127.15.0.1(confirmed this on server1 tcpdump). Server1 replied but the replies are dropped again.

I ran out of ideas at this point. I took down server1 for maintenance and replaced 127.15.0.1/26 with 192.168.1.1/16. Connectivity worked fine in this case (with and without iptables). Now the question is, is the issue because of using 127.x.x.x? If yes, is there a way out of it?? If no, what else can I try?

Note: This config was working before. We recently lost server2 (which had old Linux) and I am building it from scratch. Also windows doesn't allow using 127.x.x.x to interfaces other than loopback. Not sure why Linux allows it on non lo interfaces. may be there is a rationale!

To summarize I have these questions:

  1. Windows outright rejects the config when we try to configure 127.x.x.x but Linux allows it and that too with global scope. Is there a use case for this?
  2. In this case server2 sends out requests destined to 127.x.x.x and server1 is actually sending replies back. If 127.x.x.x is only host-internal, why are they even sending packets on the link??
RBK050
  • 9
  • 2
  • 2
    127.0.0.0/8 is reserved for *host-internal* loopback and not for use on a local network, see RFC 5735. There are plenty of other, functional address ranges as per RFC 1918. – Zac67 Aug 30 '21 at 14:27
  • Thankyou. I don't want to sound rude but I already knew that. As already mentioned in the question, the moment I change the subnet to private/public subnets, it works. I am working on fixing the config. I have summarized my queries at the end of the question. Would be interesting to get your view(s) on it. – RBK050 Aug 30 '21 at 15:08
  • 2
    Even if you do not have access to the other server, it would be appropriate if the person responsible for its maintenance a) explains himself b) showed you the relevant configuration so you do not have to wonder *why* this even worked before and c) fix this mess. – anx Aug 30 '21 at 16:02
  • 1
    Addresses in the `127.0.0.0/8` loopback block cannot appear on any network, anywhere. See [this answer](https://networkengineering.stackexchange.com/a/40156/8499) for the relevant RFCs. That range is recognized by IPv4, itself, and any IPv4 implementation that allows traffic destined to an address in that range to exit the host is a flawed IPv4 implementation. Traffic destined to those addresses is _required_ to loop back inside the source host. – Ron Maupin Aug 30 '21 at 16:37
  • _[RFC 1122, Requirements for Internet Hosts -- Communication Layers](https://tools.ietf.org/html/rfc1122#section-3.2.1.3)_: "_Internal host loopback address. Addresses of this form MUST NOT appear outside a host."_ – Ron Maupin Aug 30 '21 at 16:44
  • Relax guys. I am well aware of the RFCs. I just wanted to know if linux supports it. And looks like it does. Please look at the answer. I am not encouraging anyone to use it. Just wanted to know if there is a possibility. – RBK050 Aug 31 '21 at 01:58

1 Answers1

0

The Linux sysctl flags at

/sys/net/ipv4/conf/*/route_localnet

allow disabling reasonable treatment for such packets.

route_localnet - BOOLEAN

Do not consider loopback addresses as martian source or destination while routing. This enables the use of 127/8 for local routing purposes. default FALSE

Since few sane people would ever do such a thing, this may or may not work these days (I last tested it a few years back).

Please assign any reserved-for-this-purpose (possibly link-local, but not host-internal) or owned IP space to the interfaces in question. Continuing with this strange setup is only going to cause more trouble, especially when easy alternatives exist.

anx
  • 6,875
  • 4
  • 22
  • 45
  • This worked. This proc entry is the reason for black magic. After setting this, connectivity worked. I was able to convince my team use private IPs. Thank you – RBK050 Aug 31 '21 at 01:54