Closed port 22 in the jail redirects to the outer system

Arthur Chance freebsd at
Thu Dec 8 17:33:44 UTC 2016

On 08/12/2016 17:20, Robroy Gregg wrote:
> Good day Bertram,
> On Wed, 7 Dec 2016, Bertram Scharpf wrote:
>> On Tuesday, 06. Dec 2016, 22:05:09 -0800, Robroy Gregg wrote:
>>> Bertram Scharpf wrote:
>>>> How can I make a port 22 request fail if an SSH server is running on
>>>> the
>>>> outer machine but not inside the jail?
>>> If I've understood your situation correctly, the idea here's to
>>> configure
>>> the host FreeBSD system's ssh daemon to associate itself only with the
>>> host system's IP address.
>>> By default, the ssh daemon associates itself with all IP addresses your
>>> computer's configured to use (host + jails), which leads to the
>>> fall-through effect you're experiencing when your jail's ssh daemon
>>> isn't
>>> running.
>> That's exactly what I meant. I don't know why, but I always thought a
>> jail should grab all requests on its IP and then look up a server
>> process.
> Bertram, I think you probably understand these details already, but I'll
> add a few comments.
> Original, non-VNET jails share networking with the host in a way which
> takes some getting used to.  Yet once you are used to it, its simplicity
> has a lot of appeal, when compared to other virtualization styles which
> have more stuff (code, bugs) sandwiched in between the guest and the host.
> I'm not sure if this is always true, yet I've noticed that when a
> process on the host and a process in a jail both (effectively) listen on
> the same IP and port, the process in the jail will "win."  Incoming
> traffic will go to the jailed process.  Yet if that process exits, the
> same incoming traffic will then "fall through" to the host, which could
> obviously be a really bad thing.
> As others have mentioned, setting up a host to run jails means
> configuring daemons on the host to listen only on the host's specific IP
> address, and not on a catch-all address.
> The NFS server's another classic example of something that makes itself
> available on all of the computer's IPs (host + jails) by default, and
> has to be configured to avoid using IPs assigned to jails--otherwise,
> the jails themselves will look like NFS servers, which is probably not
> what anybody would want.
> These configuration changes aren't necessary inside of the jails
> themselves, since they're prevented from listening on, or sending
> traffic from any IP address other than what they've been configured to
> use.  If a jailed process tries to send a packet with any IP other than
> its configured IP, it'll silently be re-written to match the jail's
> configured IP before being sent out.
> I have noticed though, that some programs (like Samba), will log errors
> when they start in a jail, unless they're explicitly configured to use
> only the jail's IP address.  It's as though their attempt to bind to a
> catch-all address can return an error, despite working--at least
> insofar as the process binding successfully to the jail's IP (a subset
> of what the process tried to bind to).  So though it's much less likely
> to be necessary, things may run more cleanly in the jail if they're
> configured explicitly to bind to the jail's IP.

A minor point about this. Depending on your admin tools it could be an
administrative pain ensuring that each jail's config for such programs
has the correct IP address to match the jail. To avoid that possible
problem, set the listening IP address to The networking code
in jails silently rewrites that as the jail's first actual IPv4 address
(and ditto ::1 for IPv6). That way you can use the localhost address for
90+% of your configurations.

>>> On the host system, edit /etc/ssh/sshd_config, and add a line like this,
>>> assuming your host system's IP is
>>> ListenAddress
>> I should have found this myself. Sorry for the noise.
> 'happy to have had a chance to reply to one of the few things I happen
> to know about.
>> Thank you!
> You're welcome Bertram!
> Robroy

Schrödinger's cat had 18 half lives.

More information about the freebsd-questions mailing list