Can't ping in jail

[doug]

This is a 9.3-RELEASE-p49 system. In the jail:

gaia:~> sysctl security.jail.allow_raw_sockets
security.jail.allow_raw_sockets: 1

gaia:~> ifconfig
em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500

options=4219b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC,VLAN_HWTSO>
ether c8:9c:dc:eb:ab:fb
inet 192.168.2.110 netmask 0xffffffff broadcast 192.168.2.110
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>

and as root

gaia:/home/doug# ping -c 2 192.168.2.102
PING 192.168.2.102 (192.168.2.102): 56 data bytes
ping: sendto: Can't assign requested address
ping: sendto: Can't assign requested address
^C
--- 192.168.2.102 ping statistics ---
2 packets transmitted, 0 packets received, 100.0% packet loss

ctrl-c is required to end the command. This is without a loopback defined. If I
define the loopback I can ping 127.0.0.1 but nothing else. What am I missing?


_______________________________________________
freebsd-...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questi...@freebsd.org"

[doug]

On Sat, 3 Dec 2016, doug wrote:

> This is a 9.3-RELEASE-p49 system. In the jail:
>
> gaia:~> sysctl security.jail.allow_raw_sockets
> security.jail.allow_raw_sockets: 1
>
> gaia:~> ifconfig
> em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
>
> options=4219b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC,VLAN_HWTSO>
> ether c8:9c:dc:eb:ab:fb
> inet 192.168.2.110 netmask 0xffffffff broadcast 192.168.2.110
> media: Ethernet autoselect (100baseTX <full-duplex>)
> status: active
> lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
> options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
>
> and as root
>
> gaia:/home/doug# ping -c 2 192.168.2.102
> PING 192.168.2.102 (192.168.2.102): 56 data bytes
> ping: sendto: Can't assign requested address
> ping: sendto: Can't assign requested address
> ^C
> --- 192.168.2.102 ping statistics ---
> 2 packets transmitted, 0 packets received, 100.0% packet loss
>
> ctrl-c is required to end the command. This is without a loopback defined. If
> I define the loopback I can ping 127.0.0.1 but nothing else. What am I
> missing?

Okay after lots of reading: handbook, man pages, wiki's, and google (I did RTFM)
I an pretty sure I have a routing issue and that security.jail.allow_raw_sockets
works. That said, I give up. The host was getting its IP via DHCP so I changed
that, defined the host as a gateway, did what I know how to so with netmasks and
set all the sysctl's that seemed remotely related to this in the host. At the
end of the day virtually all combinations of the aforementioned allow the jail
to ping its own IP and localhost. Now moving on to stuff that pays the rent. Any
thoughts welcomed though.

[Ernie Luzar]

Hello Doug.

Your asking for help, but providing a very small amount of information
about how you created your jails and the network surrounding your host.

Are your jails defined using the legacy method with definition
statements in /etc/rc.conf or the modern way using /etc/jail.conf?

Is this a single host with isp assigned dynamic ip addresses?

Is there a LAN behind the host with real computers attached, or are you
using an second NIC just to address the jails?

Do you have a firewall doing NAT for the jail's [non public routeable ip
address]?

How did you create your jail directory tree?

Are you using nullfs?

Did you use any of the port utilities for creating your jail environment?


The above will give you plenty to think about.

******************************************************************

First off 9.3 reaches EOL [end of life] next month. There has been a
lot of changes to jail(8) between 9.3 and 11.0. You should have moved to
11.0 already. Your not going to get jail support for an EOL system.

I strongly suggest you install the package named jail-primer it will
go a long way filling in the background info you seem to be lacking
about jails in general.

Once your on 11.0 then install the package named qjail
It automates jail management in a very user friendly manner
automatically doing all the little details for you.

First you have to get the host communicating with the public network
before you start playing with jails.

As a general rule there is no need to be using any sysctl nibs.
At a bare minimum you need this in rc.conf

hostname="doughost.com"
gateway_enable="YES"
ifconfig_em0="DHCP"

After doing your homework and having played with qjail, if you need help
then post here again but give greater details about your environment.

Good Luck.

[DTD]

Thank you that was indeed a lot of stuff. I will ponder and check things out. I
am using ezjail which I like. I inferred from the handbook, man jail and some
reading on jails that if you could route TCP from the jail then all you had to
do to route ICMP was set security.jail.allow_raw_sockets. I did not say but
perhaps should have said the host and the jails are on a LAN (192.168.2.0/24)
behind a firewall that connects to a router and out to the internet. The host
and the jails can use any TCP based protocol to connect to any server either in
the LAN or on the internet. I infer from all this that routing ICMP from within
a jail requires some additional support. The host has one NIC shared by all the
jails. The jails can do anything except ping.

Thanks again for all the pointers

_____
Douglas Denault
http://www.safeport.com
do...@safeport.com
Voice: 301-217-9220
Fax: 301-217-9277

[Ernie Luzar]

This post sheds a lot light on your problem. ezjail uses the legacy
method with definition statements in /etc/rc.conf and qjail uses the
modern way using /etc/jail.conf. qjail is a fork of ezjail so many
things will feel the same moving to qjail. The ezjail and qjail
directory tree is named differently and use different internal control
files so you would have to build your qjail jails anew. qjail and ezjail
can both run on the same host at the same time just using different jail
ip addresses.

Both methods have statements for enabling allow_raw_sockets on a jail
by jail basis which is the way it should be done. The sysctl nib has to
be issued on the host were the jails are, not the gateway host connected
to the public network.

ezjail requires manual starting and stopping of ip alias for the jail.
qjail does all that for you without you having to take any actions.

there is a qjail version for 9.x systems, but its out dated and at EOL.

[Matthew Seaman]

On 04/12/2016 01:59, Ernie Luzar wrote:
> This post sheds a lot light on your problem. ezjail uses the legacy
> method with definition statements in /etc/rc.conf and qjail uses the
> modern way using /etc/jail.conf. qjail is a fork of ezjail so many
> things will feel the same moving to qjail. The ezjail and qjail
> directory tree is named differently and use different internal control
> files so you would have to build your qjail jails anew. qjail and ezjail
> can both run on the same host at the same time just using different jail
> ip addresses.
>
> Both methods have statements for enabling allow_raw_sockets on a jail
> by jail basis which is the way it should be done. The sysctl nib has to
> be issued on the host were the jails are, not the gateway host connected
> to the public network.
>
> ezjail requires manual starting and stopping of ip alias for the jail.
> qjail does all that for you without you having to take any actions.
>
> there is a qjail version for 9.x systems, but its out dated and at EOL.

The jail management system that has been attracting a lot of attention
and favourable comment recently is iocage. The original version was
written in /bin/sh and this is what is in ports as sysutils/iocage or
sysutils/iocage-devel. The authors are intending to rewrite it in a
different language though.

It does, however, require you to use ZFS, since it stores all the
configuration into it needs as ZFS properties.

https://iocage.readthedocs.io/en/latest/

Cheers,

Matthew

[doug]

On Sun, 4 Dec 2016, Matthew Seaman wrote:

> On 04/12/2016 01:59, Ernie Luzar wrote:
>> This post sheds a lot light on your problem. ezjail uses the legacy
>> method with definition statements in /etc/rc.conf and qjail uses the
>> modern way using /etc/jail.conf. qjail is a fork of ezjail so many
>> things will feel the same moving to qjail. The ezjail and qjail
>> directory tree is named differently and use different internal control
>> files so you would have to build your qjail jails anew. qjail and ezjail
>> can both run on the same host at the same time just using different jail
>> ip addresses.
>>
>> Both methods have statements for enabling allow_raw_sockets on a jail
>> by jail basis which is the way it should be done. The sysctl nib has to
>> be issued on the host were the jails are, not the gateway host connected
>> to the public network.
>>
>> ezjail requires manual starting and stopping of ip alias for the jail.
>> qjail does all that for you without you having to take any actions.
>>
>> there is a qjail version for 9.x systems, but its out dated and at EOL.
>
> The jail management system that has been attracting a lot of attention
> and favourable comment recently is iocage. The original version was
> written in /bin/sh and this is what is in ports as sysutils/iocage or
> sysutils/iocage-devel. The authors are intending to rewrite it in a
> different language though.

From this I hear that the file system and more specifically various jail
management interfaces, which I understand as basically an abstraction layer to
interface with the basic jail structure has an impact on the way raw sockets are
handled in the network stack. It was/is my general understanding that best
practices O/S design would and do generally following the layers underlying the
original apranet design. So that's not the case with the jail implementation??