Bug#772650: general: Debian could not use gateway in 169.254.0.0 ip range
On Wed, 10 Dec 2014, Maciej Kotliński wrote: Finally I found the easiest and trivial resolution of the problem. You just can set scope 0 with ip command. The interface with address 169.254.x.x gets scope link (253), so the packets won't be send outside NAT. Configuring interface with ip a a 169.254.x.x dev ethX scope 0 After that the packages are sent as before. I'm sure that after release of Jessie as stable some other people will have such problem. Could somebody add my comment to the closed bug report? It could help somebody with the networki simillar to mine. Done. However, here are the warnings for other users that also have the same problem (broken as designed network addressing using link-local scope to reach through routers/gateways). 1. This is not a proper fix, it is a gross hack that breaks things further, useful only to perpetuate broken network designs. 2. Changing the scope of 169.254.0.0/16 has security implications, none of them good. 3. The end result is utterly unsupported by Debian and by the IP networking standards. In fact, it is an *explicitly forbidden* configuration. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#772650: general: Debian could not use gateway in 169.254.0.0 ip range
Closing remarks and the solution of the problem:
We can conclude that *using 169.254.x.x for routed networks is not in
accordance with standards.*
According to the standards the router shouldn't forward such packages
(from 169.254.x.x network) and even the client shouldn't send such
packages to the router.
Linux firewall will forward anything you configure it to. So you can
configure it to forward 169.254.x.x packages.
I think in doesn't have anything to do with standards — you configure
the router as you want (you should obey standards).
Debian Jessie as a client also obey the standard (contrary to older
Debian releases) it doesn't send the packages addressed outside from
169.254.x.x network to the router. It normally sends packages to the
other computers in 169.254.x.x network including the router but does not
send the traffic directed outside 169.254.x.x network. All packages
which before were sent to the router and NATed now are dropped.
This is done by setting interface/link scope property to 253 (it means
local link). The packages directed outside (to NAT) from such
interface are dropped.
One can check the scope by ip a
inet 169.254.1.61/24 brd 169.254.1.255 scope *link* eth0
It is possible to set scope to 0 (global) something like by this:
ip a a 169.254.1.61/23 dev eth0 scope 0
(of course you have to delete the old interface config for example by:
ip a d 169.254.1.61/23 dev eth0
than you can see this in ip a output
inet 169.254.1.61/24 brd 169.254.1.255 scope *global* eth0
Now the client starts to send packets from 169.254.x.x to be NATed by a
gateway.
Now the note for insubordinate administrators who don't like obey the
rules in their private networks (as me:)
*The scope could be configured by DHCP server.*
For dhcpd you need to put option non-local-source-routing true; in
subnet configuration of dhcpd.conf
It looks like this:
subnet 169.254.1.0 netmask 255.255.255.0 {
authoritative;
range 169.254.1.10 169.254.1.249;
option subnet-mask 255.255.255.0;
option routers 169.254.1.1;
default-lease-time 3600;
max-lease-time 9900;
option domain-name-servers x.x.x.x, y.y.y.y;
option non-local-source-routing true;
}
Now the server push clients to set scope of the interface to 0;
You can do something opposite: configure the clients of some other ip
range to not send packed to router.
Maybe it will help somebody with the network as mine.
Regards,
Maciek
Bug#772650: general: Debian could not use gateway in 169.254.0.0 ip range
Package: general Severity: important I have a NAT-ed network which uses 169.254.1.0/24 range (private/zeroconf range). The network has dhcp and gateway (169.254.1.1). From some time (probably few months) Debian Jessie is not able to use the gateway. It is possible to ping the gateway and other computers in 169.254.1.0/24 network. The packets are not routed by the nat. Tcpdump on the gateway does not see any incoming packets when I try to send packets from Debian box outside 169.254.1.0 network. The gateway works fine, there is 30 computers using this nat and dhcp (Windows, Androids, Mac, Ubuntu, etc.). Few days ago I have installed a fresh copy of Jessie on a laptop connected to my 169.254.1.0 network. Debian installer (netinst) correctly downloads the packages with use of this network. After firs reboot the system lose the connectivity with the Internet. I made a virtual machine to test the problem — it behaves exactly the same (could connect internet witch other ip ranges could not connect internet when connected to 169.254.1.0/24). The re is no avahi and any avahi-configured routes to 169.254.x.x. There is only the route configured by dhcp. I don't know where is the problem. I know that 169.254.x.x range is assigned to zeroconf and avahi like stuff. Still it should be possible to configure/use the gateway in any ip range you want. It would be very difficult to change the addressing here. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.17.4MK (SMP w/4 CPU cores) Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#772650: general: Debian could not use gateway in 169.254.0.0 ip range
1) General is the wrong package for this bug. (i assume it's going to get closed, network-manager or ifupdown are probably a better idea). 2) Assuming the former is causing the problem (because you have eth0 in /etc/network/interfaces). FIX 1) Set managed=true in /etc/NetworkManager/NetworkManager.conf. as per https://wiki.debian.org/NetworkManager#Enabling_Interface_Management (and restart) FIX 2) If that fails (and you use network-manager) remove ALL instances of eth0 in /etc/network/interfaces (and restart) Expect this bug to be closed. Check network-manager bugs in the bug tracker. And at some point plan a project to change the internal IP range. 169.254.x.x is wrong. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#772650: general: Debian could not use gateway in 169.254.0.0 ip range
On Tue, 09 Dec 2014, Maciej Kotliński wrote: I have a NAT-ed network which uses 169.254.1.0/24 range (private/zeroconf range). The network has dhcp and gateway (169.254.1.1). From some time (probably few months) Debian Jessie is not able to use the gateway. This was never supposed to work in the first place, but before I explain why, make sure you have ip forwarding enabled. cat /proc/sys/net/ipv4/conf/all/forwarding must return 1. I will also reply with the long explanation of why your network addressing is broken and not supposed to work. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#772650: general: Debian could not use gateway in 169.254.0.0 ip range
On Tue, 09 Dec 2014, Maciej Kotliński wrote: It is possible to ping the gateway and other computers in 169.254.1.0/24 network. The packets are not routed by the nat. link-local addresses, such as 169.254.0.0/16 are unroutable. No traffic from/to link-local addresses is allowed to go through* an IP router/gateway. Ever. That means it cannot be retransmitted to a different node (i.e. forwarded). The gateway is correct in dropping these packets when they're not destined to the gateway itself. Please switch to a private-use address range, such as a network inside the 192.168.0.0/16 range. Here's the document that specifies this stuff (for reference, should you need it or if you're curious about it): https://tools.ietf.org/html/rfc6890 The information for the link-local range 169.254.0.0/16 reads as follow (from RFC-6890, table 5): Address Block| 169.254.0.0/16 | Name | Link Local | RFC | [RFC3927] | Allocation Date | May 2005 | Termination Date | N/A| Source | True | Destination | True | Forwardable | False | Global | False | Reserved-by-Protocol | True | Note the forwardable as false. Any packet with a source or destination address in this range MUST NOT be routed or forwarded by a router/gateway. I don't know where is the problem. I know that 169.254.x.x range is assigned to zeroconf and avahi like stuff. Still it should be possible to configure/use the gateway in any ip range you want. It would be very difficult to change the addressing here. To fix this properly, you'll likely have to deploy DHCP to assign forwardable/routable private-use addresses to your IP nodes. I recommend you use something like 192.168.x.y, where x is not in this list: 0, 1, 99 or 100. (that list is an attempt to avoid common factory default addresses for home routers, so that they will not collide with your real network). It is unfortunate that you'll have all this work, but your original configuration *was* invalid as far as the Internet standards go, and it only worked due to a bug in the IP gateway/router. It is now broken as expected. Yeah, I know this is not nice to read, and I understand it is most certainly not what you'd like to read as an answer. But you will likely be better off in the long run if you fix this properly. That said, it may be possible to revert the gateway to an uncompliant configuration that forwards unforwardable packets. I don't know exactly what changed, though, and a quick google search turned out nothing so I cannot help you with a recipe. Maybe someone does and will reply with the specific commands required. However, you *can* use the iptables -v and ip route commands to look at the active packet filter and routing rules, and search for 169.254 there. If you find nothing, also look at the output of ip rule. If you find something referencing 169.254, that's the rule that is blocking the forwarding. If you find nothing, the kernel is enforcing a built-in hardcoded do-not-forward rule for unforwardable packets. It can probably be disabled in /proc/sys/net somewhere. This all assumes you have a IP router/gateway with forwarding enabled, of course. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#772650: general: Debian could not use gateway in 169.254.0.0 ip range
Hello, thanks for fast answer and suggestions. 1) General is the wrong package for this bug. (i assume it's going to get closed, network-manager or ifupdown are probably a better idea). I don't know which one and I'm not sure if it is not somethink else. I haven't found anything like this in bugzilla/google. 2) Assuming the former is causing the problem (because you have eth0 in /etc/network/interfaces). I have only auto lo in /etc/network/interfaces FIX 1) Set managed=true in /etc/NetworkManager/NetworkManager.conf. as per https://wiki.debian.org/NetworkManager#Enabling_Interface_Management (and restart) This doesn't change anything FIX 2) If that fails (and you use network-manager) remove ALL instances of eth0 in /etc/network/interfaces (and restart) Expect this bug to be closed. There are no eth0 lines in /etc/network/interfaces Check network-manager bugs in the bug tracker. And at some point plan a project to change the internal IP range. 169.254.x.x is wrong. I know... this was set here many years ago. Its difficult (people remember addresses, the configuration of printers and such staff). Regards, Maciek -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#772650: general: Debian could not use gateway in 169.254.0.0 ip range
W dniu 09.12.2014 o 17:13, Henrique de Moraes Holschuh pisze: On Tue, 09 Dec 2014, Maciej Kotliński wrote: It is possible to ping the gateway and other computers in 169.254.1.0/24 network. The packets are not routed by the nat. link-local addresses, such as 169.254.0.0/16 are unroutable. No traffic from/to link-local addresses is allowed to go through* an IP router/gateway. Ever. That means it cannot be retransmitted to a different node (i.e. forwarded). The gateway is correct in dropping these packets when they're not destined to the gateway itself. You don't understand what I mean. The gateway is forwarding packages! It is forwarding packages from Windows, Mac, and other Linux boxes in 169.254.x.x Debian Jessie box doesn't send this packages, there is no packages directed outside arriving gateway (tcpdump). This is strange for me and there should be the way to change this behaviour. This is not the matter of forwarding on the gateway. I can forward anything I like with iptables. I know all the story about forwarding. I do not cite the long text. You should know that linux as a router forwards 169.254.x.x traffic as any other range. It is just the matter of what you like. Regards, Maciek -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#772650: general: Debian could not use gateway in 169.254.0.0 ip range
Those have been the fixes for the usual networking problems that have crept up in jessie. I concur with Henrique Holschuh's advice, fix the address range. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#772650: general: Debian could not use gateway in 169.254.0.0 ip range
On 9 December 2014 at 19:12, Anthony F McInerney afm...@gmail.com wrote: Those have been the fixes for the usual networking problems that have crept up in jessie. I concur with Henrique Holschuh's advice, fix the address range. I think in some environments changing the addressing layout is not that simple. @Maciej, could you post all the network-related config of your failing machine? I mean: routing, addresses, firewalling, sysctl, IPv6 and all. Also, I see your kernel is 3.17.4MK. Is a custom kernel? -- Arturo Borrero González -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#772650: general: Debian could not use gateway in 169.254.0.0 ip range
On Tue, 09 Dec 2014, Maciej Kotliński wrote: You don't understand what I mean. The gateway is forwarding packages! It is forwarding packages from Windows, Mac, and other Linux boxes in 169.254.x.x The gateway is doing something it was not supposed to do in the first place. Debian Jessie box doesn't send this packages, there is no packages directed outside arriving gateway (tcpdump). And the computer that is refusing to play along is an end station, not a router. I understand your scenario, now. This is strange for me and there should be the way to change this behaviour. There probably is, I wrote as much. You should know that linux as a router forwards 169.254.x.x traffic as any other range. Not when properly configured. That said, I gave you commands to try to locate where the filtering is going on in the gateway, because I wrongly assumed it was dropping the packets. These commands also work on end stations, but on end stations there are a few other places you have to look at. One that comes to mind is ip addr, check the address scope. If it says scope link, the kernel *knows* this address is unsuitable to talk to anything outside of its network mask. And what the kernel knows, it uses on source address selection. That could well be a false trail, but you did say you understand iptables, so I will assume you verified that no firewall rule is dropping those packets, and that you did verify both the raw and filter tables of iptables. Now, the kernel is not supposed to refuse to send packets silently, it should return an error, and at least ping will issue such error messages back to the user. If this isn't happening, then the problem is likely elsewhere. Other places to look at: /proc/sys/net/* (ip-sysctl.conf), especially bogon filters, etc. /etc/gai.conf (getaddrinfo() configuration for glibc). -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#772650: general: Debian could not use gateway in 169.254.0.0 ip range
W dniu 09.12.2014 o 19:27, Arturo Borrero Gonzalez pisze: I think in some environments changing the addressing layout is not that simple. @Maciej, could you post all the network-related config of your failing machine? I mean: routing, addresses, firewalling, sysctl, IPv6 and all. Also, I see your kernel is 3.17.4MK. Is a custom kernel? Sure: The kernel on my laptop is custom but the virtual machine I've set up runs on stock Debian kernel. Now I will write about virtual machine that I use for testing because it's a fresh install. I configured testing environment with two virtual machines: Windows and Debian Jessie. Both are connected to the same virtual network configured with nat and IP range 169.254.100.0/24. Both virtual machines see (ping) the gateway 169.254.100.1, the machines see each other. Windows machine have normal access to the Internet. Debian don't see anything outside nat. Both machines have second interface to test if every think is working with normal private address range 192.168.x.x. I of course turn it off for testing. Now about the Debian running on the virtual machine: Debian Jessie fresh install Stock Debian kernel (3.16.3-2 2014-09-20). The only network settings are configured by network-manager/dhcp. ip a: 1: lo: LOOPBACK,UP,LOWER_UP mtu 65536 qdisc noqueue state UNKNOWN group default link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever 2: eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 52:54:00:ab:57:39 brd ff:ff:ff:ff:ff:ff 3: eth1: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 52:54:00:91:2b:47 brd ff:ff:ff:ff:ff:ff inet 169.254.100.244/24 brd 169.254.100.255 scope link dynamic eth1 valid_lft 3274sec preferred_lft 3274sec ip r: default via 169.254.100.1 dev eth0 proto static metric 1024 169.254.100.0/24 dev eth0 proto kernel scope link src 169.254.100.244 no IPv6 (disabled in network manager) no firewalling sysctl in attachement Regards, Maciek abi.vsyscall32 = 1 crypto.fips_enabled = 0 debug.exception-trace = 1 debug.kprobes-optimization = 1 dev.cdrom.autoclose = 1 dev.cdrom.autoeject = 0 dev.cdrom.check_media = 0 dev.cdrom.debug = 0 dev.cdrom.info = CD-ROM information, Id: cdrom.c 3.20 2003/12/17 dev.cdrom.info = dev.cdrom.info = drive name:sr0 dev.cdrom.info = drive speed: 4 dev.cdrom.info = drive # of slots: 1 dev.cdrom.info = Can close tray:1 dev.cdrom.info = Can open tray: 1 dev.cdrom.info = Can lock tray: 1 dev.cdrom.info = Can change speed: 1 dev.cdrom.info = Can select disk: 0 dev.cdrom.info = Can read multisession: 1 dev.cdrom.info = Can read MCN: 1 dev.cdrom.info = Reports media changed: 1 dev.cdrom.info = Can play audio:1 dev.cdrom.info = Can write CD-R:0 dev.cdrom.info = Can write CD-RW: 0 dev.cdrom.info = Can read DVD: 1 dev.cdrom.info = Can write DVD-R: 0 dev.cdrom.info = Can write DVD-RAM: 0 dev.cdrom.info = Can read MRW: 1 dev.cdrom.info = Can write MRW: 1 dev.cdrom.info = Can write RAM: 1 dev.cdrom.info = dev.cdrom.info = dev.cdrom.lock = 1 dev.hpet.max-user-freq = 64 dev.mac_hid.mouse_button2_keycode = 97 dev.mac_hid.mouse_button3_keycode = 100 dev.mac_hid.mouse_button_emulation = 0 dev.parport.default.spintime = 500 dev.parport.default.timeslice = 200 dev.scsi.logging_level = 0 fs.aio-max-nr = 65536 fs.aio-nr = 5336 fs.binfmt_misc.status = enabled fs.dentry-state = 40799 28853 45 0 0 0 fs.dir-notify-enable = 1 fs.epoll.max_user_watches = 206376 fs.file-max = 100719 fs.file-nr = 6368 0 100719 fs.inode-nr = 20864 529 fs.inode-state = 20864 529 0 0 0 0 0 fs.inotify.max_queued_events = 16384 fs.inotify.max_user_instances = 128 fs.inotify.max_user_watches = 8192 fs.lease-break-time = 45 fs.leases-enable = 1 fs.mqueue.msg_default = 10 fs.mqueue.msg_max = 10 fs.mqueue.msgsize_default = 8192 fs.mqueue.msgsize_max = 8192 fs.mqueue.queues_max = 256 fs.nfs.nfs_congestion_kb = 32384 fs.nfs.nfs_mountpoint_timeout = 500 fs.nfs.nlm_grace_period = 0 fs.nfs.nlm_tcpport = 0 fs.nfs.nlm_timeout = 10 fs.nfs.nlm_udpport = 0 fs.nfs.nsm_local_state = 0 fs.nfs.nsm_use_hostnames = 0 fs.nr_open = 1048576 fs.overflowgid = 65534 fs.overflowuid = 65534 fs.pipe-max-size = 1048576 fs.protected_hardlinks = 1 fs.protected_symlinks = 1 fs.quota.allocated_dquots = 0 fs.quota.cache_hits = 0 fs.quota.drops = 0 fs.quota.free_dquots = 0 fs.quota.lookups = 0 fs.quota.reads = 0 fs.quota.syncs = 0 fs.quota.warnings = 1 fs.quota.writes = 0 fs.suid_dumpable = 0 fscache.object_max_active = 4 fscache.operation_max_active = 2 kernel.acct = 4 2 30 kernel.acpi_video_flags = 0 kernel.auto_msgmni = 1 kernel.bootloader_type = 114
Bug#772650: general: Debian could not use gateway in 169.254.0.0 ip range
Hi, Please read your previous replies. To repeat: 3: eth1: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 52:54:00:91:2b:47 brd ff:ff:ff:ff:ff:ff inet 169.254.100.244/24 brd 169.254.100.255 scope link dynamic eth1 ..** This is a link-local address. It MUST NOT be used beyond the local network. The presence (or not) of a router on that network does not matter. If Windows really does work with these addresses, that is a Windows bug. Also, a router which does this is misconfigured. Set up your router correctly, e.g. with a 192.168.x.1 address, and turn on DHCP. [ complete sysconf dbump ] Doesn't matter. -- -- Matthias Urlichs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
