Steve Bertrand wrote:
Erik Norgaard wrote:
Erik Norgaard wrote:

I have no problem connecting from the host to the jail, but the other
way around doesn't work.

Also, related, how do I configure multiple interfaces in a jail?
Second problem solved, starting jail with

  # jail /var/jail jail 127.0.0.2,172.16.0.2 /bin/sh /etc/rc

So, now I have:

vr1: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0
mtu 1500
    options=2808<VLAN_MTU,WOL_UCAST,WOL_MAGIC>
    ether 00:40:63:ee:97:f1
    inet 172.16.0.2 netmask 0xffffffff broadcast 172.16.0.2
    media: Ethernet autoselect (100baseTX <full-duplex>)
    status: active
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
    inet 127.0.0.2 netmask 0xffffffff

Now, I can connect out on vr1 to 172.16.0.1, but not on lo0 to
127.0.0.1. Any suggestions what might be wrong?

I don't think that it is a wise idea to be using the loopback address
space to route packets outside of the OS, and it is even possible that
some implementations forbid this behaviour (don't quote me on that).

I have read some recommendations not to use the loopback interface without any real explanation, I don't see why it shouldn't work with a different IP as for other interfaces - or a cloned loopback.

If you want a loopback to be a receive interface, you should clone off a
second one (lo1), and assign an IP address to it that was not designed
to be short circuited within the host, like this:

% grep lo10 /etc/rc.conf

cloned_interfaces="lo1 lo3 lo10 ...etc

# lo10 (IPv4 iBGP loopback, advertised by OSPF)
ifconfig_lo10="UP"
ifconfig_lo10="inet 172.16.104.8 netmask 255.255.255.255"

From RFC 1700:

      (g)   {127, <any>}

         Internal host loopback address.  Should never appear outside
         a host.

It won't. It's intended to be stricly local on the internal loopback interface.

The idea is to use the loopback interface for connecting between the jail and the host while not exposing the jail to the exterior.

Basically, I'm trying to setup a jail for my imap server to migrate my mail from the existing server, a last resort clumsy way of upgrading the Berkeley DB. Then a script connecting to both services can create accounts, folders and copy the mail to the new service.

The idea is that this way I could do it transparently - well, that's the theory.

BR, Erik.

--
Erik Nørgaard
Ph: +34.666334818/+34.915211157                  http://www.locolomo.org
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"

Reply via email to