Automatically regenerating /etc/resolv.conf after receiving a DHCP lease on a cloned interface

J

jmpalacios

Hi everyone,

I'm attempting to setup a couple of jails with VLANs not just to continue educating myself on FreeBSD networking, but also to configure some testing infrastructure that'll hopefully help me to debug a problem I'm having with my pfSense CE router and my real VLANs after upgrading the former to 2.8.1.

The host of the jails is a TrueNAS CORE 13.5 server, in which I have a 13.5 VNET jail attached to a bridge which, in turn, connects the former via a vtnet NIC to a bhyve VM where I'm running the testing pfSense CE 2.8.1 instance.

I configure the jail with a 10.80.1.2 static IP on its epair0B interface and intentionally with no initial resolver information, and via the bridge I can ping the 10.80.1.1 vtnet-based interface on the testing pfSense router. Further, this testing pfSense router instance has a VLAN interface on top of its vtnet NIC, with VLAN tag 10 and static IP 10.80.10.1, on which it's running a DHCP server, and I'm attempting to acquire a DHCP lease off it from inside the testing jail. For this purpose, I configure a VLAN directly inside the jail as so:

Code: 
cloned_interfaces="vlan8010"
ifconfig_vlan8010="vlan 10 vlandev epair0b SYNCDHCP"

and the DHCP lease comes right in without any issues at jail startup time, with the vlan8010 interface being configured correctly with IP address and netmask, and a route for the 10.80.10.0/24 network even being added to the jail's routing table.

What I believe is the sole problem I'm still facing with this configuration for now is that the jail's /etc/resolv.conf file remains empty after receiving the DHCP lease and, as an obvious result, DNS resolution fails. I have confirmed several times by attaching tcpdump(1) to the bridge on the TrueNAS CORE host that DNS information is indeed being included in the DHCP reply from the target DHCP server, and probably all I'm lacking is some rc and/or dhclient and/or resolvconf configuration to instruct the jail to regenerate its /etc/resolv.conf file upon receiving the new DHCP lease. However, for the life of me, I cannot figure out what that could be.

Needless to say, I can easily rewrite the /etc/resolv.conf file manually with the appropriate information to continue with my testing, but I'd love to learn what's keeping the jail from doing so automatically upon receiving the DHCP lease, if that's at all even possible.

Tips, comments, and even critiques on my setup most welcome, thanks!
 
Small addendum to this: using the -e flag in the tcpdump(1) invocation attached to the host bridge reveals that the ethernet traffic resulting from the DHCP lease request from the jail is properly tagged with the expected VLAN tag 10, which explains why the target DHCP server, running on the vtnet1.10 interface on the testing pfSense instance, is successfully receiving, and responding to, said DHCP request.
 
Another addendum to this question: another, much simpler way, in my opinion, that I found to configure the VLAN from inside my test jail, from reading rc.conf(5), is with the following rc configuration:

sh: 
vlans_epair0b="10"
ifconfig_epair0b_10="SYNCDHCP"

which I know under-the-hood is almost 100% equivalent to my previous:

sh: 
cloned_interfaces="vlan8010"
ifconfig_vlan8010="vlan 10 vlandev epair0b SYNCDHCP"

with the only difference being that my VLAN interface is now named epair0b.10, per convention, rather than my custom vlan8010, but that's perfectly fine (I know I could recover the original interface name, but couldn't care less about that).

However, the original problem of an empty /etc/resolv.conf file after receiving the DHCP lease still remains.
 
jmpalacios said:
and probably all I'm lacking is some rc and/or dhclient and/or resolvconf configuration to instruct the jail to regenerate its /etc/resolv.conf file upon receiving the new DHCP lease.
Click to expand...
All it 'needs' is ifconfig_<int>="DHCP", everything is already set up correctly. On FreeBSD. No idea about TrueNAS and/or pfSense.

DutchDaemon

Thread 'GhostBSD, pfSense, TrueNAS, and all other FreeBSD Derivatives'

Questions about 'derivative FreeBSDs', like
  • GhostBSD
  • TrueNAS
  • XigmaNAS
  • OPNsense
  • pfSense
  • BSD Router Project
  • NomadBSD
  • helloSystem
  • HardenedBSD
should be asked on the forums and/or mailing lists for these specific products. See below for links.

If you still think your questions should be asked here, beware of the following:

  • To show that you have indeed tried to get a solution from the forum or mailing list of the...
  • Thanks
  • Like
 
SirDice said:
All it 'needs' is ifconfig_<int>="DHCP", everything is already set up correctly. On FreeBSD. No idea about TrueNAS and/or pfSense.

DutchDaemon

Thread 'GhostBSD, pfSense, TrueNAS, and all other FreeBSD Derivatives'

Questions about 'derivative FreeBSDs', like
  • GhostBSD
  • TrueNAS
  • XigmaNAS
  • OPNsense
  • pfSense
  • BSD Router Project
  • NomadBSD
  • helloSystem
  • HardenedBSD
should be asked on the forums and/or mailing lists for these specific products. See below for links.

If you still think your questions should be asked here, beware of the following:

  • To show that you have indeed tried to get a solution from the forum or mailing list of the...
  • Thanks
  • Like
Click to expand...
I'm using SYNCDHCP:

Code: 
vlans_epair0b="10"
ifconfig_epair0b_10="SYNCDHCP"

but I understand the only difference between that and DHCP is that the former blocks the booting process until either a DHCP lease is received or the request fails for any reason (e.g. timeout), while the latter simply starts dhclient(8) and lets it do its thing in the background.

Is there another difference between those two modes that I should be aware of?

I'd imagine the key thing here to note is that the interface that's receiving the DHCP lease is a "secondary" one, i.e. an epair0b.10 VLAN that sits on top of an epair0b interface that's already configured with a static IP, and I don't if that breaks any best practices, expectations, and/or conventions on the part of FreeBSD, with that being the potential cause for my /etc/resolv.conf file remaining empty after the VLAN interface receives its DHCP lease.

Lastly, I should note that this jail, even though hosted on TrueNAS CORE, and managed via a rather old iocage distribution, is just a vanilla FreeBSD 13.5 runtime. In other non-testing jails that I configure with VNET and a single interface on DHCP, but otherwise under the exact same conditions, the /etc/resolv.conf file is generated without any issues with the DNS information received in their DHCP leases. Hence my comment about this testing scenario of a base epair0b interface with a static IP and a DHCP VLAN on top of it possibly posing some (expected?) problem to the rc scripts.
 
Now here's an interesting find!

As far as I understand, the main, if not the only, difference between the SYNCDHCP and DHCP startup modes is that the former starts dhclient(8) automatically for the configured interface at boot, but the latter does not, it just enables DHCP for the interface in question and you then start dhclient(8) manually via something like:

sh: 
service dhclient start epair0b.10

So I'm playing with this manual mode of operation for various testing purposes and this is what I find:

sh: 
-> ifconfig epair0b | grep inet
    inet 10.80.1.2 netmask 0xffffff00 broadcast 10.80.1.255

-> cat /etc/resolv.conf
(empty)

-> service dhclient start epair0b.10
Starting dhclient.
DHCPREQUEST on epair0b.10 to 255.255.255.255 port 67
DHCPACK from 10.80.10.1

-> ifconfig epair0b.10 | grep inet
    inet 10.80.10.2 netmask 0xffffff00 broadcast 10.80.10.255

-> cat /etc/resolv.conf
(empty)

-> ifconfig epair0b 10.80.1.2/24 delete

-> service dhclient restart epair0b.10
Stopping dhclient.
Waiting for PIDS: 3332.
Starting dhclient.
DHCPREQUEST on epair0b.10 to 255.255.255.255 port 67
DHCPACK from 10.80.10.1

-> cat /etc/resolv.conf
# Generated by resolvconf
search lan
nameserver 10.80.10.1

And a few variations on that pattern of testing all reveal the same result, i.e. receive a DHCP lease with an IP already existing on another interface, and /etc/resolv.conf is not rewritten; on the other hand, receive a DHCP lease without an IP already on another interface, and /etc/resolv.conf is rewritten as expected!

Now, I'm not quite sure if that's expected behavior (e.g. "simple precaution because you obviously already have networking information already configured"), undefined behavior out of an unexpected situation (e.g. because I'm doing something non-standard in the way I'm configuring my epair0b and epair0b.10 interfaces), or a plain and simple a bug somewhere in rc scripts; and, if the latter, if it might have already been fixed in newer releases, because this jail is an already pretty old 13.5 userland.

But, in any case, at least now I understand what's going on, which was my main goal all along. Now what I gotta figure out is how to bring up this jail with its epair0b interface but without any IP address to begin with, because the moment I remove the IP address then the whole interface disappears from the jail, and I don't know if that's expected behavior from FreeBSD or just an iocage oddity or bug.
 
You must log in or register to reply here.
Back
Top