Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

iptables rule - move from OUTPUT => PREROUTING #321

Closed
ianmiell opened this Issue Jul 19, 2018 · 28 comments

Comments

Projects
None yet
2 participants
@ianmiell
Copy link

ianmiell commented Jul 19, 2018

I had an issue with iptables on linux, moving from ubuntu 16.04 to 18.04.

It seems that there was a kernel change between the two versions (17.xx) which affects the OUTPUT chain, which now fails to forward properly. I can't find proof of this.

From experimenting it seems that changing OUTPUT to PREROUTING works on both 16.04 and 18.04, so is a change as simple as that likely to be accepted?

See also here, where I originally raised this with the vagrant image maintainer before looking back at landrush:

chef/bento#1086

@hferentschik

This comment has been minimized.

Copy link
Contributor

hferentschik commented Sep 3, 2018

Just so that we are on the same line, what is the error you are seeing? I get a:

  ../../../../lib/isc/unix/socket.c:2135: internal_send: 127.0.0.53#53: Invalid argument

I am not so sure whether changing OUTPUT to PREROUTING is going to work. My understanding is that locally generated packages flow through OUTPUT and not through PREROUTING. See also https://www.karlrupp.net/en/computer/nat_tutorial:

For locally generated packets there is a small difference: Instead of passing through the PREROUTING chain it passes the OUTPUT chain and then moves on to the POSTROUTING chain.

I could be wrong, but I think with the suggested change the redirection of the DNS traffic just does not occur and hence the error does not get triggered.

I am wondering whether the issue is related to Ubuntu's switch to systemd-resolved? However, I even get this error when I stop systemd-resolved. Not quite sure what's going on tbh.

@hferentschik hferentschik changed the title iptables rule - move from OUTPUT => PREROUTING? iptables rule - move from OUTPUT => PREROUTING Sep 3, 2018

@ianmiell

This comment has been minimized.

Copy link
Author

ianmiell commented Sep 4, 2018

If memory serves, I tested by using a script that creates a VM with landrush. When running 18.04 networking doesn't work if landrush is used. When I changed the rule to PREROUTING all works fine. I also tried this in 16.xx and it continued to work.

I'll try and get a more detailed repro later.

@ianmiell

This comment has been minimized.

Copy link
Author

ianmiell commented Sep 5, 2018

Yes, you're right. I can't figure it out, as I can telnet direct to the landrush port from the VM, and the iptables rule looks correct, and I can dig via that IP/port:


root@foo:~# iptables -L -t nat
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
DNAT       tcp  --  anywhere             127.0.0.53           tcp dpt:domain to:10.0.2.2:10053
DNAT       udp  --  anywhere             127.0.0.53           udp dpt:domain to:10.0.2.2:10053

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination

root@foo:~# dig @10.0.2.2 -p 10053 google.com

; <<>> DiG 9.11.3-1ubuntu1-Ubuntu <<>> @10.0.2.2 -p 10053 google.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34035
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;google.com.			IN	A

;; ANSWER SECTION:
google.com.		176	IN	A	216.58.204.14

;; Query time: 177 msec
;; SERVER: 10.0.2.2#10053(10.0.2.2)
;; WHEN: Wed Sep 05 10:48:54 UTC 2018
;; MSG SIZE  rcvd: 44

Running a curl command gets me this error:

root@foo:~# strace -f -o out curl google.com
curl: (6) Could not resolve host: google.com

and the strace suggests (in the middle) that something goes wrong when sendmmsg is called:

2354  socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3
2354  connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, 16) = 0
2354  poll([{fd=3, events=POLLOUT}], 1, 0) = 1 ([{fd=3, revents=POLLOUT}])
2354  sendmmsg(3, [{msg_hdr={msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\272\322\1\0\0\1\0\0\0\0\0\0\6google\3com\0\0\1\0\1", iov_len=28}], msg_iovlen=1, msg_controllen=0, msg_flags=0}}, {msg_hdr={msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\262\327\1\0\0\1\0\0\0\0\0\0\6google\3com\0\0\34\0\1", iov_len=28}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_TRUNC|MSG_DONTWAIT|MSG_FIN|MSG_SYN|MSG_NOSIGNAL|MSG_BATCH|MSG_ZEROCOPY|MSG_FASTOPEN|0x9a480000}}], 2, MSG_NOSIGNAL) = -1 EINVAL (Invalid argument)
2354  close(3)                          = 0
2354  socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3
2354  connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, 16) = 0
2354  poll([{fd=3, events=POLLOUT}], 1, 0) = 1 ([{fd=3, revents=POLLOUT}])
2354  sendmmsg(3, [{msg_hdr={msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\272\322\1\0\0\1\0\0\0\0\0\0\6google\3com\0\0\1\0\1", iov_len=28}], msg_iovlen=1, msg_controllen=0, msg_flags=0}}, {msg_hdr={msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\262\327\1\0\0\1\0\0\0\0\0\0\6google\3com\0\0\34\0\1", iov_len=28}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_TRUNC|MSG_DONTWAIT|MSG_FIN|MSG_SYN|MSG_NOSIGNAL|MSG_BATCH|MSG_ZEROCOPY|MSG_FASTOPEN|0x9a480000}}], 2, MSG_NOSIGNAL) = -1 EINVAL (Invalid argument)
2354  close(3)                          = 0
2354  socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3
2354  connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, 16) = 0
2354  poll([{fd=3, events=POLLOUT}], 1, 0) = 1 ([{fd=3, revents=POLLOUT}])
2354  sendmmsg(3, [{msg_hdr={msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\356m\1\0\0\1\0\0\0\0\0\0\6google\3com\5local\0\0\1"..., iov_len=34}], msg_iovlen=1, msg_controllen=0, msg_flags=0}}, {msg_hdr={msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\32q\1\0\0\1\0\0\0\0\0\0\6google\3com\5local\0\0\34"..., iov_len=34}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_WAITALL|MSG_CONFIRM|MSG_ERRQUEUE|MSG_NOSIGNAL|MSG_MORE|MSG_WAITFORONE|MSG_BATCH|0x91ba0010}}], 2, MSG_NOSIGNAL) = -1 EINVAL (Invalid argument)
2354  close(3)                          = 0
2354  socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3
2354  connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, 16) = 0
2354  poll([{fd=3, events=POLLOUT}], 1, 0) = 1 ([{fd=3, revents=POLLOUT}])
2354  sendmmsg(3, [{msg_hdr={msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\356m\1\0\0\1\0\0\0\0\0\0\6google\3com\5local\0\0\1"..., iov_len=34}], msg_iovlen=1, msg_controllen=0, msg_flags=0}}, {msg_hdr={msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\32q\1\0\0\1\0\0\0\0\0\0\6google\3com\5local\0\0\34"..., iov_len=34}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_WAITALL|MSG_CONFIRM|MSG_ERRQUEUE|MSG_NOSIGNAL|MSG_MORE|MSG_WAITFORONE|MSG_BATCH|0x91ba0010}}], 2, MSG_NOSIGNAL) = -1 EINVAL (Invalid argument)
2354  close(3)                          = 0
2354  madvise(0x7ff691400000, 8368128, MADV_DONTNEED) = 0
2354  exit(0)                           = ?
2354  +++ exited with 0 +++

which perplexes me - has the syscall changed in the kernel and now doesn't like the iptables rule? Surely that would be a big bug.

@ianmiell

This comment has been minimized.

Copy link
Author

ianmiell commented Sep 5, 2018

If I wipe the iptables rules:

root@foo:~# iptables -t nat -D OUTPUT 1
root@foo:~# iptables -t nat -D OUTPUT 1
root@foo:~# strace -f -o out2 curl google.com
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>301 Moved</TITLE></HEAD><BODY>
<H1>301 Moved</H1>
The document has moved
<A HREF="http://www.google.com/">here</A>.
</BODY></HTML>

the sendmmsg succeeds:

2397  sendmmsg(3, [{msg_hdr={msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\246\302\1\0\0\1\0\0\0\0\0\0\6google\3com\0\0\1\0\1", iov_len=28}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, msg_len=28}, {msg_hdr={msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\236\307\1\0\0\1\0\0\0\0\0\0\6google\3com\0\0\34\0\1", iov_len=28}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_TRUNC|MSG_DONTWAIT|MSG_FIN|MSG_SYN|MSG_ERRQUEUE|MSG_MORE|MSG_WAITFORONE|MSG_ZEROCOPY|MSG_FASTOPEN|MSG_CMSG_CLOEXEC|0x11f20000}, msg_len=28}], 2, MSG_NOSIGNAL) = 2

The difference appears to be the msg_len is dropped when the iptables rule is there:


root@foo:~# cat tmp
sendmmsg(3, [{msg_hdr={msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\272\322\1\0\0\1\0\0\0\0\0\0\6google\3com\0\0\1\0\1", iov_len=28}], msg_iovlen=1, msg_controllen=0, msg_flags=0}}, {msg_hdr={msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\262\327\1\0\0\1\0\0\0\0\0\0\6google\3com\0\0\34\0\1", iov_len=28}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_TRUNC|MSG_DONTWAIT|MSG_FIN|MSG_SYN|MSG_NOSIGNAL|MSG_BATCH|MSG_ZEROCOPY|MSG_FASTOPEN|0x9a480000}}], 2, MSG_NOSIGNAL) = -1 EINVAL (Invalid argument)
root@foo:~# cat tmp2
sendmmsg(3, [{msg_hdr={msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\246\302\1\0\0\1\0\0\0\0\0\0\6google\3com\0\0\1\0\1", iov_len=28}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, msg_len=28}, {msg_hdr={msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\236\307\1\0\0\1\0\0\0\0\0\0\6google\3com\0\0\34\0\1", iov_len=28}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_TRUNC|MSG_DONTWAIT|MSG_FIN|MSG_SYN|MSG_ERRQUEUE|MSG_MORE|MSG_WAITFORONE|MSG_ZEROCOPY|MSG_FASTOPEN|MSG_CMSG_CLOEXEC|0x11f20000}, msg_len=28}], 2, MSG_NOSIGNAL) = 2
@ianmiell

This comment has been minimized.

Copy link
Author

ianmiell commented Sep 5, 2018

Now on xenial, which 'works' and resolves static1.example.com fine:

root@foo:~# iptables -L -t nat
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
DNAT       tcp  --  anywhere             10.0.2.3             tcp dpt:domain to:10.0.2.2:10053
DNAT       udp  --  anywhere             10.0.2.3             udp dpt:domain to:10.0.2.2:10053

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
root@foo:~# strace -f -o out curl google.com
...
2205  sendmmsg(4, {{{msg_name(0)=NULL, msg_iov(1)=[{"b\32\1\0\0\1\0\0\0\0\0\0\6google\3com\0\0\1\0\1", 28}], msg_controllen=0, msg_flags=MSG_DONTROUTE|MSG_DONTWAIT|MSG_EOR|MSG_WAITALL|MSG_RST|MSG_ERRQUEUE|MSG_NOSIGNAL|MSG_WAITFORONE|MSG_CMSG_CLOEXEC|0x1f2c0010}, 28}, {{msg_name(0)=NULL, msg_iov(1)=[{"n2\1\0\0\1\0\0\0\0\0\0\6google\3com\0\0\34\0\1", 28}], msg_controllen=0, msg_flags=MSG_OOB|MSG_DONTROUTE|MSG_CTRUNC|0x10}, 28}}, 2, MSG_NOSIGNAL) = 2

No msg_len there and it works. It's different in other ways too. Why?

@hferentschik

This comment has been minimized.

Copy link
Contributor

hferentschik commented Sep 6, 2018

Nice digging.

Yes, you're right. I can't figure it out, as I can telnet direct to the landrush port from the VM, and the iptables rule looks correct, and I can dig via that IP/port:

Right, I don't think there is an issue with the reachability of the Landrush process on the host. This can easily be proven via telnet or dig.

The difference appears to be the msg_len is dropped when the iptables rule is there:

Interesting. Unfortunately, I don't know (yet) if and how this could cause the issue we are seeing. It's a good lead for sure.

which perplexes me - has the syscall changed in the kernel and now doesn't like the iptables rule? Surely that would be a big bug.

Same here. If this is a Kernel/iptables issue, it would indeed be a big bug and I would expect to find something about it on the web.

One thing which might be worth trying is to isolate completely form Landrush and DNS. What if one would try something similar against port 80. Trying to nat traffic for 127.0.0.[1|53]:80 to say port 8080 on the host (trying to reach a web server). If that fails as well, I would say there is for sure a Kernel/iptables bug. If not, I am wondering whether somehow systemd-resolv plays a role. There are various stories out there where systemd-resolve seems to screw things up. One could try to uninstall systemd-resolve and let NetworkManager handle DNS (https://askubuntu.com/questions/907246/how-to-disable-systemd-resolved-in-ubuntu) or maybe even install resolvconf.

WDYT?

@ianmiell

This comment has been minimized.

Copy link
Author

ianmiell commented Sep 6, 2018

@hferentschik

This comment has been minimized.

Copy link
Contributor

hferentschik commented Sep 6, 2018

I became a bit obsessed with how messed up DNS was on linux so wrote these
articles, which you may see mistakes in:

Awesome posts. I fully feel the pain you went through discovering all this. Something which is in theory so simple (and maybe even was once upon a time), is truly screwed up our days. I recognise a lot of what you wrote and can confirm it with my own experiences. I wish your writeup would have existed when I was sifting through some of this.

It might be nice to link your articles somewhere in the docs. Maybe in the dev document or maybe even the user one. I think it helps potential contributors and maybe users to understand what is actually going on. It also explains why things are not so easy for Landrush. Contrary to macOS and Windows where things are more uniform, each Linux distro seems to so things a bit differently.

Feel free to create an issue and pull request to update the docs at some appropriate point.

systemd resolve 'should' not be a problem, but I agree with removing it as a factor.

"should" :-) One does not know for sure until one tries. Personally it is beyond me why systemd-resolve was needed. In fact the whole systemd thing beats me a bit. I can see some benefits for sure, but I would also agree that it went too far.

I was thinking another angle on top of any other kind of firewall would be to isolate the kernel version.

Sure.

BTW, regarding your articles. One angle you are not addressing is caching. Not only are there various ways to do DNS lookups, there also multiple levels of caching. Some applications, like browser, implement their own lookup+caching. This can get really painful when setting up dynamic dev environments. Even if one knows how to clear the system DNS cache, it does not imply that your app/browser will pick up on a DNS change.

@hferentschik

This comment has been minimized.

Copy link
Contributor

hferentschik commented Sep 6, 2018

Have you by any chance already compared iptables versions between the two Ubuntu versions? That's another angle.

@ianmiell

This comment has been minimized.

Copy link
Author

ianmiell commented Sep 8, 2018

Yes, I did look at that, but they were effectively the same, except for the systemd-resolved differences.

@ianmiell

This comment has been minimized.

Copy link
Author

ianmiell commented Sep 8, 2018

Tried re-routing to google DNS to remove LR from the equation.

root@foo:~# iptables -L -t nat
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
DNAT       tcp  --  anywhere             127.0.0.53           tcp dpt:domain to:8.8.8.8:53
DNAT       udp  --  anywhere             127.0.0.53           udp dpt:domain to:8.8.8.8:53

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
root@foo:~# ping google.com
ping: google.com: Temporary failure in name resolution
@ianmiell

This comment has been minimized.

Copy link
Author

ianmiell commented Sep 8, 2018

This works.

resolv.conf updated to point to 10.0.2.2, iptables points to same. I think this proves systemd-resolved is the problem:

root@foo:~# cat /etc/resolv.conf
# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "systemd-resolve --status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs must not access this file directly, but only through the
# symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a different way,
# replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 10.0.2.2
search home
root@foo:~# iptables -L -t nat
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
DNAT       tcp  --  anywhere             10.0.2.2             tcp dpt:domain to:10.0.2.2:10053
DNAT       udp  --  anywhere             10.0.2.2             udp dpt:domain to:10.0.2.2:10053

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination

pings:

root@foo:~# ping -c1 google.com
PING google.com (216.58.212.78) 56(84) bytes of data.
64 bytes from lhr35s05-in-f14.1e100.net (216.58.212.78): icmp_seq=1 ttl=63 time=8.12 ms

--- google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 8.121/8.121/8.121/0.000 ms
root@foo:~# ping -c1 static1.example.com
PING static1.example.com (1.2.3.4) 56(84) bytes of data.
^C
--- static1.example.com ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
@ianmiell

This comment has been minimized.

Copy link
Author

ianmiell commented Sep 8, 2018

Simple repro:

vagrant init ubuntu/bionic64
vagrant up
vagrant ssh
sudo su
ping -c1 google.com
iptables -t nat -A OUTPUT -p udp --dport 53 -j DNAT -d 127.0.0.53 --to 8.8.8.8
ping -c1 google.com

Second ping fails.

@ianmiell

This comment has been minimized.

Copy link
Author

ianmiell commented Sep 8, 2018

However, if I take systemd-resolved out of the equation:

sed -i 's/127.0.0.53/127.0.0.54/' /etc/resolv.conf
iptables -t nat -A OUTPUT -p udp --dport 53 -j DNAT -d 127.0.0.54 --to 8.8.8.8

it also fails.

@ianmiell

This comment has been minimized.

Copy link
Author

ianmiell commented Sep 8, 2018

However, works on xenial:

vagrant init ubuntu/xenial64
vagrant up
vagrant ssh
sudo su
ping -c1 google.com
iptables -t nat -A OUTPUT -p udp --dport 53 -j DNAT -d 10.0.2.3 --to 8.8.8.8
ping -c1 google.com

Second ping succeeds.

@ianmiell

This comment has been minimized.

Copy link
Author

ianmiell commented Sep 8, 2018

But this works... (bionic)

sed -i 's/127.0.0.53/10.0.2.3/' /etc/resolv.conf
iptables -t nat -A OUTPUT -p udp --dport 53 -j DNAT -d 10.0.2.3 --to 8.8.8.8
@ianmiell

This comment has been minimized.

Copy link
Author

ianmiell commented Sep 8, 2018

This also works (bionic):

sed -i 's/127.0.0.53/10.0.2.3/' /etc/resolv.conf
iptables -F -t nat
iptables -t nat -A OUTPUT -p udp --dport 53 -j DNAT -d 10.0.2.3 --to 10.0.2.2:10053
@ianmiell

This comment has been minimized.

Copy link
Author

ianmiell commented Sep 8, 2018

I'm starting to think it's a problem of mixing localhost and non-localhost addresses in iptables rules.

@ianmiell

This comment has been minimized.

Copy link
Author

ianmiell commented Sep 8, 2018

Figured it out :)

https://serverfault.com/questions/211536/iptables-port-redirect-not-working-for-localhost

This makes it all lovely again:

sysctl -w net.ipv4.conf.all.route_localnet=1
@ianmiell

This comment has been minimized.

Copy link
Author

ianmiell commented Sep 8, 2018

So the problem appears to be that systemd-resolved uses the localhost address space, and forwarding this is prevented in the kernel by default.

Not sure how you'd want to handle this in your code.

One option might be:

imiell@Ians-MacBook-Air-2:/space/git/landrush/lib/landrush/cap/guest/linux  ⑂ master +    git diff
diff --git a/lib/landrush/cap/guest/linux/add_iptables_rule.rb b/lib/landrush/cap/guest/linux/add_iptables_rule.rb
index b585b1b..4cc9970 100644
--- a/lib/landrush/cap/guest/linux/add_iptables_rule.rb
+++ b/lib/landrush/cap/guest/linux/add_iptables_rule.rb
@@ -4,6 +4,7 @@ module Landrush
       module AddIptablesRule
         def self.add_iptables_rule(machine, rule)
           _run(machine, %(iptables -C #{rule} 2> /dev/null || iptables -A #{rule}))
+          _run(machine, %(sysctl -w net.ipv4.conf.all.route_localnet=1))
         end

         def self._run(machine, command)
@ianmiell

This comment has been minimized.

@hferentschik

This comment has been minimized.

Copy link
Contributor

hferentschik commented Sep 8, 2018

Not sure how you'd want to handle this in your code.

I guess running the sysctl command would work. Does this work on all distros? Atm, this code is in the general linux capability. Also is it backwards compatible? I think setting net.ipv4.conf.all.route_localnet is probably the way forward, question is whether we need to differentiate distribution/version as well. WDYT?

@hferentschik

This comment has been minimized.

Copy link
Contributor

hferentschik commented Sep 8, 2018

So is this a new kernel option or has the default been changed? If this is new one wonders what happens when one calls sysctl -w net.ipv4.conf.all.route_localnet=1) if the option does not exist?

@ianmiell

This comment has been minimized.

Copy link
Author

ianmiell commented Sep 8, 2018

@hferentschik

This comment has been minimized.

Copy link
Contributor

hferentschik commented Sep 10, 2018

I guess the most appropriate solution would be to

  1. Check whether the source is localhost (one might have to reshuffle some code for that since at the moment you only get the whole rule passed to add_iptables_rule.
  2. If source is localhost, check ensure sysctl is available (it might be given on Linux in which case we can just make the call to set route_localnet. ( Not sure whether we also need to write the setting into /etc/sysctl.conf. sysctl -w is not persistent. Need to make sure capabilities are always called, also in `vagrant halt && vagrant up``

@hferentschik hferentschik modified the milestones: v1.3.0, v1.3.1 Sep 19, 2018

@ianmiell

This comment has been minimized.

Copy link
Author

ianmiell commented Sep 30, 2018

Had a quick look at the code:

it appears that: lib/landrush/cap/guest/linux/redirect_dns.rb

gets the configured dns servers and iterates through them.

At the point we can capture whether the server is on localhost / 127.0.0.x.

If so, then we can see whether sysctl is not appropriately set, and use sysctl or (preferable) echo to /proc directly (if possible).

Do we want to revert to the original setting on vagrant halt?

I'm not sure what 'Need to make sure capabilities are always called, also in `vagrant halt && vagrant up``' means?

@hferentschik

This comment has been minimized.

Copy link
Contributor

hferentschik commented Oct 3, 2018

it appears that: lib/landrush/cap/guest/linux/redirect_dns.rb
gets the configured dns servers and iterates through them.

Correct.

At the point we can capture whether the server is on localhost / 127.0.0.x.

Sounds like a plan.

If so, then we can see whether sysctl is not appropriately set, and use sysctl or (preferable) echo to /proc directly (if possible).

+1. Maybe as another guest capability, so that we have the option to do something guest specific in case it is needed.

Do we want to revert to the original setting on vagrant halt?

I don't think this is needed, especially since the settings are not persistent anyways. My understanding is that in order to persist settings one needs to edit /etc/sysctl.conf. Using sysctl changes the settings for the current running machine.

I'm not sure what 'Need to make sure capabilities are always called, also in `vagrant halt && vagrant up``' means?

Sorry, I was unclear. Certain callbacks (provisioning) are only made during the initial startup and don't occur during a vagrant halt && vagrant up cycle. Given that changes via sysctl are not persistent, I was concerned whether the kernel option change would not occur when doing vagrant halt && vagrant up. Looking at the code a bit more, I don't think this is an issue. redirect_dns will always be called (see also plugin.rb). So using sysctl should work and we also would not have to clean anything up afterwards. Does this make more sense now?

hferentschik added a commit to hferentschik/landrush that referenced this issue Nov 27, 2018

hferentschik added a commit to hferentschik/landrush that referenced this issue Nov 27, 2018

hferentschik added a commit to hferentschik/landrush that referenced this issue Nov 28, 2018

hferentschik added a commit to hferentschik/landrush that referenced this issue Nov 28, 2018

hferentschik added a commit to hferentschik/landrush that referenced this issue Nov 29, 2018

hferentschik added a commit to hferentschik/landrush that referenced this issue Dec 3, 2018

Issue vagrant-landrush#321 Making sure route_localnet is enabled in k…
…ernel

- Aligning some info messages format

hferentschik added a commit to hferentschik/landrush that referenced this issue Dec 3, 2018

Issue vagrant-landrush#321 Making sure route_localnet is enabled in k…
…ernel

- Aligning some info messages format

hferentschik added a commit to hferentschik/landrush that referenced this issue Dec 3, 2018

Issue vagrant-landrush#321 Making sure route_localnet is enabled in k…
…ernel

- Aligning some info messages format

hferentschik added a commit to hferentschik/landrush that referenced this issue Dec 3, 2018

hferentschik added a commit to hferentschik/landrush that referenced this issue Dec 4, 2018

Issue vagrant-landrush#321 Updating and moving release docs.
- Adding version badge to README
@hferentschik

This comment has been minimized.

Copy link
Contributor

hferentschik commented Dec 4, 2018

Merged via pull request #336

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.