Don't put a public address on a lo device use a dummy eth interface instead. Any IP address and it's subnet assigned to a lo device is marked as a marcian address and the traffic is dropped if it tries to leave the lo device. I know that there is som old documentation out there (for example quagga's documentation) that says you can do it but it's been wrong since the 2.4 version off the kernel. Linux treats the lo device differently that what routers call a loopback device. The dummy driver is the linux equivalent of what routers call a loopback device. Original Message From: Robert Sander Sent: Friday, January 8, 2016 04:32 To: netfilter@xxxxxxxxxxxxxxx; netdev@xxxxxxxxxxxxxxx Subject: Configure ICMP error source address Hi, It is possible to change the source address of ICMP error messages generated by the kernel via /proc/sys/net/ipv4/icmp_errors_use_inbound_ifaddr. This is currently the only way to influence the source address as ICMP errors do not travel through the NAT table (for obvious reasons). We have the situation that our routers use RFC1918 addresses on their transfer networks (which should be quite common nowadays to save on public IPv4 addresses). ICMP errors are generated with RFC1918 source addresses and therefor never reach the original sender. Every router has its public IP address bound to dev lo to be reachable even if any one interface is down. Routing protocols assure that. Is it a good idea to develop a kernel patch that makes it possible to select the first IPv4 address on dev lo with scope global as the source address for ICMP errors? Would that do any harm to the Internet at large? Regards -- Robert Sander Heinlein Support GmbH Schwedter Str. 8/9b, 10119 Berlin http://www.heinlein-support.de Tel: 030 / 405051-43 Fax: 030 / 405051-19 Zwangsangaben lt. §35a GmbHG: HRB 93818 B / Amtsgericht Berlin-Charlottenburg, Geschäftsführer: Peer Heinlein -- Sitz: Berlin -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html