I am unable to access devices on a link-local interface within a docker instance when uses a bridged network.
I tried pinging the device and can see the ping going out of the right interface using wireshark, however, the source IP is not the link local interface ip (thus on the wrong subnet) so the device rejects it.
I assumed the addresses would be masqueraded like for public domains but that doesn’t seem to be the case for link-local.
Is there any way to get this to work with bridged networking? I tried modifying IP tables with no luck.
A container on a bridge network is not in the same subnet. Why do you want a link local address? If you just want to access the host, you can use the gateway of the network which will be the ip of the host on that network. OF course the service that you want to access has to listen on that ip address.
I have a device which is default configured to use a link-local connection and I am connecting to it on an interface on my machine also configured with link-local. It will reject(as expected) any data not from another link-local address. It would be very convenient not to have to worry if the device is link local or not, plus there wouldn’t be the confusion of why access isn’t working.
I’m not sure what you mean about using the gateway of the host network. I don’t think that would get my internal docker communication coming from the address I want?
Based on the section of a Kurbenetes article at IP Masquerade Agent User Guide | Kubernetes it seems they support masquerade for link local, but I’m not sure how to do it on 169.254 addresses because as far as I can tell iptables will ignore Masquerade in that range.
masqLinkLocal: A Boolean (true/false) which indicates whether to masquerade traffic to the link local prefix 169.254.0.0/16. False by default.
I thought you wanted to access a port on the host operating system from the container. Thanks for the link, I have read it and I can’t say I completely understand it, but at least I think I understand you want to communicate with another host not the host of the container…