# Jail loopback interface question



## wonslung (Nov 22, 2013)

I was curious whether or not it was possible to run a jail on the same IP as the base system, so *I* decided to try it.

I was able to get dns/bind99 and net/isc-dhcp42-server installed and working in the jail but *I* noticed that the loopback device seems to point to the host system. I was wondering why this is true and if there is a way to fix it.


----------



## fluca1978 (Nov 22, 2013)

First of all I don't see the point in running the jail on the same address of the host: the latter should be very confused to where to deliver packets!
However, what do you mean with "pointing to the host system"? I configured a jail with the same address and the loopback interface look normal to me.


----------



## wonslung (Nov 25, 2013)

Let's say the host is 192.168.1.1 has sshd running on port 22.   Create a new jail running on 192.168.1.1 and set ssh to run on port 2222.   If you are in the jail and do: `ssh 127.0.0.1` it will log into the host.   If you are logged into the host and do `ssh -p 2222 127.0.0.1` it will not log into the jail. If you make a third jail on 192.168.1.1 and set its sshd to run on port 2223 you will be able to ssh into both jails from the host (and from both jails).  You will be able to ssh into the host from the third jail, but again it won't work from the host to the jail.


----------



## ShelLuser (Nov 25, 2013)

wonslung said:
			
		

> Let's say the host is 192.168.1.1 has sshd running on port 22.   Create a new jail running on 192.168.1.1 and set ssh to run on port 2222.   If you are in the jail and do:
> 
> `ssh 127.0.0.1`   It will log into the host.


No, it won't. If you're logged onto the jail or have started a shell within the jail (see jexec for that) then `ssh 127.0.0.1` will log you onto the jail, _not_ the host.

If this happens on your end then you most likely did not properly use the jail.


----------



## wonslung (Nov 25, 2013)

ShelLuser said:
			
		

> wonslung said:
> 
> 
> 
> ...


Under normal circumstances you're right.  (Where jails don't share the same IP.) Under the circumstances *I* describe,  what *I* said happens happens.  I've tried it on two fresh installs, go try it.

Install freebsd FreeBSD and set the IP on one of your interfaces to something, let's say 192.168.1.1.
Create two jails with the same IP as above.
Set sshd in both jails to run on a different port, 2222 and 2223 respectively.
If you do `ssh 127.0.0.1` in either jail, it will ssh to the host system. If you do `ssh -p 2222 127.0.0.1` from either jail it will ssh to the jail with sshd set to port 2222. If you do the same as above from the host it will fail.

I've tried this several times.


----------



## ShelLuser (Nov 25, 2013)

Ah yes, my mistake. I overlooked that part.

Well, in that case I consider it to be a non-issue (no offense) because such a setup is basically broken to begin with.

Having said that I do share your curiosity for the reason why this might happen. My theory is because although a jail is a separated process it always shares some features from the host. The jail's IP address for example is simply an alias which gets added to the main network interface card.

I could imagine, but this is pure speculation mind you, that the system might have been tricked to use the same approach with the localhost. So instead of creating it's own loopback device it simply tried to add an alias, which didn't work but resulted in the local loopback to be shared.


----------



## wonslung (Nov 25, 2013)

I don't think it's a non-issue.  Jails were apparently designed to do this.  It seems they are designed to allow you to share a single IP between multiple jails, but not multiple IP's (  you can't use two IP's on a jail that is using the same IP as another jail).   I don't see why they would make a distinction like that.  Why would they allow you to share multiple IP's (so long as those IP's are unique) but not allow you to share multiple IP's if one of those IP's isn't unique.  I wonder if loopback is somehow tied to the jail IP.

Anyways, I was just curious.  It's easy to work around this problem by not using the loopback device.


----------

