Pi-hole in doker network problem

    • Offizieller Beitrag

    @Nefertiti


    I have an idea, but I'm not sure of the Linux command to do this, what you need to do is to release the ip address in omv (on windows machine it's ipconfig /release from the command line)
    Then reset your static ip option on your router, shutdown and reboot the should assign that new static ip via the router, the following is from the manual.



    According to that it will assign the ip to the Pi, but the current one needs to be released, what I found is dhcpclient -v -r from the command line, but to that you'll have to have a keyboard and monitor so you can shutdown shutdown -r now this will shutdown and reboot the Pi smoothly, rather than pulling the plug.

    • Offizieller Beitrag

    No control in the Ethernet layer over the address where each end user could assign any IP address as static would be unacceptable

    That would not happen, this would be disabled using group policy and so would a number of other options, but I understand what you're saying....and we have a saying for that "Horses for Courses" :)

    I think omv-firstaid fixit and probably the name eth0 was wrong should have been eth1 to make sure I should not assigned it as dynamic at the router level?

    Well at least you've found the problem, but you need to change the ip to something outside the dhcp scope, the ip assigned to the Pi will release once the lease time runs out.

  • That would not happen, this would be disabled using group policy and so would a number of other options, but I understand what you're saying....and we have a saying for that "Horses for Courses" :)

    Well at least you've found the problem, but you need to change the ip to something outside the dhcp scope, the ip assigned to the Pi will release once the lease time runs out.

    Well it was my question since the ip is now static in the omv network interface and assigned by me outside the dhcp scope in the omv first aid should I also assign it dynamic in the router? getting a little bit confused!

    • Offizieller Beitrag

    Hmmm Imho, no ... Or I misunderstand you. ;)
    Whether the address is static or dynamic does not depend on whether it is out of the dhcp pool.


    On the dhcp side, I can give any IP from the pool for a specific MAC address and this IP will be static even though it will be in the dhcp pool.

    In the strictest sense, you're right. One can reserve a DCHP address, permanently, and assign that address to a specific MAC address. Going further, my router allows assigning a hostname to the reserved IP/Mac address combination. (Which allows for a simple version of local DNS.) That same address does not have to be supplied by the DHCP server, to the client, either. Since it's reserved, the same IP address can be statically set on the host.


    On the other hand, hashing off-topic details doesn't always help in solving the problem as outlined in the thread.

    • Offizieller Beitrag

    Well it was my question since the ip is now static in the omv network interface and assigned by me outside the dhcp scope in the omv first aid should I also assign it dynamic in the router? getting a little bit confused!

    What's the address you have assigned to OMV, in network settings?

  • That would not happen, this would be disabled using group policy and so would a number of other options, but I understand what you're saying....and we have a saying for that "Horses for Courses" :)

    Well at least you've found the problem, but you need to change the ip to something outside the dhcp scope, the ip assigned to the Pi will release once the lease time runs out.

    Well it was my question since the ip is now static in the omv network interface and assigned by me outside the dhcp scope in the omv first aid should I also assign it dynamic in the router? getting a little bit confused!

    • Offizieller Beitrag

    The address is fine so long as it's in your network and NOT the server's IP address. That appears to be the case. Your server is 192.168.2.150. Pi-hole is 192.168.2.155 so all should work.


    However, from a previous post, I noticed that your router's DHCP range runs from .2 to .200. You now have two IP addresses, in use, within that range. If possible, I would go into your router and reserve those addresses so your routers DHCP server won't assign them to another host.
    (Otherwise, it's not the best way to set it up; with your server (.150) and Pi-hole (.155) running 24x7, it's unlikely that your router would assign an address that's in active use.)
    ________________________________________________


    You can test Pi-hole a couple ways. You can set one of your network clients with a static DNS address of 192.168.155 and go surfing. If the client connects to web sites, it works.
    Check Pi-holes console http://192.168.1.155/admin/ You should see activity in the Dashboard. (If total queries is more than 0, it's working.)
    Finally, change your router's DNS server, to Pi-hole's address. This include change the DNS address for all statically addressed clients.

  • I changed the dhcp pool from 192.168.2.2 to192.168.2.100 ,But I checked from a browser without add blocking and it is not working wondering If I can setup dns in the router as https://discourse.pi-hole.net/…e-as-their-dns-server/245 with the ip 192.168.2.155 in dns server on the lan page of the router


    Also http://192.168.2.155/admin is not resolving and when I go to docker container modify just to check under Macvlan settings the IP address is empty other issue but maybe this is ok the bridge container pihole name naughty_joliot says dead
    Please how can I fix it ?

    • Offizieller Beitrag

    But I checked from a browser without add blocking and it is not working

    Yes, add Pi-Holes DNS ip address to your router and apply your changes, but for clients to get the new settings, for windows using Command Prompt you can do ipconfig /release followed by ipconfig /renew to check it's picking up it it up ipconfig /all, iPads etc you an do from Settings, again release and renew.


    Your MacVlan is set incorrectly, when you set this up under Create Network, the Subnet should be 192.168.2.0/24, Gateway 192.168.2.2, and the parent eth1.


    Then in the container, under Macvlan Settings>>>Select macvlan network would display workgroup (192.168.2.0/24) then in the Ip Address add 192.168.2.150

    • Offizieller Beitrag

    I have my preferences, you have yours. Only I do not like the firm and final message to the user when there are alternatives ...

    I agree, you have yours and I have mine but I prefer to work on the KIS principle for a home user, imho anything else confuses them in achieving the end result.

    • Offizieller Beitrag

    I changed the dhcp pool from 192.168.2.2 to192.168.2.100, But I checked from a browser without add blocking and it is not working wondering If I can setup dns in the router as https://discourse.pi-hole.net/…e-as-their-dns-server/245 with the ip 192.168.2.155 in dns server on the lan page of the router
    Also http://192.168.2.155/admin is not resolving and when I go to docker container modify just to check under Macvlan settings the IP address is empty other issue but maybe this is ok the bridge container pihole name naughty_joliot says dead
    Please how can I fix it ?

    Reducing your scope (from 2 - 200 to 2 - 100) was a good idea. That free's up the addresses you're using for the server (150) and pi-hole (155). However, @geaves is right about the details of your configuration.


    A network statement such as 192.168.2.150/24 is "technically" the same as 192.168.2.0/24 but I have no idea how the MacVlan driver or the Docker Plugin would interpret the first address. It's best to use 192.168.2.0/24.


    Another note, regarding the missing IP address for your server in the MacVlan section:
    From experience, I've found that trying to alter a MacVlan network configuration, after it has been saved the first time, didn't always "take" or "save". It's best to delete the MacVlan network and configure it again, with the correct entries.


    Since the Pi-Hole docker container's networking is based on the MacVlan driver, if MacVlan settings are changed, it would probably be best to configure a new container from scratch. So, the best bet would be to delete the MacVlan and the container, and start over using 192.168.2.0/24
    ___________________________________________________________________


    When the above is done, in the Docker plugin, your container's STATUS should be running. If it's running, the first test is going to 192.168.2.155/admin in a browser. If you can't get into the console, there's no point in going further.


    If you can get into the console, that's when you'd change your router according to your link above.


    If you have clients accessing your network using DHCP, it's easier to simply reboot them or, if they're devices (TV's), power them off and on so they'll pick up a new address in your reduced DHCP range, and the Pi-holes DNS address from your router.

  • Yes, add Pi-Holes DNS ip address to your router and apply your changes, but for clients to get the new settings, for windows using Command Prompt you can do ipconfig /release followed by ipconfig /renew to check it's picking up it it up ipconfig /all, iPads etc you an do from Settings, again release and renew.
    Your MacVlan is set incorrectly, when you set this up under Create Network, the Subnet should be 192.168.2.0/24, Gateway 192.168.2.2, and the parent eth1.


    Then in the container, under Macvlan Settings>>>Select macvlan network would display workgroup (192.168.2.0/24) then in the Ip Address add 192.168.2.150

    I think I got it it working in macvlan I used 192.168.2.0/24, Gateway 192.168.2.1 since it is my router , and the parent eth1. strangely pi_hole insit on eth0 in the login page
    I got confused about IP address of192.168.2.150 since it is OMV IP but I think I tried 192.168.2.155 and it was not working ( I was confused there)


    At the beginning I got DNS service not running but now everything is green and working thank you so much for all your help and great guide.

  • your using the MAC address to fix the ip to a specific machine, this is not normal practise


    Of course it IS normal practice to use DHCP in the way it has been designed. You want to manage static IP addresses centrally and not by fiddling around with text files or config database entries on individual machines.


    @Nefertiti: can you provide output from 'armbianmonitor -u' when you're logged into OMV on your RPi via SSH? In case you use an OMV image older than 1 year this will produce only 'command now found' but if you started with OMV 3 after July 2017 we might get some insights.

    • Offizieller Beitrag

    Of course it IS normal practice to use DHCP in the way it has been designed. You want to manage static IP addresses centrally and not by fiddling around with text files or config database entries on individual machines.

    What does this have to do with this thread....nothing....have you contributed anything to this thread to resolve the problem....no


    But you take one single comment out of context by cutting the end of the comment off and then proceed to apply your bit which serves no purpose!!
    What part of community forum do you not understand, you seem to take some sort of satisfaction in a "I know better than you do" attitude. Does this help anyone....no, but it obviously boosts your ego.
    As a moderator and as a forum member if you are unable to contribute to a thread to assist another member in resolving their problem, then "have sex and travel" because "willy waving" your knowledge is a distraction and totally unnecessary.

  • What does this have to do with this thread....nothing


    The purpose was informing you that things do work differently than you think (since you're a forum user spending a lot of time sharing your knowledge with others). If @Nefertiti would have been told to simply assign a static IP address in his router for his Pi a lot of confusion and lost time could have been avoided.


    Next wrong assumption is 'eth0' being always the name of the active network interface of an OMV box. This is also something from the past (today we use so called 'predictable network interface names' and eth0 is already deprecated -- OMV users and especially people trying to help other forum users should stop thinking ethN would be the natural way of naming interfaces since with Debian 10 they're completely gone -- details) but there exists no reason at all to think eth0 would be the correct interface name (that's the stuff @Nefertiti lost most of his time with since on his installation eth1 seems to be the device in question and me asking him for armbianmonitor -u output is the try to get an idea why to probably improve OMV code to better deal with such situations).

    • Offizieller Beitrag

    The purpose was informing you that things do work differently than you think (since you're a forum user spending a lot of time sharing your knowledge with others).

    Touche.....No I don't think I know!! Not only that most SOHO users do not have that functionality within their network, no dc, no pfsense and routers that do not allow mac filtering....So I work on the KIS principle. But thank you for the condescending comment :)


    If @Nefertiti would have been told to simply assign a static IP address in his router for his Pi a lot of confusion and lost time could have been avoided.

    Post 8, tried that for whatever reason that didn't work or it didn't apply itself. Plus his router clearly states that fixed ip addresses are required to be outside of the dhcp scope.


    lost most of his time with since on his installation eth1 seems to be the device in question and me asking him for armbianmonitor -u output is the try to get an idea why to probably improve OMV code to better deal with such situations).

    Again Post 8 clearly shows his interface as eth0 when he tries to change to a static ip. But running omv-firstaid to reset the network interface has renamed it, why?
    I changed my machine and searching the forum all I needed to do was to run omv-firstaid and run the network configuration, which I did, mine changed from eth0 to enp2s0 which I can locate in /etc/network/interfaces.


    OMV users and especially people trying to help other forum users should stop thinking ethN would be the natural way of naming interfaces since with Debian 10 they're completely gone

    I thought the current omv was based on Debian 9? or is the above for future reference?


    Perhaps end users like myself should stop 'trying' to help others as we deliver assistance simply and clearly without the technical babble which they would not understand nor care about.


    Perhaps it might help if @flmaxey changed the howto on Pi-Hole to check the network interface name at the time of changing omv's dns setting and for the user to make a note of that as it will be required later in the guide.

  • So I work on the KIS principle


    IMO no. @Nefertiti had the most simply setup one could imagine: he used a statically assigned IP address set by his router (basic DHCP functionality) and problems started once he tried to switch to a manual setup (with wrong MTU setting, maybe that was the culprit in the beginning -- don't know).


    I know you call this willy wanking (or insert any other insults here) but currently I try to get an idea what went wrong to improve OMV on ARM devices (yeah, I'm not after spending hours in the forums trying to help politely other users but I want to fix issues where they should be fixed in the first place so those questions/issues can be avoided altogether).


    Background information:

    • On the Armbian based OMV images networking setup is done entirely different to x86 installations where OMV's own routine adds the appropriate interface to OMV's config so that a network entry is already defined. On ARM this does not happen currently which allows users to use wrong settings (see MTU size): Last year I added automatic creation of the network node but this resulted in problems in networks with IPv6 enabled so I removed this in the images (spent 2 days on the problem -- situation with ARM due to most SoC families having own kernels is way more complex compared to x86)
    • When I try to setup manually a network node on one of my ARM boards the OMV UI only allows me to use eth0 but in my situation that's the wrong interface (see [1]). Based on this I don't trust that much into eth0 being displayed in Nefertiti's screenshots. Hint: trying to debug this issue omv-firstaid fails with an error message (that looks like an unrelated bug with displaying the UI). That's why I asked for armbianmonitor -u output already multiple times
    • Two weeks ago we changed the way name resolution is set up in Armbian. I'm currently trying to get an idea how/whether this conflicts with the way OMV tries to configure those settings and I also try to figure out whether it's worth the efforts changing 'first boot' behavior of the OMV ARM images to create a an interface config automatically (that's the challenge compared to x86 where the user is forced to run a manual setup when installing)


    Perhaps it might help if @flmaxey changed the howto on Pi-Hole to check the network interface name at the time of changing omv's dns setting

    Well, I've to admit that I don't understand this step at all. Why do I need to adjust DNS settings? And if I fear tracking on the Internet why exactly would I use Google's DNS servers then (or any other centralized -- if you fear someone tracking your Internet behavior then the best DNS server possible is your ISP's one).


    I set up Pi-Hole in a Docker container on my EspressoBin now skipping the 'create a static IP address and assign 8.8.8.8 as DNS' step entirely just creating a macvlan interface in Docker with the appropriate parent device (br0 in my case) and it simply works.



    [1] br0 is the needed interface, eth0 is not the right one (but is presented to me as only available interface in the OMV UI), so obviously the OMV routine to display the active network needs adjustments

    • Offizieller Beitrag

    /---/ now everything is green and working t /---/

    :thumbup: Have a good one.


    Well done glad you got it sorted and it's working, my Pi-Hole shows eth0 as well even though it isn't :)

    And you too. :) (Let's ignore the insurgent or this thread will get butchered up, as it spins down yet another rabbit hole.)

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!