moby: Inconsistent source IPs in containers
Hi,
I’m running rsyslog in a container. Basically just an ubuntu image with rsyslogd installed and a template configuration like this:
$template FILENAME,"/var/log/%fromhost-ip%/%hostname%/syslog.log"
Exposed ports in Dockerfile: EXPOSE 514/tcp 514/udp
Now this works in general just fine, but I discovered some strange behavior regarding the source IP of the syslog packets: Sometimes the messages for remote systems end up in [remote-host-ip]/[container-hostname]/syslog.log
, then after some time, they end up in [docker0-bridges-ip]/[container-hostname]/syslog.log
. This seems to flip around from now and then.
As far as I understand, the expected behavior is:
- If you connect to a exposed port from localhost, inside the container the source IP is the IP of the docker0 bridge
- If you connect to a exposed port from a remote system, the source IP is the IP of the remote system
But it seems somehow those packets get routed via the docker0 IP and sometimes not. This makes not only running a syslog server hard but also debugging request logs in general.
About this issue
- Original URL
- State: closed
- Created 10 years ago
- Comments: 34 (22 by maintainers)
Commits related to this issue
- Clear conntrack entries for UDP ports Conntrack entries are created for UDP flows even if there's nowhere to route these packets (ie. no listening socket and no NAT rules to apply). Moreover, iptable... — committed to akerouanton/docker by akerouanton a year ago
- Clear conntrack entries for published UDP ports Conntrack entries are created for UDP flows even if there's nowhere to route these packets (ie. no listening socket and no NAT rules to apply). Moreove... — committed to akerouanton/docker by akerouanton a year ago
- Clear conntrack entries for published UDP ports Conntrack entries are created for UDP flows even if there's nowhere to route these packets (ie. no listening socket and no NAT rules to apply). Moreove... — committed to akerouanton/docker by akerouanton a year ago
- Clear conntrack entries for published UDP ports Conntrack entries are created for UDP flows even if there's nowhere to route these packets (ie. no listening socket and no NAT rules to apply). Moreove... — committed to corhere/moby by akerouanton a year ago
- Clear conntrack entries for published UDP ports Conntrack entries are created for UDP flows even if there's nowhere to route these packets (ie. no listening socket and no NAT rules to apply). Moreove... — committed to akerouanton/docker by akerouanton a year ago
@sanimej You’re not using udp. See my initial description and try to reproduce with rsyslogd. This issue is two years old, I stopped using Docker for anything udp long time ago… So won’t be able to test it.