firewall: Allow overriding the TTL#606
Conversation
vkareh
force-pushed
the
override-nat-ttl
branch
2 times, most recently
from
c2f6944 to
0f2713a
Compare
|
I think you might have missed the lines that set this for outgoing packets: https://github.com/sshuttle/sshuttle/blob/master/sshuttle/server.py#L194 The more I see this code, the more I wonder if it should be simply deleted. It seems a horrible way to allow ssh to run on the localhost. Which seems a strange thing to do (but requested). And I can't help but think there should be a better way of doing this. |
|
Just wanted to comment on the use case. We have the same issue. Our use case is running a container in a container with docker-in-docker. sshuttle is running on the outer container. So we basically run into the exact same issue. Deleting the TTL rule is a valid workaround for me because in my use case I don't want to run sshuttle client and server on the same "host"/network namespace (I guess container in my case). I'm no iptables expert by any means. I saw that calico is solving a similar use case by marking packages. But I have no idea if this would also work in this case as replacement for the TTL "match". |
In instances where a cluster pod in a local VM needs to access a server that is sshuttle'd from the host, since the packets arriving at the host already made a hop, their TTL is 63 and so get ignored by sshuttle. Allowing an override of the firewall TTL rule allows the packets to go through.
Yes, thanks! I've updated the PR to include them |
Yes, I tested this and it works for me as well, but I feel that other users might have a valid scenario needing the TTL rule, so removing it seems unnecessarily disruptive for this PR. My use case is running an openshift cluster inside a local VM that connects to another (sshuttled) openshift cluster. Setting the TTL to 64 allows those clusters to talk to one another. Setting it to 65 allows both the VM'd cluster and my host system/browser to connect to the remote cluster. |
|
@vkareh yeah deleting the rule is definitely just a temporary workaround. A permanent solution would be great. |
Previously, it was possible to run sshuttle locally without using ssh and connecting to a remote server. In this configuration, traffic was redirected to the sshuttle server running on the localhost. However, the firewall needed to distinguish between traffic leaving the sshuttle server and traffic that originated from the machine that still needed to be routed through the sshuttle server. The TTL of the packets leaving the sshuttle server were manipulated to indicate to the firewall what should happen. The TTL was adjusted for all packets leaving the sshuttle server (even if it wasn't necessary because the server and client were running on different machines). Changing the TTL caused trouble and some machines, and the --ttl option was added as a workaround to change how the TTL was set for traffic leaving sshuttle. All of this added complexity to the code for a feature (running the server on localhost) that is likely only used for testing and rarely used by others. This commit updates the associated documentation, but doesn't fully fix the ipfw method since I am unable to test that. This change will also make sshuttle fail to work if -r is used to specify a localhost. Pull request sshuttle#610 partially addresses that issue. For example, see: sshuttle#240, sshuttle#490, sshuttle#660, sshuttle#606.
3 participants
In instances where a cluster pod in a local VM needs to access a server
that is sshuttle'd from the host, since the packets arriving at the host
already made a hop, their TTL is 63 and so get ignored by sshuttle.
Allowing an override of the firewall TTL rule allows the packets to go
through.