Menu
▾
▴
astlinux-devel — The AstLinux development environment, compilation, etc
You can subscribe to this list here.
| 2008 |
Jan
|
Feb
|
Mar
(41) |
Apr
(35) |
May
(18) |
Jun
(5) |
Jul
(4) |
Aug
(37) |
Sep
(9) |
Oct
(20) |
Nov
(50) |
Dec
(217) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2009 |
Jan
(212) |
Feb
(76) |
Mar
(113) |
Apr
(88) |
May
(130) |
Jun
(54) |
Jul
(208) |
Aug
(223) |
Sep
(112) |
Oct
(63) |
Nov
(131) |
Dec
(103) |
| 2010 |
Jan
(247) |
Feb
(130) |
Mar
(43) |
Apr
(92) |
May
(40) |
Jun
(43) |
Jul
(43) |
Aug
(80) |
Sep
(44) |
Oct
(74) |
Nov
(21) |
Dec
(46) |
| 2011 |
Jan
(36) |
Feb
(11) |
Mar
(21) |
Apr
(33) |
May
(4) |
Jun
(12) |
Jul
(5) |
Aug
(20) |
Sep
|
Oct
(64) |
Nov
(26) |
Dec
(71) |
| 2012 |
Jan
(13) |
Feb
(24) |
Mar
(11) |
Apr
(2) |
May
(10) |
Jun
(5) |
Jul
(13) |
Aug
(7) |
Sep
(26) |
Oct
(22) |
Nov
(17) |
Dec
(16) |
| 2013 |
Jan
(6) |
Feb
(6) |
Mar
(6) |
Apr
(8) |
May
(20) |
Jun
|
Jul
(1) |
Aug
(4) |
Sep
(18) |
Oct
(3) |
Nov
(14) |
Dec
(33) |
| 2014 |
Jan
(26) |
Feb
(6) |
Mar
(69) |
Apr
(10) |
May
|
Jun
(8) |
Jul
(18) |
Aug
(22) |
Sep
(19) |
Oct
(17) |
Nov
|
Dec
(4) |
| 2015 |
Jan
(14) |
Feb
(18) |
Mar
|
Apr
|
May
(26) |
Jun
(8) |
Jul
(9) |
Aug
(10) |
Sep
(15) |
Oct
(2) |
Nov
(30) |
Dec
(33) |
| 2016 |
Jan
(1) |
Feb
(24) |
Mar
(19) |
Apr
(1) |
May
|
Jun
(3) |
Jul
(1) |
Aug
(1) |
Sep
(20) |
Oct
(5) |
Nov
(14) |
Dec
(4) |
| 2017 |
Jan
(15) |
Feb
(35) |
Mar
(10) |
Apr
(9) |
May
(14) |
Jun
(33) |
Jul
(1) |
Aug
(27) |
Sep
(7) |
Oct
|
Nov
(10) |
Dec
(15) |
| 2018 |
Jan
(29) |
Feb
|
Mar
(2) |
Apr
(1) |
May
(11) |
Jun
|
Jul
(1) |
Aug
(8) |
Sep
(11) |
Oct
(22) |
Nov
(9) |
Dec
(13) |
| 2019 |
Jan
(1) |
Feb
(7) |
Mar
(3) |
Apr
(21) |
May
(34) |
Jun
(36) |
Jul
(18) |
Aug
(17) |
Sep
(19) |
Oct
(8) |
Nov
(3) |
Dec
|
| 2020 |
Jan
|
Feb
(4) |
Mar
(8) |
Apr
(29) |
May
(50) |
Jun
(8) |
Jul
(2) |
Aug
(10) |
Sep
(1) |
Oct
(7) |
Nov
(9) |
Dec
(19) |
| 2021 |
Jan
(2) |
Feb
(9) |
Mar
(6) |
Apr
(21) |
May
(13) |
Jun
(11) |
Jul
(2) |
Aug
(1) |
Sep
(3) |
Oct
(26) |
Nov
(2) |
Dec
(16) |
| 2022 |
Jan
(8) |
Feb
(7) |
Mar
(1) |
Apr
(13) |
May
(1) |
Jun
(4) |
Jul
(4) |
Aug
(1) |
Sep
(1) |
Oct
|
Nov
|
Dec
(1) |
| 2023 |
Jan
(2) |
Feb
(3) |
Mar
(16) |
Apr
|
May
(2) |
Jun
(1) |
Jul
(4) |
Aug
(13) |
Sep
(8) |
Oct
(6) |
Nov
(4) |
Dec
|
| 2024 |
Jan
(3) |
Feb
(3) |
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
(5) |
Aug
|
Sep
(1) |
Oct
|
Nov
(5) |
Dec
|
| 2025 |
Jan
(4) |
Feb
(2) |
Mar
|
Apr
(11) |
May
(1) |
Jun
(9) |
Jul
(18) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Michael K. <mic...@ip...> - 2018-12-12 22:13:50
|
Hi Devs Is there any option for dual PPPoE connections for Astlinux? Im setting up more and more WAN failover and it would be very handy to not have to install another router. Regards Michael Knill |
|
From: Lonnie A. <li...@lo...> - 2018-12-07 15:14:28
|
Announcing Pre-Release Version: astlinux-1.3-4012-9a9605 Significant development on WireGuard VPN support, related to available iOS and Android WireGuard Apps -- iOS WireGuard beta (iOS 12+) https://testflight.apple.com/join/63I19SDT Android WireGuard https://play.google.com/store/apps/details?id=com.wireguard.android -- Re-read first half of WireGuard VPN Configuration -- https://doc.astlinux-project.org/userdoc:tt_wireguard_vpn The AstLinux Team is regularly upgrading packages containing security and bug fixes as well as adding new features of our own. -- Linux Kernel 3.16.61, security and bug fixes. -- WireGuard VPN, version bump to 0.0.20181119 -- WireGuard VPN, add wireguard-mobile-client script to manage mobile clients. Also used by the web interface. -- Web Interface, WireGuard VPN sub-tab, add "Mobile Client Defaults" and "Mobile Client Credentials" sections. -- Web Interface, Status tab, improve layout of "WireGuard VPN Status" section. -- arnofw (AIF), add WIREGUARD_ALLOW_OPENVPN rc.conf variable, Allow WireGuard tunnel to OpenVPN tunnel(s), disabled by default. -- alert, on boot create a /etc/motd MOTD (Message of the Day) file containing system information. The MOTD is displayed at post-login by ssh, console and web interface CLI tab login. New rc.conf variable ENABLE_MOTD, display MOTD at post-login, "yes" or "no", defaults to "yes" -- wol-host, new command to send Wake-on-LAN packet to specified host, by IP or DNS name. Example: wol-host --ping 192.168.101.13 More info: wol-host --help -- fossil, new feature to optionally send commit notifications via email while using 'fossil-commit'. New rc.conf variable FOSSIL_NOTIFY must be defined (via user.conf) as To: email address to enable. Additional new, optional rc.conf variables: FOSSIL_NOTIFY_FROM, FOSSIL_HOSTNAME -- Complete Pre-Release ChangeLog: https://s3.amazonaws.com/beta.astlinux-project/astlinux-changelog/ChangeLog.txt New Documentation Topics: (none) Updated Documentation Topics: WireGuard VPN Configuration -- https://doc.astlinux-project.org/userdoc:tt_wireguard_vpn The "AstLinux Pre-Release ChangeLog" and "Repository URL" entries can be found under the "Development" tab of the AstLinux Project web site ... AstLinux Project -> Development https://www.astlinux-project.org/dev.html AstLinux Team |
|
From: Lonnie A. <li...@lo...> - 2018-11-27 14:15:45
|
Announcing Pre-Release Version: astlinux-1.3-3996-1662d2 Significant development on WireGuard VPN support, related to available iOS and Android WireGuard Apps -- iOS WireGuard beta (iOS 12+) https://testflight.apple.com/join/63I19SDT Android WireGuard https://play.google.com/store/apps/details?id=com.wireguard.android -- Re-read first half of WireGuard VPN Configuration -- https://doc.astlinux-project.org/userdoc:tt_wireguard_vpn The AstLinux Team is regularly upgrading packages containing security and bug fixes as well as adding new features of our own. -- Linux Kernel 3.16.61, security and bug fixes. -- WireGuard VPN, version bump to 0.0.20181119 -- WireGuard VPN, add wireguard-mobile-client script to manage mobile clients. Also used by the web interface. -- Web Interface, WireGuard VPN sub-tab, add "Mobile Client Defaults" and "Mobile Client Credentials" sections. -- Web Interface, Status tab, improve layout of "WireGuard VPN Status" section. -- arnofw (AIF), add WIREGUARD_ALLOW_OPENVPN rc.conf variable, Allow WireGuard tunnel to OpenVPN tunnel(s), disabled by default. -- wol-host, new command to send Wake-on-LAN packet to specified host, by IP or DNS name. Example: wol-host --ping 192.168.101.13 More info: wol-host --help -- fossil, new feature to optionally send commit notifications via email while using 'fossil-commit'. New rc.conf variable FOSSIL_NOTIFY must be defined (via user.conf) as To: email address to enable. Additional new, optional rc.conf variables: FOSSIL_NOTIFY_FROM, FOSSIL_HOSTNAME -- Complete Pre-Release ChangeLog: https://s3.amazonaws.com/beta.astlinux-project/astlinux-changelog/ChangeLog.txt New Documentation Topics: (none) Updated Documentation Topics: WireGuard VPN Configuration -- https://doc.astlinux-project.org/userdoc:tt_wireguard_vpn The "AstLinux Pre-Release ChangeLog" and "Repository URL" entries can be found under the "Development" tab of the AstLinux Project web site ... AstLinux Project -> Development https://www.astlinux-project.org/dev.html AstLinux Team |
|
From: Lonnie A. <li...@lo...> - 2018-11-02 13:39:31
|
Hi David, I looked over the changes more than once and did not see any cases where a trailing space was needed or intended. Your IFS example is a valid possibility, but we don't have any of those. Anyone, feel free to look over the the Github Commit Compare below. Lonnie > On Nov 2, 2018, at 8:24 AM, David Kerr <Da...@Ke...> wrote: > > Nice piece of cleanup. My first thought was did you check for any cases where a trailing space is actually required. For example > IFS=' > ' > which makes space and newline the separator. I don't know if we have any of those, and if we do it is probably bad practice anyway. > > David > > > On Fri, Nov 2, 2018 at 9:15 AM Lonnie Abelbeck <li...@lo...> wrote: > Hi Devs, > > Yesterday I cleaned-up trailing spaces in our scripts, many years of copy/paste'ing and an old Busybox "vi" auto-indent "feature". > > scripts, remove trailing spaces, cosmetic, no functional change > https://github.com/astlinux-project/astlinux/compare/c7ab5b16f26e...f7d41203769f > > In general this should not effect anyone. > > But, if by chance you maintain a patch referencing the astlinux github repository, these space removals could break patches, PR's, etc. . If that happens, remove such trailing spaces in your custom script changes by using sed "in-place" ... > > $ sed -i 's/ *$//' custom_astlinux_script > > Alternatively, if you are using "vi", search using '/ *$' to find any trailing spaces. > > Lonnie |
|
From: David K. <da...@ke...> - 2018-11-02 13:24:37
|
Nice piece of cleanup. My first thought was did you check for any cases where a trailing space is actually required. For example IFS=' ' which makes space and newline the separator. I don't know if we have any of those, and if we do it is probably bad practice anyway. David On Fri, Nov 2, 2018 at 9:15 AM Lonnie Abelbeck <li...@lo...> wrote: > Hi Devs, > > Yesterday I cleaned-up trailing spaces in our scripts, many years of > copy/paste'ing and an old Busybox "vi" auto-indent "feature". > > scripts, remove trailing spaces, cosmetic, no functional change > > https://github.com/astlinux-project/astlinux/compare/c7ab5b16f26e...f7d41203769f > > In general this should not effect anyone. > > But, if by chance you maintain a patch referencing the astlinux github > repository, these space removals could break patches, PR's, etc. . If that > happens, remove such trailing spaces in your custom script changes by using > sed "in-place" ... > > $ sed -i 's/ *$//' custom_astlinux_script > > Alternatively, if you are using "vi", search using '/ *$' to find any > trailing spaces. > > Lonnie > > > > > > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > |
|
From: Lonnie A. <li...@lo...> - 2018-11-02 13:15:21
|
Hi Devs, Yesterday I cleaned-up trailing spaces in our scripts, many years of copy/paste'ing and an old Busybox "vi" auto-indent "feature". scripts, remove trailing spaces, cosmetic, no functional change https://github.com/astlinux-project/astlinux/compare/c7ab5b16f26e...f7d41203769f In general this should not effect anyone. But, if by chance you maintain a patch referencing the astlinux github repository, these space removals could break patches, PR's, etc. . If that happens, remove such trailing spaces in your custom script changes by using sed "in-place" ... $ sed -i 's/ *$//' custom_astlinux_script Alternatively, if you are using "vi", search using '/ *$' to find any trailing spaces. Lonnie |
|
From: David K. <da...@ke...> - 2018-11-02 00:32:44
|
Well, as I was initiator of this thread I am in favor. Lonnie's suggestion
of using the DMZ is actually quite elegant. A couple of thoughts though..
1) Is it okay to have one DNS set for all internal subnets (excluding
DMZ)? dnsmasq does allow setting of different DNS servers on a
per-interface basis. It is definitely simpler to just support the same for
all subnets but I have noticed that pi-hole can stop some things working
(like sponsored search results in google, and quite a few affiliate links
from blogs, etc.). So I might want the flexibility to leave my guest
network un-filtered while I send my main network to pi-hole.
2) And I put on my body armor here :-) the setting should allow for IPv6
as well as IPv4 address. Yes I know standard astlinux does not support
DHCPv6 on internal networks, but I have implemented it on my custom
version... just trying to keep the differences between the two as minimal
as possible. [sidebar, at some point AstLinux will need to up its game wrt
IPv6, but I know Lonnie is not at that point yet.]
David
On Thu, Nov 1, 2018 at 7:05 PM Michael Keuter <li...@mk...>
wrote:
>
> > Am 01.11.2018 um 22:46 schrieb Michael Knill <
> mic...@ip...>:
> >
> > I personally don't think I would use it. I use dnsmasq.static for
> everything that needs to be changed.
>
> +1
>
> > Are you thinking of adding it to the Network Tab?
> >
> > Regards
> > Michael Knill
> >
> > On 2/11/18, 6:51 am, "Lonnie Abelbeck" <li...@lo...>
> wrote:
> >
> > Any thoughts on adding a DHCP_OPTION_DNS_SERVER rc.conf variable ?
> (outlined below)
> >
> > Useful, or extraneous ?
> >
> >
> > Lonnie
> >
> >
> >
> >> On Oct 24, 2018, at 9:12 AM, Lonnie Abelbeck <li...@lo...>
> wrote:
> >>
> >>> Does DMZ require another physical ethernet port?
> >>
> >> No, the DMZ can be a VLAN.
> >>
> >> Lonnie
> >>
> >>
> >>
> >>> On Oct 24, 2018, at 8:55 AM, David Kerr <Da...@Ke...> wrote:
> >>>
> >>> Does DMZ require another physical ethernet port? I've used up all
> three on my APU2.
> >>>
> >>> David
> >>>
> >>> On Wed, Oct 24, 2018 at 9:14 AM Lonnie Abelbeck <
> li...@lo...> wrote:
> >>> How about this...
> >>>
> >>> Hardware Pi-hole with AstLinux
> >>> ------------------------------
> >>>
> >>> Place the Pi-hole box off the DMZ interface.
> >>>
> >>> Example: DMZ is 10.10.50.1/24 and Pi-hole static IP is 10.10.50.53/24
> with it's upstream DNS set to 10.10.50.1
> >>>
> >>> Network -> Firewall Configuration: {Firewall Configuration}
> >>> --
> >>> Action: [Pass DMZ->Local]
> >>> Source: 10.10.50.53
> >>> Port: 53
> >>> Protocol: TCP/UDP
> >>> Comment: Allow Pi-hole upstream DNS via Local
> >>> --
> >>>
> >>> Network -> Advanced Configuration: {Edit User Variables}
> >>> --
> >>> DHCP_OPTION_DNS_SERVER="10.10.50.53"
> >>> --
> >>>
> >>> The only code change required would be adding DHCP_OPTION_DNS_SERVER
> rc.conf support:
> >>> -- package/dnsmasq/dnsmasq.init --
> >>> trueDNSMASQnet()
> >>> ...
> >>> - dhcp-option=$1,option:dns-server,$gateway
> >>> + dhcp-option=$1,option:dns-server,${DHCP_OPTION_DNS_SERVER:-$gateway}
> >>> --
> >>> Same idea as David's, but simplified.
> >>>
> >>> FYI, in case you forgot, the default DMZ firewall rules are:
> >>> 1) Block all DMZ initiated connections to internal interfaces and
> Local AstLinux
> >>> 2) Allow all DMZ initiated connections via external interface.
> >>> 3) Allow all internal interfaces and Local AstLinux initiated
> connections to the DMZ
> >>>
> >>> With this scenario, AstLinux can be configured with "DNS-TLS Proxy
> Server" enabled to encrypt all Pi-hole upstream requests, as well as any
> local "DNS Hosts" can be honored via Pi-hole.
> >>>
> >>> Thoughts ?
> >>>
> >>> Lonnie
> >>>
> >>>
> >>>
> >>>
> >>>> On Oct 23, 2018, at 8:32 PM, David Kerr <Da...@Ke...> wrote:
> >>>>
> >>>> Hi Lonnie,
> >>>> Interesting thought about making pi-hole the upstream DNS for
> Astlinux (and therefore the whole network). You would certainly loose a
> lot of the metrics that pi-hole captures, though I am not sure how much I
> care about those. Mainly for geek interest I think. I do notice on
> pi-hole settings page support for DNSSEC with a note that it only works
> with google, norton, dns.watch and quad9 servers. I do not see a way to
> specify port number for pi-hole's upstream servers, but you could use
> iptables on Astlinux to REDIRECT traffic from pi-hole's static ip going to
> port 53 and send it instead to 2853, I think that might work.
> >>>>
> >>>> I do agree it is a pity that pi-hole isn't a whole lot simpler...
> would be great if it could just be added to AstLinux, but clearly that is
> not the approach they took and given cost of a Raspberry Pi it is maybe not
> that unreasonable for them to take the approach they did.
> >>>>
> >>>> Not at home this week so I cannot do any experimenting. I did leave
> pi-hole active at home, lets hope I don't return to annoyed family... I
> have already had to whitelist some domains just to get google sponsored
> search results to work.
> >>>>
> >>>> David
> >>>>
> >>>> On Sun, Oct 21, 2018 at 11:28 PM Lonnie Abelbeck <
> li...@lo...> wrote:
> >>>>> This is not a problem for standard AstLinux because that does not
> support DHCP for IPv6 so on a AstLinux LAN dual IPv4/IPv6 is required and
> DNS comes from IPv4.
> >>>>
> >>>> Indeed, and is why I like the idea of only supporting DHCPv4 on
> internal interfaces, it just works, and works consistently.
> >>>>
> >>>>
> >>>>> The changes to support that (IPv4 only for standard AstLinux) can be
> found here..
> >>>>>
> https://github.com/dkerr64/astlinux/commit/d20a4f40571258bbbf8725bfde6ec5a4254630ec
> >>>>
> >>>> David, nicely done (I have a few quibbles) but you put your finger on
> where it would go.
> >>>>
> >>>>
> >>>> Taking a step back, if a dedicated Raspberry Pi was performing DNS
> for the whole network, wouldn't it be better for AstLinux to just use it as
> it's static DNS source ? like ...
> >>>>
> >>>> Network -> DNS: ____
> >>>>
> >>>> In this case all the requests would be coming from AstLinux itself,
> would you be loosing any interesting statistics on the pi-hole web
> interface ?
> >>>>
> >>>> More importantly, the pi-hole should offer DNS-TLS upstream (via
> stubby like we do), I'm not sure if that has been implemented (lots of
> requests for it by DuckDuckGo'ing it).
> >>>>
> >>>> If you have a simple single LAN, then I can see tweaking the DHCP
> "option:dns-server" would be a reasonable choice, but when you have
> multiple LAN's/VLAN's and a single pi-hole it would require adding a bunch
> of firewall rules for DNS to be accessed across subnets. Not to mention
> requiring dnsmasq setup tweaks like what David proposed above.
> >>>>
> >>>> I would imagine that pi-hole should support DNS-TLS upstream at some
> point. I suppose we could optionally have our stubby daemon listen on
> 0.0.0.0@2853 instead of 127.0.0.1@2853 so a local pi-hole could direct
> DNS to it's internal gateway at port 2853 ... bypassing dnsmasq's DNS
> altogether. It would take some testing, assuming pi-hole can forward
> upstream to both address and port.
> >>>>
> >>>> Sadly the pi-hole project basically requires a full "Linux system"
> rather than just a single daemon, the later could be easily incorporated
> into AstLinux directly.
> >>>>
> >>>> Lonnie
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>> On Oct 21, 2018, at 7:57 PM, David Kerr <da...@ke...> wrote:
> >>>>>
> >>>>> Moving this to developer list...
> >>>>>
> >>>>> I decided to go the same route as Michael. I found a old Raspberry
> Pi lying around and set it up as a pi-hole server. Then I went the route
> of setting dnsmasq option to replace the DNS server pushed out to DHCP
> clients.
> >>>>>
> >>>>> As I did this I found a quirk of dnsmasq...
> >>>>> NOTE... following does NOT apply to standard AstLinux, only to my
> version, but it is worth documenting.
> >>>>> For IPv4 all is fine. The dhcp-option statement in dnsmasq.static
> seems to replace/overwrite that in dnsmasq.conf.
> >>>>> However for IPv6 it was not as clean cut as that. On iOS devices
> both the IPv6 address in dnsmasq.conf and that in dnsmasq.static was
> getting picked up by the IPv6 network stack on iOS devices. This did not
> appear to be happening on MacOS devices however, very odd.
> >>>>> This is not a problem for standard AstLinux because that does not
> support DHCP for IPv6 so on a AstLinux LAN dual IPv4/IPv6 is required and
> DNS comes from IPv4. I have implemented much richer IPv6 support for local
> networks but this has not been incorporated back into the standard AstLinux
> (yet?).
> >>>>>
> >>>>> I decided therefore that it would make sense to allow for manual
> configuration of DNS servers in Astlinux, so that it would be done by the
> system into dnsmasq.conf and not require setting in dnsmasq.static. I
> therefore implemented support for...
> >>>>> INTDNS="192.168.1.1"
> >>>>> that can be set in user.conf.
> >>>>> And of course all the other interfaces as well... INT2DNS, INT3DNS,
> INT4DNS, DMZDNS and EXTDNS
> >>>>> These can be a space or comma separated list of IP addresses, so if
> you want to push a primary and secondary you can...
> >>>>> INT2DNS="8.8.8.8 8.8.4.4"
> >>>>>
> >>>>> The changes to support that (IPv4 only for standard AstLinux) can be
> found here..
> >>>>>
> https://github.com/dkerr64/astlinux/commit/d20a4f40571258bbbf8725bfde6ec5a4254630ec
> >>>>> The full IPv6 version is in my "develop" branch.
> >>>>>
> >>>>> Up to Lonnie if he wants to pull the IPv4 version into the Astlinux
> master.
> >>>>>
> >>>>> David
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Sat, Oct 20, 2018 at 6:00 PM Michael Keuter <
> li...@mk...> wrote:
> >>>>>
> >>>>>> Am 20.10.2018 um 23:50 schrieb David Kerr <da...@ke...>:
> >>>>>>
> >>>>>> So, been thinking this through. I didn't realize that primary and
> secondary DNS could in fact be both used in parallel. I had assumed that
> secondary would be used only if primary failed. If I had a dedicated DNS
> server for pi-hole this might be okay (raspberry pi on my network maybe?)
> but I have it running in a VM which is running on Astlinux and it is also
> my UniFi Controller. I am trying to cover the possibility of that VM not
> being running, even if for just a few minutes during a reboot. When
> Astlinux reboots the VM image also restarts but maybe delayed by a minute
> or two as it goes through its boot. So DNS will take longer to come back
> up.
> >>>>>>
> >>>>>> I think two choices. I can change DHCP to push out the IP address
> of pi-hole VM. Or I can put some iptables rules in place to reroute DNS
> requests that come in to Astlinux (using NAT rules, needs both DNAT and
> SNAT rules). The benefit of iptables rules is that I could apply it to
> entire network (even statically assigned clients) if I want and I can
> quickly revert the entire network to using Astlinux directly for DNS if I
> need to. But it is a more complex solution than just pushing out a DNS
> server address.
> >>>>>>
> >>>>>> Pondering over this. Any thoughts?
> >>>>>>
> >>>>>> David
> >>>>>
> >>>>> Hi David,
> >>>>>
> >>>>> I am running a real Raspi 3 Model B+ with Pi hole, and my AstLinux
> router does DHCP and upstream DNS.
> >>>>> All DHCP devices get only the Pi as DNS server, which does
> Ad-blocking and then forwards the requests to the AstLinux router (with the
> config described in my former email). The Raspi is always on.
> >>>>>
> >>>>>> On Fri, Oct 19, 2018 at 5:33 PM Lonnie Abelbeck <
> li...@lo...> wrote:
> >>>>>> Ahhh, pi-hole ....
> >>>>>>
> >>>>>> Keep in mind that depending on the DNS client, given two DNS server
> IP's they can be queried in parallel and not just failover as
> primary/secondary would imply.
> >>>>>>
> >>>>>> Can you configure AstLinux to use the pi-hole IP as the system's
> static DNS server ? or is there a startup chicken/egg issue ?
> >>>>>>
> >>>>>> Network -> DNS: ____
> >>>>>>
> >>>>>> Lonnie
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> On Oct 19, 2018, at 4:13 PM, David Kerr <Da...@Ke...> wrote:
> >>>>>>>
> >>>>>>> I'll try dnsmasq.static. As to why... I have installed pi-hole (
> https://pi-hole.net/) on a VM and want to point clients at it as primary
> DNS, astlinux as secondary in case it fails. I configured pi-hole to use
> my astlinux as its primary DNS so all queries will ultimately go through
> astlinux, after pi-hole has done its thing to filter out the unwanted. No
> idea if I will keep this but thought I would give it a try and see if the
> family notices or if anything breaks.
> >>>>>>>
> >>>>>>> David
> >>>>>>>
> >>>>>>> On Fri, Oct 19, 2018 at 4:54 PM Lonnie Abelbeck <
> li...@lo...> wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>> On Oct 19, 2018, at 3:44 PM, David Kerr <da...@ke...> wrote:
> >>>>>>>>
> >>>>>>>> I'm probably just overlooking it, but is there a way for me to
> define the DNS servers that get pushed to clients in DHCP responses? Say I
> wanted to push out 192.168.1.2 instead (or as well as) 192.168.1.1, how
> would I do that?
> >>>>>>>
> >>>>>>> No trivial way. Possibly you could override the
> "dhcp-option=lan,option:dns-server,.." value using /mnt/kd/dnsmasq.static .
> >>>>>>>
> >>>>>>> Which begs the question, Why ? :-)
> >>>>>>>
> >>>>>>> Lonnie
> >>>>>
> >>>>> Michael
>
>
> Michael
>
> http://www.mksolutions.info
>
>
>
>
>
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>
|
|
From: Michael K. <li...@mk...> - 2018-11-01 23:05:02
|
> Am 01.11.2018 um 22:46 schrieb Michael Knill <mic...@ip...>:
>
> I personally don't think I would use it. I use dnsmasq.static for everything that needs to be changed.
+1
> Are you thinking of adding it to the Network Tab?
>
> Regards
> Michael Knill
>
> On 2/11/18, 6:51 am, "Lonnie Abelbeck" <li...@lo...> wrote:
>
> Any thoughts on adding a DHCP_OPTION_DNS_SERVER rc.conf variable ? (outlined below)
>
> Useful, or extraneous ?
>
>
> Lonnie
>
>
>
>> On Oct 24, 2018, at 9:12 AM, Lonnie Abelbeck <li...@lo...> wrote:
>>
>>> Does DMZ require another physical ethernet port?
>>
>> No, the DMZ can be a VLAN.
>>
>> Lonnie
>>
>>
>>
>>> On Oct 24, 2018, at 8:55 AM, David Kerr <Da...@Ke...> wrote:
>>>
>>> Does DMZ require another physical ethernet port? I've used up all three on my APU2.
>>>
>>> David
>>>
>>> On Wed, Oct 24, 2018 at 9:14 AM Lonnie Abelbeck <li...@lo...> wrote:
>>> How about this...
>>>
>>> Hardware Pi-hole with AstLinux
>>> ------------------------------
>>>
>>> Place the Pi-hole box off the DMZ interface.
>>>
>>> Example: DMZ is 10.10.50.1/24 and Pi-hole static IP is 10.10.50.53/24 with it's upstream DNS set to 10.10.50.1
>>>
>>> Network -> Firewall Configuration: {Firewall Configuration}
>>> --
>>> Action: [Pass DMZ->Local]
>>> Source: 10.10.50.53
>>> Port: 53
>>> Protocol: TCP/UDP
>>> Comment: Allow Pi-hole upstream DNS via Local
>>> --
>>>
>>> Network -> Advanced Configuration: {Edit User Variables}
>>> --
>>> DHCP_OPTION_DNS_SERVER="10.10.50.53"
>>> --
>>>
>>> The only code change required would be adding DHCP_OPTION_DNS_SERVER rc.conf support:
>>> -- package/dnsmasq/dnsmasq.init --
>>> trueDNSMASQnet()
>>> ...
>>> - dhcp-option=$1,option:dns-server,$gateway
>>> + dhcp-option=$1,option:dns-server,${DHCP_OPTION_DNS_SERVER:-$gateway}
>>> --
>>> Same idea as David's, but simplified.
>>>
>>> FYI, in case you forgot, the default DMZ firewall rules are:
>>> 1) Block all DMZ initiated connections to internal interfaces and Local AstLinux
>>> 2) Allow all DMZ initiated connections via external interface.
>>> 3) Allow all internal interfaces and Local AstLinux initiated connections to the DMZ
>>>
>>> With this scenario, AstLinux can be configured with "DNS-TLS Proxy Server" enabled to encrypt all Pi-hole upstream requests, as well as any local "DNS Hosts" can be honored via Pi-hole.
>>>
>>> Thoughts ?
>>>
>>> Lonnie
>>>
>>>
>>>
>>>
>>>> On Oct 23, 2018, at 8:32 PM, David Kerr <Da...@Ke...> wrote:
>>>>
>>>> Hi Lonnie,
>>>> Interesting thought about making pi-hole the upstream DNS for Astlinux (and therefore the whole network). You would certainly loose a lot of the metrics that pi-hole captures, though I am not sure how much I care about those. Mainly for geek interest I think. I do notice on pi-hole settings page support for DNSSEC with a note that it only works with google, norton, dns.watch and quad9 servers. I do not see a way to specify port number for pi-hole's upstream servers, but you could use iptables on Astlinux to REDIRECT traffic from pi-hole's static ip going to port 53 and send it instead to 2853, I think that might work.
>>>>
>>>> I do agree it is a pity that pi-hole isn't a whole lot simpler... would be great if it could just be added to AstLinux, but clearly that is not the approach they took and given cost of a Raspberry Pi it is maybe not that unreasonable for them to take the approach they did.
>>>>
>>>> Not at home this week so I cannot do any experimenting. I did leave pi-hole active at home, lets hope I don't return to annoyed family... I have already had to whitelist some domains just to get google sponsored search results to work.
>>>>
>>>> David
>>>>
>>>> On Sun, Oct 21, 2018 at 11:28 PM Lonnie Abelbeck <li...@lo...> wrote:
>>>>> This is not a problem for standard AstLinux because that does not support DHCP for IPv6 so on a AstLinux LAN dual IPv4/IPv6 is required and DNS comes from IPv4.
>>>>
>>>> Indeed, and is why I like the idea of only supporting DHCPv4 on internal interfaces, it just works, and works consistently.
>>>>
>>>>
>>>>> The changes to support that (IPv4 only for standard AstLinux) can be found here..
>>>>> https://github.com/dkerr64/astlinux/commit/d20a4f40571258bbbf8725bfde6ec5a4254630ec
>>>>
>>>> David, nicely done (I have a few quibbles) but you put your finger on where it would go.
>>>>
>>>>
>>>> Taking a step back, if a dedicated Raspberry Pi was performing DNS for the whole network, wouldn't it be better for AstLinux to just use it as it's static DNS source ? like ...
>>>>
>>>> Network -> DNS: ____
>>>>
>>>> In this case all the requests would be coming from AstLinux itself, would you be loosing any interesting statistics on the pi-hole web interface ?
>>>>
>>>> More importantly, the pi-hole should offer DNS-TLS upstream (via stubby like we do), I'm not sure if that has been implemented (lots of requests for it by DuckDuckGo'ing it).
>>>>
>>>> If you have a simple single LAN, then I can see tweaking the DHCP "option:dns-server" would be a reasonable choice, but when you have multiple LAN's/VLAN's and a single pi-hole it would require adding a bunch of firewall rules for DNS to be accessed across subnets. Not to mention requiring dnsmasq setup tweaks like what David proposed above.
>>>>
>>>> I would imagine that pi-hole should support DNS-TLS upstream at some point. I suppose we could optionally have our stubby daemon listen on 0.0.0.0@2853 instead of 127.0.0.1@2853 so a local pi-hole could direct DNS to it's internal gateway at port 2853 ... bypassing dnsmasq's DNS altogether. It would take some testing, assuming pi-hole can forward upstream to both address and port.
>>>>
>>>> Sadly the pi-hole project basically requires a full "Linux system" rather than just a single daemon, the later could be easily incorporated into AstLinux directly.
>>>>
>>>> Lonnie
>>>>
>>>>
>>>>
>>>>
>>>>> On Oct 21, 2018, at 7:57 PM, David Kerr <da...@ke...> wrote:
>>>>>
>>>>> Moving this to developer list...
>>>>>
>>>>> I decided to go the same route as Michael. I found a old Raspberry Pi lying around and set it up as a pi-hole server. Then I went the route of setting dnsmasq option to replace the DNS server pushed out to DHCP clients.
>>>>>
>>>>> As I did this I found a quirk of dnsmasq...
>>>>> NOTE... following does NOT apply to standard AstLinux, only to my version, but it is worth documenting.
>>>>> For IPv4 all is fine. The dhcp-option statement in dnsmasq.static seems to replace/overwrite that in dnsmasq.conf.
>>>>> However for IPv6 it was not as clean cut as that. On iOS devices both the IPv6 address in dnsmasq.conf and that in dnsmasq.static was getting picked up by the IPv6 network stack on iOS devices. This did not appear to be happening on MacOS devices however, very odd.
>>>>> This is not a problem for standard AstLinux because that does not support DHCP for IPv6 so on a AstLinux LAN dual IPv4/IPv6 is required and DNS comes from IPv4. I have implemented much richer IPv6 support for local networks but this has not been incorporated back into the standard AstLinux (yet?).
>>>>>
>>>>> I decided therefore that it would make sense to allow for manual configuration of DNS servers in Astlinux, so that it would be done by the system into dnsmasq.conf and not require setting in dnsmasq.static. I therefore implemented support for...
>>>>> INTDNS="192.168.1.1"
>>>>> that can be set in user.conf.
>>>>> And of course all the other interfaces as well... INT2DNS, INT3DNS, INT4DNS, DMZDNS and EXTDNS
>>>>> These can be a space or comma separated list of IP addresses, so if you want to push a primary and secondary you can...
>>>>> INT2DNS="8.8.8.8 8.8.4.4"
>>>>>
>>>>> The changes to support that (IPv4 only for standard AstLinux) can be found here..
>>>>> https://github.com/dkerr64/astlinux/commit/d20a4f40571258bbbf8725bfde6ec5a4254630ec
>>>>> The full IPv6 version is in my "develop" branch.
>>>>>
>>>>> Up to Lonnie if he wants to pull the IPv4 version into the Astlinux master.
>>>>>
>>>>> David
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Sat, Oct 20, 2018 at 6:00 PM Michael Keuter <li...@mk...> wrote:
>>>>>
>>>>>> Am 20.10.2018 um 23:50 schrieb David Kerr <da...@ke...>:
>>>>>>
>>>>>> So, been thinking this through. I didn't realize that primary and secondary DNS could in fact be both used in parallel. I had assumed that secondary would be used only if primary failed. If I had a dedicated DNS server for pi-hole this might be okay (raspberry pi on my network maybe?) but I have it running in a VM which is running on Astlinux and it is also my UniFi Controller. I am trying to cover the possibility of that VM not being running, even if for just a few minutes during a reboot. When Astlinux reboots the VM image also restarts but maybe delayed by a minute or two as it goes through its boot. So DNS will take longer to come back up.
>>>>>>
>>>>>> I think two choices. I can change DHCP to push out the IP address of pi-hole VM. Or I can put some iptables rules in place to reroute DNS requests that come in to Astlinux (using NAT rules, needs both DNAT and SNAT rules). The benefit of iptables rules is that I could apply it to entire network (even statically assigned clients) if I want and I can quickly revert the entire network to using Astlinux directly for DNS if I need to. But it is a more complex solution than just pushing out a DNS server address.
>>>>>>
>>>>>> Pondering over this. Any thoughts?
>>>>>>
>>>>>> David
>>>>>
>>>>> Hi David,
>>>>>
>>>>> I am running a real Raspi 3 Model B+ with Pi hole, and my AstLinux router does DHCP and upstream DNS.
>>>>> All DHCP devices get only the Pi as DNS server, which does Ad-blocking and then forwards the requests to the AstLinux router (with the config described in my former email). The Raspi is always on.
>>>>>
>>>>>> On Fri, Oct 19, 2018 at 5:33 PM Lonnie Abelbeck <li...@lo...> wrote:
>>>>>> Ahhh, pi-hole ....
>>>>>>
>>>>>> Keep in mind that depending on the DNS client, given two DNS server IP's they can be queried in parallel and not just failover as primary/secondary would imply.
>>>>>>
>>>>>> Can you configure AstLinux to use the pi-hole IP as the system's static DNS server ? or is there a startup chicken/egg issue ?
>>>>>>
>>>>>> Network -> DNS: ____
>>>>>>
>>>>>> Lonnie
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On Oct 19, 2018, at 4:13 PM, David Kerr <Da...@Ke...> wrote:
>>>>>>>
>>>>>>> I'll try dnsmasq.static. As to why... I have installed pi-hole (https://pi-hole.net/) on a VM and want to point clients at it as primary DNS, astlinux as secondary in case it fails. I configured pi-hole to use my astlinux as its primary DNS so all queries will ultimately go through astlinux, after pi-hole has done its thing to filter out the unwanted. No idea if I will keep this but thought I would give it a try and see if the family notices or if anything breaks.
>>>>>>>
>>>>>>> David
>>>>>>>
>>>>>>> On Fri, Oct 19, 2018 at 4:54 PM Lonnie Abelbeck <li...@lo...> wrote:
>>>>>>>
>>>>>>>
>>>>>>>> On Oct 19, 2018, at 3:44 PM, David Kerr <da...@ke...> wrote:
>>>>>>>>
>>>>>>>> I'm probably just overlooking it, but is there a way for me to define the DNS servers that get pushed to clients in DHCP responses? Say I wanted to push out 192.168.1.2 instead (or as well as) 192.168.1.1, how would I do that?
>>>>>>>
>>>>>>> No trivial way. Possibly you could override the "dhcp-option=lan,option:dns-server,.." value using /mnt/kd/dnsmasq.static .
>>>>>>>
>>>>>>> Which begs the question, Why ? :-)
>>>>>>>
>>>>>>> Lonnie
>>>>>
>>>>> Michael
Michael
http://www.mksolutions.info
|
|
From: Lonnie A. <li...@lo...> - 2018-11-01 21:55:01
|
> Are you thinking of adding it to the Network Tab?
Not directly, it would be a user.conf variable. I can't imagine it would be commonly used, mostly pi-hole implementations.
Lonnie
> On Nov 1, 2018, at 4:46 PM, Michael Knill <mic...@ip...> wrote:
>
> I personally don't think I would use it. I use dnsmasq.static for everything that needs to be changed.
> Are you thinking of adding it to the Network Tab?
>
> Regards
> Michael Knill
>
> On 2/11/18, 6:51 am, "Lonnie Abelbeck" <li...@lo...> wrote:
>
> Any thoughts on adding a DHCP_OPTION_DNS_SERVER rc.conf variable ? (outlined below)
>
> Useful, or extraneous ?
>
>
> Lonnie
>
>
>
>> On Oct 24, 2018, at 9:12 AM, Lonnie Abelbeck <li...@lo...> wrote:
>>
>>> Does DMZ require another physical ethernet port?
>>
>> No, the DMZ can be a VLAN.
>>
>> Lonnie
>>
>>
>>
>>> On Oct 24, 2018, at 8:55 AM, David Kerr <Da...@Ke...> wrote:
>>>
>>> Does DMZ require another physical ethernet port? I've used up all three on my APU2.
>>>
>>> David
>>>
>>> On Wed, Oct 24, 2018 at 9:14 AM Lonnie Abelbeck <li...@lo...> wrote:
>>> How about this...
>>>
>>> Hardware Pi-hole with AstLinux
>>> ------------------------------
>>>
>>> Place the Pi-hole box off the DMZ interface.
>>>
>>> Example: DMZ is 10.10.50.1/24 and Pi-hole static IP is 10.10.50.53/24 with it's upstream DNS set to 10.10.50.1
>>>
>>> Network -> Firewall Configuration: {Firewall Configuration}
>>> --
>>> Action: [Pass DMZ->Local]
>>> Source: 10.10.50.53
>>> Port: 53
>>> Protocol: TCP/UDP
>>> Comment: Allow Pi-hole upstream DNS via Local
>>> --
>>>
>>> Network -> Advanced Configuration: {Edit User Variables}
>>> --
>>> DHCP_OPTION_DNS_SERVER="10.10.50.53"
>>> --
>>>
>>> The only code change required would be adding DHCP_OPTION_DNS_SERVER rc.conf support:
>>> -- package/dnsmasq/dnsmasq.init --
>>> trueDNSMASQnet()
>>> ...
>>> - dhcp-option=$1,option:dns-server,$gateway
>>> + dhcp-option=$1,option:dns-server,${DHCP_OPTION_DNS_SERVER:-$gateway}
>>> --
>>> Same idea as David's, but simplified.
>>>
>>> FYI, in case you forgot, the default DMZ firewall rules are:
>>> 1) Block all DMZ initiated connections to internal interfaces and Local AstLinux
>>> 2) Allow all DMZ initiated connections via external interface.
>>> 3) Allow all internal interfaces and Local AstLinux initiated connections to the DMZ
>>>
>>> With this scenario, AstLinux can be configured with "DNS-TLS Proxy Server" enabled to encrypt all Pi-hole upstream requests, as well as any local "DNS Hosts" can be honored via Pi-hole.
>>>
>>> Thoughts ?
>>>
>>> Lonnie
>>>
>>>
>>>
>>>
>>>> On Oct 23, 2018, at 8:32 PM, David Kerr <Da...@Ke...> wrote:
>>>>
>>>> Hi Lonnie,
>>>> Interesting thought about making pi-hole the upstream DNS for Astlinux (and therefore the whole network). You would certainly loose a lot of the metrics that pi-hole captures, though I am not sure how much I care about those. Mainly for geek interest I think. I do notice on pi-hole settings page support for DNSSEC with a note that it only works with google, norton, dns.watch and quad9 servers. I do not see a way to specify port number for pi-hole's upstream servers, but you could use iptables on Astlinux to REDIRECT traffic from pi-hole's static ip going to port 53 and send it instead to 2853, I think that might work.
>>>>
>>>> I do agree it is a pity that pi-hole isn't a whole lot simpler... would be great if it could just be added to AstLinux, but clearly that is not the approach they took and given cost of a Raspberry Pi it is maybe not that unreasonable for them to take the approach they did.
>>>>
>>>> Not at home this week so I cannot do any experimenting. I did leave pi-hole active at home, lets hope I don't return to annoyed family... I have already had to whitelist some domains just to get google sponsored search results to work.
>>>>
>>>> David
>>>>
>>>> On Sun, Oct 21, 2018 at 11:28 PM Lonnie Abelbeck <li...@lo...> wrote:
>>>>> This is not a problem for standard AstLinux because that does not support DHCP for IPv6 so on a AstLinux LAN dual IPv4/IPv6 is required and DNS comes from IPv4.
>>>>
>>>> Indeed, and is why I like the idea of only supporting DHCPv4 on internal interfaces, it just works, and works consistently.
>>>>
>>>>
>>>>> The changes to support that (IPv4 only for standard AstLinux) can be found here..
>>>>> https://github.com/dkerr64/astlinux/commit/d20a4f40571258bbbf8725bfde6ec5a4254630ec
>>>>
>>>> David, nicely done (I have a few quibbles) but you put your finger on where it would go.
>>>>
>>>>
>>>> Taking a step back, if a dedicated Raspberry Pi was performing DNS for the whole network, wouldn't it be better for AstLinux to just use it as it's static DNS source ? like ...
>>>>
>>>> Network -> DNS: ____
>>>>
>>>> In this case all the requests would be coming from AstLinux itself, would you be loosing any interesting statistics on the pi-hole web interface ?
>>>>
>>>> More importantly, the pi-hole should offer DNS-TLS upstream (via stubby like we do), I'm not sure if that has been implemented (lots of requests for it by DuckDuckGo'ing it).
>>>>
>>>> If you have a simple single LAN, then I can see tweaking the DHCP "option:dns-server" would be a reasonable choice, but when you have multiple LAN's/VLAN's and a single pi-hole it would require adding a bunch of firewall rules for DNS to be accessed across subnets. Not to mention requiring dnsmasq setup tweaks like what David proposed above.
>>>>
>>>> I would imagine that pi-hole should support DNS-TLS upstream at some point. I suppose we could optionally have our stubby daemon listen on 0.0.0.0@2853 instead of 127.0.0.1@2853 so a local pi-hole could direct DNS to it's internal gateway at port 2853 ... bypassing dnsmasq's DNS altogether. It would take some testing, assuming pi-hole can forward upstream to both address and port.
>>>>
>>>> Sadly the pi-hole project basically requires a full "Linux system" rather than just a single daemon, the later could be easily incorporated into AstLinux directly.
>>>>
>>>> Lonnie
>>>>
>>>>
>>>>
>>>>
>>>>> On Oct 21, 2018, at 7:57 PM, David Kerr <da...@ke...> wrote:
>>>>>
>>>>> Moving this to developer list...
>>>>>
>>>>> I decided to go the same route as Michael. I found a old Raspberry Pi lying around and set it up as a pi-hole server. Then I went the route of setting dnsmasq option to replace the DNS server pushed out to DHCP clients.
>>>>>
>>>>> As I did this I found a quirk of dnsmasq...
>>>>> NOTE... following does NOT apply to standard AstLinux, only to my version, but it is worth documenting.
>>>>> For IPv4 all is fine. The dhcp-option statement in dnsmasq.static seems to replace/overwrite that in dnsmasq.conf.
>>>>> However for IPv6 it was not as clean cut as that. On iOS devices both the IPv6 address in dnsmasq.conf and that in dnsmasq.static was getting picked up by the IPv6 network stack on iOS devices. This did not appear to be happening on MacOS devices however, very odd.
>>>>> This is not a problem for standard AstLinux because that does not support DHCP for IPv6 so on a AstLinux LAN dual IPv4/IPv6 is required and DNS comes from IPv4. I have implemented much richer IPv6 support for local networks but this has not been incorporated back into the standard AstLinux (yet?).
>>>>>
>>>>> I decided therefore that it would make sense to allow for manual configuration of DNS servers in Astlinux, so that it would be done by the system into dnsmasq.conf and not require setting in dnsmasq.static. I therefore implemented support for...
>>>>> INTDNS="192.168.1.1"
>>>>> that can be set in user.conf.
>>>>> And of course all the other interfaces as well... INT2DNS, INT3DNS, INT4DNS, DMZDNS and EXTDNS
>>>>> These can be a space or comma separated list of IP addresses, so if you want to push a primary and secondary you can...
>>>>> INT2DNS="8.8.8.8 8.8.4.4"
>>>>>
>>>>> The changes to support that (IPv4 only for standard AstLinux) can be found here..
>>>>> https://github.com/dkerr64/astlinux/commit/d20a4f40571258bbbf8725bfde6ec5a4254630ec
>>>>> The full IPv6 version is in my "develop" branch.
>>>>>
>>>>> Up to Lonnie if he wants to pull the IPv4 version into the Astlinux master.
>>>>>
>>>>> David
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Sat, Oct 20, 2018 at 6:00 PM Michael Keuter <li...@mk...> wrote:
>>>>>
>>>>>> Am 20.10.2018 um 23:50 schrieb David Kerr <da...@ke...>:
>>>>>>
>>>>>> So, been thinking this through. I didn't realize that primary and secondary DNS could in fact be both used in parallel. I had assumed that secondary would be used only if primary failed. If I had a dedicated DNS server for pi-hole this might be okay (raspberry pi on my network maybe?) but I have it running in a VM which is running on Astlinux and it is also my UniFi Controller. I am trying to cover the possibility of that VM not being running, even if for just a few minutes during a reboot. When Astlinux reboots the VM image also restarts but maybe delayed by a minute or two as it goes through its boot. So DNS will take longer to come back up.
>>>>>>
>>>>>> I think two choices. I can change DHCP to push out the IP address of pi-hole VM. Or I can put some iptables rules in place to reroute DNS requests that come in to Astlinux (using NAT rules, needs both DNAT and SNAT rules). The benefit of iptables rules is that I could apply it to entire network (even statically assigned clients) if I want and I can quickly revert the entire network to using Astlinux directly for DNS if I need to. But it is a more complex solution than just pushing out a DNS server address.
>>>>>>
>>>>>> Pondering over this. Any thoughts?
>>>>>>
>>>>>> David
>>>>>
>>>>> Hi David,
>>>>>
>>>>> I am running a real Raspi 3 Model B+ with Pi hole, and my AstLinux router does DHCP and upstream DNS.
>>>>> All DHCP devices get only the Pi as DNS server, which does Ad-blocking and then forwards the requests to the AstLinux router (with the config described in my former email). The Raspi is always on.
>>>>>
>>>>>> On Fri, Oct 19, 2018 at 5:33 PM Lonnie Abelbeck <li...@lo...> wrote:
>>>>>> Ahhh, pi-hole ....
>>>>>>
>>>>>> Keep in mind that depending on the DNS client, given two DNS server IP's they can be queried in parallel and not just failover as primary/secondary would imply.
>>>>>>
>>>>>> Can you configure AstLinux to use the pi-hole IP as the system's static DNS server ? or is there a startup chicken/egg issue ?
>>>>>>
>>>>>> Network -> DNS: ____
>>>>>>
>>>>>> Lonnie
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On Oct 19, 2018, at 4:13 PM, David Kerr <Da...@Ke...> wrote:
>>>>>>>
>>>>>>> I'll try dnsmasq.static. As to why... I have installed pi-hole (https://pi-hole.net/) on a VM and want to point clients at it as primary DNS, astlinux as secondary in case it fails. I configured pi-hole to use my astlinux as its primary DNS so all queries will ultimately go through astlinux, after pi-hole has done its thing to filter out the unwanted. No idea if I will keep this but thought I would give it a try and see if the family notices or if anything breaks.
>>>>>>>
>>>>>>> David
>>>>>>>
>>>>>>> On Fri, Oct 19, 2018 at 4:54 PM Lonnie Abelbeck <li...@lo...> wrote:
>>>>>>>
>>>>>>>
>>>>>>>> On Oct 19, 2018, at 3:44 PM, David Kerr <da...@ke...> wrote:
>>>>>>>>
>>>>>>>> I'm probably just overlooking it, but is there a way for me to define the DNS servers that get pushed to clients in DHCP responses? Say I wanted to push out 192.168.1.2 instead (or as well as) 192.168.1.1, how would I do that?
>>>>>>>
>>>>>>> No trivial way. Possibly you could override the "dhcp-option=lan,option:dns-server,.." value using /mnt/kd/dnsmasq.static .
>>>>>>>
>>>>>>> Which begs the question, Why ? :-)
>>>>>>>
>>>>>>> Lonnie
>>>>>
>>>>> Michael
>>>>>
>
>
>
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>
>
>
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
|
|
From: Michael K. <mic...@ip...> - 2018-11-01 21:46:48
|
I personally don't think I would use it. I use dnsmasq.static for everything that needs to be changed.
Are you thinking of adding it to the Network Tab?
Regards
Michael Knill
On 2/11/18, 6:51 am, "Lonnie Abelbeck" <li...@lo...> wrote:
Any thoughts on adding a DHCP_OPTION_DNS_SERVER rc.conf variable ? (outlined below)
Useful, or extraneous ?
Lonnie
> On Oct 24, 2018, at 9:12 AM, Lonnie Abelbeck <li...@lo...> wrote:
>
>> Does DMZ require another physical ethernet port?
>
> No, the DMZ can be a VLAN.
>
> Lonnie
>
>
>
>> On Oct 24, 2018, at 8:55 AM, David Kerr <Da...@Ke...> wrote:
>>
>> Does DMZ require another physical ethernet port? I've used up all three on my APU2.
>>
>> David
>>
>> On Wed, Oct 24, 2018 at 9:14 AM Lonnie Abelbeck <li...@lo...> wrote:
>> How about this...
>>
>> Hardware Pi-hole with AstLinux
>> ------------------------------
>>
>> Place the Pi-hole box off the DMZ interface.
>>
>> Example: DMZ is 10.10.50.1/24 and Pi-hole static IP is 10.10.50.53/24 with it's upstream DNS set to 10.10.50.1
>>
>> Network -> Firewall Configuration: {Firewall Configuration}
>> --
>> Action: [Pass DMZ->Local]
>> Source: 10.10.50.53
>> Port: 53
>> Protocol: TCP/UDP
>> Comment: Allow Pi-hole upstream DNS via Local
>> --
>>
>> Network -> Advanced Configuration: {Edit User Variables}
>> --
>> DHCP_OPTION_DNS_SERVER="10.10.50.53"
>> --
>>
>> The only code change required would be adding DHCP_OPTION_DNS_SERVER rc.conf support:
>> -- package/dnsmasq/dnsmasq.init --
>> trueDNSMASQnet()
>> ...
>> - dhcp-option=$1,option:dns-server,$gateway
>> + dhcp-option=$1,option:dns-server,${DHCP_OPTION_DNS_SERVER:-$gateway}
>> --
>> Same idea as David's, but simplified.
>>
>> FYI, in case you forgot, the default DMZ firewall rules are:
>> 1) Block all DMZ initiated connections to internal interfaces and Local AstLinux
>> 2) Allow all DMZ initiated connections via external interface.
>> 3) Allow all internal interfaces and Local AstLinux initiated connections to the DMZ
>>
>> With this scenario, AstLinux can be configured with "DNS-TLS Proxy Server" enabled to encrypt all Pi-hole upstream requests, as well as any local "DNS Hosts" can be honored via Pi-hole.
>>
>> Thoughts ?
>>
>> Lonnie
>>
>>
>>
>>
>>> On Oct 23, 2018, at 8:32 PM, David Kerr <Da...@Ke...> wrote:
>>>
>>> Hi Lonnie,
>>> Interesting thought about making pi-hole the upstream DNS for Astlinux (and therefore the whole network). You would certainly loose a lot of the metrics that pi-hole captures, though I am not sure how much I care about those. Mainly for geek interest I think. I do notice on pi-hole settings page support for DNSSEC with a note that it only works with google, norton, dns.watch and quad9 servers. I do not see a way to specify port number for pi-hole's upstream servers, but you could use iptables on Astlinux to REDIRECT traffic from pi-hole's static ip going to port 53 and send it instead to 2853, I think that might work.
>>>
>>> I do agree it is a pity that pi-hole isn't a whole lot simpler... would be great if it could just be added to AstLinux, but clearly that is not the approach they took and given cost of a Raspberry Pi it is maybe not that unreasonable for them to take the approach they did.
>>>
>>> Not at home this week so I cannot do any experimenting. I did leave pi-hole active at home, lets hope I don't return to annoyed family... I have already had to whitelist some domains just to get google sponsored search results to work.
>>>
>>> David
>>>
>>> On Sun, Oct 21, 2018 at 11:28 PM Lonnie Abelbeck <li...@lo...> wrote:
>>>> This is not a problem for standard AstLinux because that does not support DHCP for IPv6 so on a AstLinux LAN dual IPv4/IPv6 is required and DNS comes from IPv4.
>>>
>>> Indeed, and is why I like the idea of only supporting DHCPv4 on internal interfaces, it just works, and works consistently.
>>>
>>>
>>>> The changes to support that (IPv4 only for standard AstLinux) can be found here..
>>>> https://github.com/dkerr64/astlinux/commit/d20a4f40571258bbbf8725bfde6ec5a4254630ec
>>>
>>> David, nicely done (I have a few quibbles) but you put your finger on where it would go.
>>>
>>>
>>> Taking a step back, if a dedicated Raspberry Pi was performing DNS for the whole network, wouldn't it be better for AstLinux to just use it as it's static DNS source ? like ...
>>>
>>> Network -> DNS: ____
>>>
>>> In this case all the requests would be coming from AstLinux itself, would you be loosing any interesting statistics on the pi-hole web interface ?
>>>
>>> More importantly, the pi-hole should offer DNS-TLS upstream (via stubby like we do), I'm not sure if that has been implemented (lots of requests for it by DuckDuckGo'ing it).
>>>
>>> If you have a simple single LAN, then I can see tweaking the DHCP "option:dns-server" would be a reasonable choice, but when you have multiple LAN's/VLAN's and a single pi-hole it would require adding a bunch of firewall rules for DNS to be accessed across subnets. Not to mention requiring dnsmasq setup tweaks like what David proposed above.
>>>
>>> I would imagine that pi-hole should support DNS-TLS upstream at some point. I suppose we could optionally have our stubby daemon listen on 0.0.0.0@2853 instead of 127.0.0.1@2853 so a local pi-hole could direct DNS to it's internal gateway at port 2853 ... bypassing dnsmasq's DNS altogether. It would take some testing, assuming pi-hole can forward upstream to both address and port.
>>>
>>> Sadly the pi-hole project basically requires a full "Linux system" rather than just a single daemon, the later could be easily incorporated into AstLinux directly.
>>>
>>> Lonnie
>>>
>>>
>>>
>>>
>>>> On Oct 21, 2018, at 7:57 PM, David Kerr <da...@ke...> wrote:
>>>>
>>>> Moving this to developer list...
>>>>
>>>> I decided to go the same route as Michael. I found a old Raspberry Pi lying around and set it up as a pi-hole server. Then I went the route of setting dnsmasq option to replace the DNS server pushed out to DHCP clients.
>>>>
>>>> As I did this I found a quirk of dnsmasq...
>>>> NOTE... following does NOT apply to standard AstLinux, only to my version, but it is worth documenting.
>>>> For IPv4 all is fine. The dhcp-option statement in dnsmasq.static seems to replace/overwrite that in dnsmasq.conf.
>>>> However for IPv6 it was not as clean cut as that. On iOS devices both the IPv6 address in dnsmasq.conf and that in dnsmasq.static was getting picked up by the IPv6 network stack on iOS devices. This did not appear to be happening on MacOS devices however, very odd.
>>>> This is not a problem for standard AstLinux because that does not support DHCP for IPv6 so on a AstLinux LAN dual IPv4/IPv6 is required and DNS comes from IPv4. I have implemented much richer IPv6 support for local networks but this has not been incorporated back into the standard AstLinux (yet?).
>>>>
>>>> I decided therefore that it would make sense to allow for manual configuration of DNS servers in Astlinux, so that it would be done by the system into dnsmasq.conf and not require setting in dnsmasq.static. I therefore implemented support for...
>>>> INTDNS="192.168.1.1"
>>>> that can be set in user.conf.
>>>> And of course all the other interfaces as well... INT2DNS, INT3DNS, INT4DNS, DMZDNS and EXTDNS
>>>> These can be a space or comma separated list of IP addresses, so if you want to push a primary and secondary you can...
>>>> INT2DNS="8.8.8.8 8.8.4.4"
>>>>
>>>> The changes to support that (IPv4 only for standard AstLinux) can be found here..
>>>> https://github.com/dkerr64/astlinux/commit/d20a4f40571258bbbf8725bfde6ec5a4254630ec
>>>> The full IPv6 version is in my "develop" branch.
>>>>
>>>> Up to Lonnie if he wants to pull the IPv4 version into the Astlinux master.
>>>>
>>>> David
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Sat, Oct 20, 2018 at 6:00 PM Michael Keuter <li...@mk...> wrote:
>>>>
>>>>> Am 20.10.2018 um 23:50 schrieb David Kerr <da...@ke...>:
>>>>>
>>>>> So, been thinking this through. I didn't realize that primary and secondary DNS could in fact be both used in parallel. I had assumed that secondary would be used only if primary failed. If I had a dedicated DNS server for pi-hole this might be okay (raspberry pi on my network maybe?) but I have it running in a VM which is running on Astlinux and it is also my UniFi Controller. I am trying to cover the possibility of that VM not being running, even if for just a few minutes during a reboot. When Astlinux reboots the VM image also restarts but maybe delayed by a minute or two as it goes through its boot. So DNS will take longer to come back up.
>>>>>
>>>>> I think two choices. I can change DHCP to push out the IP address of pi-hole VM. Or I can put some iptables rules in place to reroute DNS requests that come in to Astlinux (using NAT rules, needs both DNAT and SNAT rules). The benefit of iptables rules is that I could apply it to entire network (even statically assigned clients) if I want and I can quickly revert the entire network to using Astlinux directly for DNS if I need to. But it is a more complex solution than just pushing out a DNS server address.
>>>>>
>>>>> Pondering over this. Any thoughts?
>>>>>
>>>>> David
>>>>
>>>> Hi David,
>>>>
>>>> I am running a real Raspi 3 Model B+ with Pi hole, and my AstLinux router does DHCP and upstream DNS.
>>>> All DHCP devices get only the Pi as DNS server, which does Ad-blocking and then forwards the requests to the AstLinux router (with the config described in my former email). The Raspi is always on.
>>>>
>>>>> On Fri, Oct 19, 2018 at 5:33 PM Lonnie Abelbeck <li...@lo...> wrote:
>>>>> Ahhh, pi-hole ....
>>>>>
>>>>> Keep in mind that depending on the DNS client, given two DNS server IP's they can be queried in parallel and not just failover as primary/secondary would imply.
>>>>>
>>>>> Can you configure AstLinux to use the pi-hole IP as the system's static DNS server ? or is there a startup chicken/egg issue ?
>>>>>
>>>>> Network -> DNS: ____
>>>>>
>>>>> Lonnie
>>>>>
>>>>>
>>>>>
>>>>>> On Oct 19, 2018, at 4:13 PM, David Kerr <Da...@Ke...> wrote:
>>>>>>
>>>>>> I'll try dnsmasq.static. As to why... I have installed pi-hole (https://pi-hole.net/) on a VM and want to point clients at it as primary DNS, astlinux as secondary in case it fails. I configured pi-hole to use my astlinux as its primary DNS so all queries will ultimately go through astlinux, after pi-hole has done its thing to filter out the unwanted. No idea if I will keep this but thought I would give it a try and see if the family notices or if anything breaks.
>>>>>>
>>>>>> David
>>>>>>
>>>>>> On Fri, Oct 19, 2018 at 4:54 PM Lonnie Abelbeck <li...@lo...> wrote:
>>>>>>
>>>>>>
>>>>>>> On Oct 19, 2018, at 3:44 PM, David Kerr <da...@ke...> wrote:
>>>>>>>
>>>>>>> I'm probably just overlooking it, but is there a way for me to define the DNS servers that get pushed to clients in DHCP responses? Say I wanted to push out 192.168.1.2 instead (or as well as) 192.168.1.1, how would I do that?
>>>>>>
>>>>>> No trivial way. Possibly you could override the "dhcp-option=lan,option:dns-server,.." value using /mnt/kd/dnsmasq.static .
>>>>>>
>>>>>> Which begs the question, Why ? :-)
>>>>>>
>>>>>> Lonnie
>>>>
>>>> Michael
>>>>
_______________________________________________
Astlinux-devel mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-devel
|
|
From: Lonnie A. <li...@lo...> - 2018-11-01 19:51:12
|
Any thoughts on adding a DHCP_OPTION_DNS_SERVER rc.conf variable ? (outlined below)
Useful, or extraneous ?
Lonnie
> On Oct 24, 2018, at 9:12 AM, Lonnie Abelbeck <li...@lo...> wrote:
>
>> Does DMZ require another physical ethernet port?
>
> No, the DMZ can be a VLAN.
>
> Lonnie
>
>
>
>> On Oct 24, 2018, at 8:55 AM, David Kerr <Da...@Ke...> wrote:
>>
>> Does DMZ require another physical ethernet port? I've used up all three on my APU2.
>>
>> David
>>
>> On Wed, Oct 24, 2018 at 9:14 AM Lonnie Abelbeck <li...@lo...> wrote:
>> How about this...
>>
>> Hardware Pi-hole with AstLinux
>> ------------------------------
>>
>> Place the Pi-hole box off the DMZ interface.
>>
>> Example: DMZ is 10.10.50.1/24 and Pi-hole static IP is 10.10.50.53/24 with it's upstream DNS set to 10.10.50.1
>>
>> Network -> Firewall Configuration: {Firewall Configuration}
>> --
>> Action: [Pass DMZ->Local]
>> Source: 10.10.50.53
>> Port: 53
>> Protocol: TCP/UDP
>> Comment: Allow Pi-hole upstream DNS via Local
>> --
>>
>> Network -> Advanced Configuration: {Edit User Variables}
>> --
>> DHCP_OPTION_DNS_SERVER="10.10.50.53"
>> --
>>
>> The only code change required would be adding DHCP_OPTION_DNS_SERVER rc.conf support:
>> -- package/dnsmasq/dnsmasq.init --
>> trueDNSMASQnet()
>> ...
>> - dhcp-option=$1,option:dns-server,$gateway
>> + dhcp-option=$1,option:dns-server,${DHCP_OPTION_DNS_SERVER:-$gateway}
>> --
>> Same idea as David's, but simplified.
>>
>> FYI, in case you forgot, the default DMZ firewall rules are:
>> 1) Block all DMZ initiated connections to internal interfaces and Local AstLinux
>> 2) Allow all DMZ initiated connections via external interface.
>> 3) Allow all internal interfaces and Local AstLinux initiated connections to the DMZ
>>
>> With this scenario, AstLinux can be configured with "DNS-TLS Proxy Server" enabled to encrypt all Pi-hole upstream requests, as well as any local "DNS Hosts" can be honored via Pi-hole.
>>
>> Thoughts ?
>>
>> Lonnie
>>
>>
>>
>>
>>> On Oct 23, 2018, at 8:32 PM, David Kerr <Da...@Ke...> wrote:
>>>
>>> Hi Lonnie,
>>> Interesting thought about making pi-hole the upstream DNS for Astlinux (and therefore the whole network). You would certainly loose a lot of the metrics that pi-hole captures, though I am not sure how much I care about those. Mainly for geek interest I think. I do notice on pi-hole settings page support for DNSSEC with a note that it only works with google, norton, dns.watch and quad9 servers. I do not see a way to specify port number for pi-hole's upstream servers, but you could use iptables on Astlinux to REDIRECT traffic from pi-hole's static ip going to port 53 and send it instead to 2853, I think that might work.
>>>
>>> I do agree it is a pity that pi-hole isn't a whole lot simpler... would be great if it could just be added to AstLinux, but clearly that is not the approach they took and given cost of a Raspberry Pi it is maybe not that unreasonable for them to take the approach they did.
>>>
>>> Not at home this week so I cannot do any experimenting. I did leave pi-hole active at home, lets hope I don't return to annoyed family... I have already had to whitelist some domains just to get google sponsored search results to work.
>>>
>>> David
>>>
>>> On Sun, Oct 21, 2018 at 11:28 PM Lonnie Abelbeck <li...@lo...> wrote:
>>>> This is not a problem for standard AstLinux because that does not support DHCP for IPv6 so on a AstLinux LAN dual IPv4/IPv6 is required and DNS comes from IPv4.
>>>
>>> Indeed, and is why I like the idea of only supporting DHCPv4 on internal interfaces, it just works, and works consistently.
>>>
>>>
>>>> The changes to support that (IPv4 only for standard AstLinux) can be found here..
>>>> https://github.com/dkerr64/astlinux/commit/d20a4f40571258bbbf8725bfde6ec5a4254630ec
>>>
>>> David, nicely done (I have a few quibbles) but you put your finger on where it would go.
>>>
>>>
>>> Taking a step back, if a dedicated Raspberry Pi was performing DNS for the whole network, wouldn't it be better for AstLinux to just use it as it's static DNS source ? like ...
>>>
>>> Network -> DNS: ____
>>>
>>> In this case all the requests would be coming from AstLinux itself, would you be loosing any interesting statistics on the pi-hole web interface ?
>>>
>>> More importantly, the pi-hole should offer DNS-TLS upstream (via stubby like we do), I'm not sure if that has been implemented (lots of requests for it by DuckDuckGo'ing it).
>>>
>>> If you have a simple single LAN, then I can see tweaking the DHCP "option:dns-server" would be a reasonable choice, but when you have multiple LAN's/VLAN's and a single pi-hole it would require adding a bunch of firewall rules for DNS to be accessed across subnets. Not to mention requiring dnsmasq setup tweaks like what David proposed above.
>>>
>>> I would imagine that pi-hole should support DNS-TLS upstream at some point. I suppose we could optionally have our stubby daemon listen on 0.0.0.0@2853 instead of 127.0.0.1@2853 so a local pi-hole could direct DNS to it's internal gateway at port 2853 ... bypassing dnsmasq's DNS altogether. It would take some testing, assuming pi-hole can forward upstream to both address and port.
>>>
>>> Sadly the pi-hole project basically requires a full "Linux system" rather than just a single daemon, the later could be easily incorporated into AstLinux directly.
>>>
>>> Lonnie
>>>
>>>
>>>
>>>
>>>> On Oct 21, 2018, at 7:57 PM, David Kerr <da...@ke...> wrote:
>>>>
>>>> Moving this to developer list...
>>>>
>>>> I decided to go the same route as Michael. I found a old Raspberry Pi lying around and set it up as a pi-hole server. Then I went the route of setting dnsmasq option to replace the DNS server pushed out to DHCP clients.
>>>>
>>>> As I did this I found a quirk of dnsmasq...
>>>> NOTE... following does NOT apply to standard AstLinux, only to my version, but it is worth documenting.
>>>> For IPv4 all is fine. The dhcp-option statement in dnsmasq.static seems to replace/overwrite that in dnsmasq.conf.
>>>> However for IPv6 it was not as clean cut as that. On iOS devices both the IPv6 address in dnsmasq.conf and that in dnsmasq.static was getting picked up by the IPv6 network stack on iOS devices. This did not appear to be happening on MacOS devices however, very odd.
>>>> This is not a problem for standard AstLinux because that does not support DHCP for IPv6 so on a AstLinux LAN dual IPv4/IPv6 is required and DNS comes from IPv4. I have implemented much richer IPv6 support for local networks but this has not been incorporated back into the standard AstLinux (yet?).
>>>>
>>>> I decided therefore that it would make sense to allow for manual configuration of DNS servers in Astlinux, so that it would be done by the system into dnsmasq.conf and not require setting in dnsmasq.static. I therefore implemented support for...
>>>> INTDNS="192.168.1.1"
>>>> that can be set in user.conf.
>>>> And of course all the other interfaces as well... INT2DNS, INT3DNS, INT4DNS, DMZDNS and EXTDNS
>>>> These can be a space or comma separated list of IP addresses, so if you want to push a primary and secondary you can...
>>>> INT2DNS="8.8.8.8 8.8.4.4"
>>>>
>>>> The changes to support that (IPv4 only for standard AstLinux) can be found here..
>>>> https://github.com/dkerr64/astlinux/commit/d20a4f40571258bbbf8725bfde6ec5a4254630ec
>>>> The full IPv6 version is in my "develop" branch.
>>>>
>>>> Up to Lonnie if he wants to pull the IPv4 version into the Astlinux master.
>>>>
>>>> David
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Sat, Oct 20, 2018 at 6:00 PM Michael Keuter <li...@mk...> wrote:
>>>>
>>>>> Am 20.10.2018 um 23:50 schrieb David Kerr <da...@ke...>:
>>>>>
>>>>> So, been thinking this through. I didn't realize that primary and secondary DNS could in fact be both used in parallel. I had assumed that secondary would be used only if primary failed. If I had a dedicated DNS server for pi-hole this might be okay (raspberry pi on my network maybe?) but I have it running in a VM which is running on Astlinux and it is also my UniFi Controller. I am trying to cover the possibility of that VM not being running, even if for just a few minutes during a reboot. When Astlinux reboots the VM image also restarts but maybe delayed by a minute or two as it goes through its boot. So DNS will take longer to come back up.
>>>>>
>>>>> I think two choices. I can change DHCP to push out the IP address of pi-hole VM. Or I can put some iptables rules in place to reroute DNS requests that come in to Astlinux (using NAT rules, needs both DNAT and SNAT rules). The benefit of iptables rules is that I could apply it to entire network (even statically assigned clients) if I want and I can quickly revert the entire network to using Astlinux directly for DNS if I need to. But it is a more complex solution than just pushing out a DNS server address.
>>>>>
>>>>> Pondering over this. Any thoughts?
>>>>>
>>>>> David
>>>>
>>>> Hi David,
>>>>
>>>> I am running a real Raspi 3 Model B+ with Pi hole, and my AstLinux router does DHCP and upstream DNS.
>>>> All DHCP devices get only the Pi as DNS server, which does Ad-blocking and then forwards the requests to the AstLinux router (with the config described in my former email). The Raspi is always on.
>>>>
>>>>> On Fri, Oct 19, 2018 at 5:33 PM Lonnie Abelbeck <li...@lo...> wrote:
>>>>> Ahhh, pi-hole ....
>>>>>
>>>>> Keep in mind that depending on the DNS client, given two DNS server IP's they can be queried in parallel and not just failover as primary/secondary would imply.
>>>>>
>>>>> Can you configure AstLinux to use the pi-hole IP as the system's static DNS server ? or is there a startup chicken/egg issue ?
>>>>>
>>>>> Network -> DNS: ____
>>>>>
>>>>> Lonnie
>>>>>
>>>>>
>>>>>
>>>>>> On Oct 19, 2018, at 4:13 PM, David Kerr <Da...@Ke...> wrote:
>>>>>>
>>>>>> I'll try dnsmasq.static. As to why... I have installed pi-hole (https://pi-hole.net/) on a VM and want to point clients at it as primary DNS, astlinux as secondary in case it fails. I configured pi-hole to use my astlinux as its primary DNS so all queries will ultimately go through astlinux, after pi-hole has done its thing to filter out the unwanted. No idea if I will keep this but thought I would give it a try and see if the family notices or if anything breaks.
>>>>>>
>>>>>> David
>>>>>>
>>>>>> On Fri, Oct 19, 2018 at 4:54 PM Lonnie Abelbeck <li...@lo...> wrote:
>>>>>>
>>>>>>
>>>>>>> On Oct 19, 2018, at 3:44 PM, David Kerr <da...@ke...> wrote:
>>>>>>>
>>>>>>> I'm probably just overlooking it, but is there a way for me to define the DNS servers that get pushed to clients in DHCP responses? Say I wanted to push out 192.168.1.2 instead (or as well as) 192.168.1.1, how would I do that?
>>>>>>
>>>>>> No trivial way. Possibly you could override the "dhcp-option=lan,option:dns-server,.." value using /mnt/kd/dnsmasq.static .
>>>>>>
>>>>>> Which begs the question, Why ? :-)
>>>>>>
>>>>>> Lonnie
>>>>
>>>> Michael
>>>>
|
|
From: Lonnie A. <li...@lo...> - 2018-10-24 14:12:47
|
> Does DMZ require another physical ethernet port?
No, the DMZ can be a VLAN.
Lonnie
> On Oct 24, 2018, at 8:55 AM, David Kerr <Da...@Ke...> wrote:
>
> Does DMZ require another physical ethernet port? I've used up all three on my APU2.
>
> David
>
> On Wed, Oct 24, 2018 at 9:14 AM Lonnie Abelbeck <li...@lo...> wrote:
> How about this...
>
> Hardware Pi-hole with AstLinux
> ------------------------------
>
> Place the Pi-hole box off the DMZ interface.
>
> Example: DMZ is 10.10.50.1/24 and Pi-hole static IP is 10.10.50.53/24 with it's upstream DNS set to 10.10.50.1
>
> Network -> Firewall Configuration: {Firewall Configuration}
> --
> Action: [Pass DMZ->Local]
> Source: 10.10.50.53
> Port: 53
> Protocol: TCP/UDP
> Comment: Allow Pi-hole upstream DNS via Local
> --
>
> Network -> Advanced Configuration: {Edit User Variables}
> --
> DHCP_OPTION_DNS_SERVER="10.10.50.53"
> --
>
> The only code change required would be adding DHCP_OPTION_DNS_SERVER rc.conf support:
> -- package/dnsmasq/dnsmasq.init --
> trueDNSMASQnet()
> ...
> - dhcp-option=$1,option:dns-server,$gateway
> + dhcp-option=$1,option:dns-server,${DHCP_OPTION_DNS_SERVER:-$gateway}
> --
> Same idea as David's, but simplified.
>
> FYI, in case you forgot, the default DMZ firewall rules are:
> 1) Block all DMZ initiated connections to internal interfaces and Local AstLinux
> 2) Allow all DMZ initiated connections via external interface.
> 3) Allow all internal interfaces and Local AstLinux initiated connections to the DMZ
>
> With this scenario, AstLinux can be configured with "DNS-TLS Proxy Server" enabled to encrypt all Pi-hole upstream requests, as well as any local "DNS Hosts" can be honored via Pi-hole.
>
> Thoughts ?
>
> Lonnie
>
>
>
>
> > On Oct 23, 2018, at 8:32 PM, David Kerr <Da...@Ke...> wrote:
> >
> > Hi Lonnie,
> > Interesting thought about making pi-hole the upstream DNS for Astlinux (and therefore the whole network). You would certainly loose a lot of the metrics that pi-hole captures, though I am not sure how much I care about those. Mainly for geek interest I think. I do notice on pi-hole settings page support for DNSSEC with a note that it only works with google, norton, dns.watch and quad9 servers. I do not see a way to specify port number for pi-hole's upstream servers, but you could use iptables on Astlinux to REDIRECT traffic from pi-hole's static ip going to port 53 and send it instead to 2853, I think that might work.
> >
> > I do agree it is a pity that pi-hole isn't a whole lot simpler... would be great if it could just be added to AstLinux, but clearly that is not the approach they took and given cost of a Raspberry Pi it is maybe not that unreasonable for them to take the approach they did.
> >
> > Not at home this week so I cannot do any experimenting. I did leave pi-hole active at home, lets hope I don't return to annoyed family... I have already had to whitelist some domains just to get google sponsored search results to work.
> >
> > David
> >
> > On Sun, Oct 21, 2018 at 11:28 PM Lonnie Abelbeck <li...@lo...> wrote:
> > > This is not a problem for standard AstLinux because that does not support DHCP for IPv6 so on a AstLinux LAN dual IPv4/IPv6 is required and DNS comes from IPv4.
> >
> > Indeed, and is why I like the idea of only supporting DHCPv4 on internal interfaces, it just works, and works consistently.
> >
> >
> > > The changes to support that (IPv4 only for standard AstLinux) can be found here..
> > > https://github.com/dkerr64/astlinux/commit/d20a4f40571258bbbf8725bfde6ec5a4254630ec
> >
> > David, nicely done (I have a few quibbles) but you put your finger on where it would go.
> >
> >
> > Taking a step back, if a dedicated Raspberry Pi was performing DNS for the whole network, wouldn't it be better for AstLinux to just use it as it's static DNS source ? like ...
> >
> > Network -> DNS: ____
> >
> > In this case all the requests would be coming from AstLinux itself, would you be loosing any interesting statistics on the pi-hole web interface ?
> >
> > More importantly, the pi-hole should offer DNS-TLS upstream (via stubby like we do), I'm not sure if that has been implemented (lots of requests for it by DuckDuckGo'ing it).
> >
> > If you have a simple single LAN, then I can see tweaking the DHCP "option:dns-server" would be a reasonable choice, but when you have multiple LAN's/VLAN's and a single pi-hole it would require adding a bunch of firewall rules for DNS to be accessed across subnets. Not to mention requiring dnsmasq setup tweaks like what David proposed above.
> >
> > I would imagine that pi-hole should support DNS-TLS upstream at some point. I suppose we could optionally have our stubby daemon listen on 0.0.0.0@2853 instead of 127.0.0.1@2853 so a local pi-hole could direct DNS to it's internal gateway at port 2853 ... bypassing dnsmasq's DNS altogether. It would take some testing, assuming pi-hole can forward upstream to both address and port.
> >
> > Sadly the pi-hole project basically requires a full "Linux system" rather than just a single daemon, the later could be easily incorporated into AstLinux directly.
> >
> > Lonnie
> >
> >
> >
> >
> > > On Oct 21, 2018, at 7:57 PM, David Kerr <da...@ke...> wrote:
> > >
> > > Moving this to developer list...
> > >
> > > I decided to go the same route as Michael. I found a old Raspberry Pi lying around and set it up as a pi-hole server. Then I went the route of setting dnsmasq option to replace the DNS server pushed out to DHCP clients.
> > >
> > > As I did this I found a quirk of dnsmasq...
> > > NOTE... following does NOT apply to standard AstLinux, only to my version, but it is worth documenting.
> > > For IPv4 all is fine. The dhcp-option statement in dnsmasq.static seems to replace/overwrite that in dnsmasq.conf.
> > > However for IPv6 it was not as clean cut as that. On iOS devices both the IPv6 address in dnsmasq.conf and that in dnsmasq.static was getting picked up by the IPv6 network stack on iOS devices. This did not appear to be happening on MacOS devices however, very odd.
> > > This is not a problem for standard AstLinux because that does not support DHCP for IPv6 so on a AstLinux LAN dual IPv4/IPv6 is required and DNS comes from IPv4. I have implemented much richer IPv6 support for local networks but this has not been incorporated back into the standard AstLinux (yet?).
> > >
> > > I decided therefore that it would make sense to allow for manual configuration of DNS servers in Astlinux, so that it would be done by the system into dnsmasq.conf and not require setting in dnsmasq.static. I therefore implemented support for...
> > > INTDNS="192.168.1.1"
> > > that can be set in user.conf.
> > > And of course all the other interfaces as well... INT2DNS, INT3DNS, INT4DNS, DMZDNS and EXTDNS
> > > These can be a space or comma separated list of IP addresses, so if you want to push a primary and secondary you can...
> > > INT2DNS="8.8.8.8 8.8.4.4"
> > >
> > > The changes to support that (IPv4 only for standard AstLinux) can be found here..
> > > https://github.com/dkerr64/astlinux/commit/d20a4f40571258bbbf8725bfde6ec5a4254630ec
> > > The full IPv6 version is in my "develop" branch.
> > >
> > > Up to Lonnie if he wants to pull the IPv4 version into the Astlinux master.
> > >
> > > David
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Sat, Oct 20, 2018 at 6:00 PM Michael Keuter <li...@mk...> wrote:
> > >
> > > > Am 20.10.2018 um 23:50 schrieb David Kerr <da...@ke...>:
> > > >
> > > > So, been thinking this through. I didn't realize that primary and secondary DNS could in fact be both used in parallel. I had assumed that secondary would be used only if primary failed. If I had a dedicated DNS server for pi-hole this might be okay (raspberry pi on my network maybe?) but I have it running in a VM which is running on Astlinux and it is also my UniFi Controller. I am trying to cover the possibility of that VM not being running, even if for just a few minutes during a reboot. When Astlinux reboots the VM image also restarts but maybe delayed by a minute or two as it goes through its boot. So DNS will take longer to come back up.
> > > >
> > > > I think two choices. I can change DHCP to push out the IP address of pi-hole VM. Or I can put some iptables rules in place to reroute DNS requests that come in to Astlinux (using NAT rules, needs both DNAT and SNAT rules). The benefit of iptables rules is that I could apply it to entire network (even statically assigned clients) if I want and I can quickly revert the entire network to using Astlinux directly for DNS if I need to. But it is a more complex solution than just pushing out a DNS server address.
> > > >
> > > > Pondering over this. Any thoughts?
> > > >
> > > > David
> > >
> > > Hi David,
> > >
> > > I am running a real Raspi 3 Model B+ with Pi hole, and my AstLinux router does DHCP and upstream DNS.
> > > All DHCP devices get only the Pi as DNS server, which does Ad-blocking and then forwards the requests to the AstLinux router (with the config described in my former email). The Raspi is always on.
> > >
> > > > On Fri, Oct 19, 2018 at 5:33 PM Lonnie Abelbeck <li...@lo...> wrote:
> > > > Ahhh, pi-hole ....
> > > >
> > > > Keep in mind that depending on the DNS client, given two DNS server IP's they can be queried in parallel and not just failover as primary/secondary would imply.
> > > >
> > > > Can you configure AstLinux to use the pi-hole IP as the system's static DNS server ? or is there a startup chicken/egg issue ?
> > > >
> > > > Network -> DNS: ____
> > > >
> > > > Lonnie
> > > >
> > > >
> > > >
> > > > > On Oct 19, 2018, at 4:13 PM, David Kerr <Da...@Ke...> wrote:
> > > > >
> > > > > I'll try dnsmasq.static. As to why... I have installed pi-hole (https://pi-hole.net/) on a VM and want to point clients at it as primary DNS, astlinux as secondary in case it fails. I configured pi-hole to use my astlinux as its primary DNS so all queries will ultimately go through astlinux, after pi-hole has done its thing to filter out the unwanted. No idea if I will keep this but thought I would give it a try and see if the family notices or if anything breaks.
> > > > >
> > > > > David
> > > > >
> > > > > On Fri, Oct 19, 2018 at 4:54 PM Lonnie Abelbeck <li...@lo...> wrote:
> > > > >
> > > > >
> > > > > > On Oct 19, 2018, at 3:44 PM, David Kerr <da...@ke...> wrote:
> > > > > >
> > > > > > I'm probably just overlooking it, but is there a way for me to define the DNS servers that get pushed to clients in DHCP responses? Say I wanted to push out 192.168.1.2 instead (or as well as) 192.168.1.1, how would I do that?
> > > > >
> > > > > No trivial way. Possibly you could override the "dhcp-option=lan,option:dns-server,.." value using /mnt/kd/dnsmasq.static .
> > > > >
> > > > > Which begs the question, Why ? :-)
> > > > >
> > > > > Lonnie
> > >
> > > Michael
> > >
>
>
>
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
|
|
From: David K. <da...@ke...> - 2018-10-24 13:55:40
|
Does DMZ require another physical ethernet port? I've used up all three on
my APU2.
David
On Wed, Oct 24, 2018 at 9:14 AM Lonnie Abelbeck <li...@lo...>
wrote:
> How about this...
>
> Hardware Pi-hole with AstLinux
> ------------------------------
>
> Place the Pi-hole box off the DMZ interface.
>
> Example: DMZ is 10.10.50.1/24 and Pi-hole static IP is 10.10.50.53/24
> with it's upstream DNS set to 10.10.50.1
>
> Network -> Firewall Configuration: {Firewall Configuration}
> --
> Action: [Pass DMZ->Local]
> Source: 10.10.50.53
> Port: 53
> Protocol: TCP/UDP
> Comment: Allow Pi-hole upstream DNS via Local
> --
>
> Network -> Advanced Configuration: {Edit User Variables}
> --
> DHCP_OPTION_DNS_SERVER="10.10.50.53"
> --
>
> The only code change required would be adding DHCP_OPTION_DNS_SERVER
> rc.conf support:
> -- package/dnsmasq/dnsmasq.init --
> trueDNSMASQnet()
> ...
> - dhcp-option=$1,option:dns-server,$gateway
> + dhcp-option=$1,option:dns-server,${DHCP_OPTION_DNS_SERVER:-$gateway}
> --
> Same idea as David's, but simplified.
>
> FYI, in case you forgot, the default DMZ firewall rules are:
> 1) Block all DMZ initiated connections to internal interfaces and Local
> AstLinux
> 2) Allow all DMZ initiated connections via external interface.
> 3) Allow all internal interfaces and Local AstLinux initiated connections
> to the DMZ
>
> With this scenario, AstLinux can be configured with "DNS-TLS Proxy Server"
> enabled to encrypt all Pi-hole upstream requests, as well as any local "DNS
> Hosts" can be honored via Pi-hole.
>
> Thoughts ?
>
> Lonnie
>
>
>
>
> > On Oct 23, 2018, at 8:32 PM, David Kerr <Da...@Ke...> wrote:
> >
> > Hi Lonnie,
> > Interesting thought about making pi-hole the upstream DNS for Astlinux
> (and therefore the whole network). You would certainly loose a lot of the
> metrics that pi-hole captures, though I am not sure how much I care about
> those. Mainly for geek interest I think. I do notice on pi-hole settings
> page support for DNSSEC with a note that it only works with google, norton,
> dns.watch and quad9 servers. I do not see a way to specify port number for
> pi-hole's upstream servers, but you could use iptables on Astlinux to
> REDIRECT traffic from pi-hole's static ip going to port 53 and send it
> instead to 2853, I think that might work.
> >
> > I do agree it is a pity that pi-hole isn't a whole lot simpler... would
> be great if it could just be added to AstLinux, but clearly that is not the
> approach they took and given cost of a Raspberry Pi it is maybe not that
> unreasonable for them to take the approach they did.
> >
> > Not at home this week so I cannot do any experimenting. I did leave
> pi-hole active at home, lets hope I don't return to annoyed family... I
> have already had to whitelist some domains just to get google sponsored
> search results to work.
> >
> > David
> >
> > On Sun, Oct 21, 2018 at 11:28 PM Lonnie Abelbeck <
> li...@lo...> wrote:
> > > This is not a problem for standard AstLinux because that does not
> support DHCP for IPv6 so on a AstLinux LAN dual IPv4/IPv6 is required and
> DNS comes from IPv4.
> >
> > Indeed, and is why I like the idea of only supporting DHCPv4 on internal
> interfaces, it just works, and works consistently.
> >
> >
> > > The changes to support that (IPv4 only for standard AstLinux) can be
> found here..
> > >
> https://github.com/dkerr64/astlinux/commit/d20a4f40571258bbbf8725bfde6ec5a4254630ec
> >
> > David, nicely done (I have a few quibbles) but you put your finger on
> where it would go.
> >
> >
> > Taking a step back, if a dedicated Raspberry Pi was performing DNS for
> the whole network, wouldn't it be better for AstLinux to just use it as
> it's static DNS source ? like ...
> >
> > Network -> DNS: ____
> >
> > In this case all the requests would be coming from AstLinux itself,
> would you be loosing any interesting statistics on the pi-hole web
> interface ?
> >
> > More importantly, the pi-hole should offer DNS-TLS upstream (via stubby
> like we do), I'm not sure if that has been implemented (lots of requests
> for it by DuckDuckGo'ing it).
> >
> > If you have a simple single LAN, then I can see tweaking the DHCP
> "option:dns-server" would be a reasonable choice, but when you have
> multiple LAN's/VLAN's and a single pi-hole it would require adding a bunch
> of firewall rules for DNS to be accessed across subnets. Not to mention
> requiring dnsmasq setup tweaks like what David proposed above.
> >
> > I would imagine that pi-hole should support DNS-TLS upstream at some
> point. I suppose we could optionally have our stubby daemon listen on
> 0.0.0.0@2853 instead of 127.0.0.1@2853 so a local pi-hole could direct
> DNS to it's internal gateway at port 2853 ... bypassing dnsmasq's DNS
> altogether. It would take some testing, assuming pi-hole can forward
> upstream to both address and port.
> >
> > Sadly the pi-hole project basically requires a full "Linux system"
> rather than just a single daemon, the later could be easily incorporated
> into AstLinux directly.
> >
> > Lonnie
> >
> >
> >
> >
> > > On Oct 21, 2018, at 7:57 PM, David Kerr <da...@ke...> wrote:
> > >
> > > Moving this to developer list...
> > >
> > > I decided to go the same route as Michael. I found a old Raspberry Pi
> lying around and set it up as a pi-hole server. Then I went the route of
> setting dnsmasq option to replace the DNS server pushed out to DHCP clients.
> > >
> > > As I did this I found a quirk of dnsmasq...
> > > NOTE... following does NOT apply to standard AstLinux, only to my
> version, but it is worth documenting.
> > > For IPv4 all is fine. The dhcp-option statement in dnsmasq.static
> seems to replace/overwrite that in dnsmasq.conf.
> > > However for IPv6 it was not as clean cut as that. On iOS devices both
> the IPv6 address in dnsmasq.conf and that in dnsmasq.static was getting
> picked up by the IPv6 network stack on iOS devices. This did not appear to
> be happening on MacOS devices however, very odd.
> > > This is not a problem for standard AstLinux because that does not
> support DHCP for IPv6 so on a AstLinux LAN dual IPv4/IPv6 is required and
> DNS comes from IPv4. I have implemented much richer IPv6 support for local
> networks but this has not been incorporated back into the standard AstLinux
> (yet?).
> > >
> > > I decided therefore that it would make sense to allow for manual
> configuration of DNS servers in Astlinux, so that it would be done by the
> system into dnsmasq.conf and not require setting in dnsmasq.static. I
> therefore implemented support for...
> > > INTDNS="192.168.1.1"
> > > that can be set in user.conf.
> > > And of course all the other interfaces as well... INT2DNS, INT3DNS,
> INT4DNS, DMZDNS and EXTDNS
> > > These can be a space or comma separated list of IP addresses, so if
> you want to push a primary and secondary you can...
> > > INT2DNS="8.8.8.8 8.8.4.4"
> > >
> > > The changes to support that (IPv4 only for standard AstLinux) can be
> found here..
> > >
> https://github.com/dkerr64/astlinux/commit/d20a4f40571258bbbf8725bfde6ec5a4254630ec
> > > The full IPv6 version is in my "develop" branch.
> > >
> > > Up to Lonnie if he wants to pull the IPv4 version into the Astlinux
> master.
> > >
> > > David
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Sat, Oct 20, 2018 at 6:00 PM Michael Keuter <li...@mk...>
> wrote:
> > >
> > > > Am 20.10.2018 um 23:50 schrieb David Kerr <da...@ke...>:
> > > >
> > > > So, been thinking this through. I didn't realize that primary and
> secondary DNS could in fact be both used in parallel. I had assumed that
> secondary would be used only if primary failed. If I had a dedicated DNS
> server for pi-hole this might be okay (raspberry pi on my network maybe?)
> but I have it running in a VM which is running on Astlinux and it is also
> my UniFi Controller. I am trying to cover the possibility of that VM not
> being running, even if for just a few minutes during a reboot. When
> Astlinux reboots the VM image also restarts but maybe delayed by a minute
> or two as it goes through its boot. So DNS will take longer to come back
> up.
> > > >
> > > > I think two choices. I can change DHCP to push out the IP address
> of pi-hole VM. Or I can put some iptables rules in place to reroute DNS
> requests that come in to Astlinux (using NAT rules, needs both DNAT and
> SNAT rules). The benefit of iptables rules is that I could apply it to
> entire network (even statically assigned clients) if I want and I can
> quickly revert the entire network to using Astlinux directly for DNS if I
> need to. But it is a more complex solution than just pushing out a DNS
> server address.
> > > >
> > > > Pondering over this. Any thoughts?
> > > >
> > > > David
> > >
> > > Hi David,
> > >
> > > I am running a real Raspi 3 Model B+ with Pi hole, and my AstLinux
> router does DHCP and upstream DNS.
> > > All DHCP devices get only the Pi as DNS server, which does Ad-blocking
> and then forwards the requests to the AstLinux router (with the config
> described in my former email). The Raspi is always on.
> > >
> > > > On Fri, Oct 19, 2018 at 5:33 PM Lonnie Abelbeck <
> li...@lo...> wrote:
> > > > Ahhh, pi-hole ....
> > > >
> > > > Keep in mind that depending on the DNS client, given two DNS server
> IP's they can be queried in parallel and not just failover as
> primary/secondary would imply.
> > > >
> > > > Can you configure AstLinux to use the pi-hole IP as the system's
> static DNS server ? or is there a startup chicken/egg issue ?
> > > >
> > > > Network -> DNS: ____
> > > >
> > > > Lonnie
> > > >
> > > >
> > > >
> > > > > On Oct 19, 2018, at 4:13 PM, David Kerr <Da...@Ke...> wrote:
> > > > >
> > > > > I'll try dnsmasq.static. As to why... I have installed pi-hole (
> https://pi-hole.net/) on a VM and want to point clients at it as primary
> DNS, astlinux as secondary in case it fails. I configured pi-hole to use
> my astlinux as its primary DNS so all queries will ultimately go through
> astlinux, after pi-hole has done its thing to filter out the unwanted. No
> idea if I will keep this but thought I would give it a try and see if the
> family notices or if anything breaks.
> > > > >
> > > > > David
> > > > >
> > > > > On Fri, Oct 19, 2018 at 4:54 PM Lonnie Abelbeck <
> li...@lo...> wrote:
> > > > >
> > > > >
> > > > > > On Oct 19, 2018, at 3:44 PM, David Kerr <da...@ke...> wrote:
> > > > > >
> > > > > > I'm probably just overlooking it, but is there a way for me to
> define the DNS servers that get pushed to clients in DHCP responses? Say I
> wanted to push out 192.168.1.2 instead (or as well as) 192.168.1.1, how
> would I do that?
> > > > >
> > > > > No trivial way. Possibly you could override the
> "dhcp-option=lan,option:dns-server,.." value using /mnt/kd/dnsmasq.static .
> > > > >
> > > > > Which begs the question, Why ? :-)
> > > > >
> > > > > Lonnie
> > >
> > > Michael
> > >
>
>
>
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>
|
|
From: Lonnie A. <li...@lo...> - 2018-10-24 13:14:32
|
How about this...
Hardware Pi-hole with AstLinux
------------------------------
Place the Pi-hole box off the DMZ interface.
Example: DMZ is 10.10.50.1/24 and Pi-hole static IP is 10.10.50.53/24 with it's upstream DNS set to 10.10.50.1
Network -> Firewall Configuration: {Firewall Configuration}
--
Action: [Pass DMZ->Local]
Source: 10.10.50.53
Port: 53
Protocol: TCP/UDP
Comment: Allow Pi-hole upstream DNS via Local
--
Network -> Advanced Configuration: {Edit User Variables}
--
DHCP_OPTION_DNS_SERVER="10.10.50.53"
--
The only code change required would be adding DHCP_OPTION_DNS_SERVER rc.conf support:
-- package/dnsmasq/dnsmasq.init --
trueDNSMASQnet()
...
- dhcp-option=$1,option:dns-server,$gateway
+ dhcp-option=$1,option:dns-server,${DHCP_OPTION_DNS_SERVER:-$gateway}
--
Same idea as David's, but simplified.
FYI, in case you forgot, the default DMZ firewall rules are:
1) Block all DMZ initiated connections to internal interfaces and Local AstLinux
2) Allow all DMZ initiated connections via external interface.
3) Allow all internal interfaces and Local AstLinux initiated connections to the DMZ
With this scenario, AstLinux can be configured with "DNS-TLS Proxy Server" enabled to encrypt all Pi-hole upstream requests, as well as any local "DNS Hosts" can be honored via Pi-hole.
Thoughts ?
Lonnie
> On Oct 23, 2018, at 8:32 PM, David Kerr <Da...@Ke...> wrote:
>
> Hi Lonnie,
> Interesting thought about making pi-hole the upstream DNS for Astlinux (and therefore the whole network). You would certainly loose a lot of the metrics that pi-hole captures, though I am not sure how much I care about those. Mainly for geek interest I think. I do notice on pi-hole settings page support for DNSSEC with a note that it only works with google, norton, dns.watch and quad9 servers. I do not see a way to specify port number for pi-hole's upstream servers, but you could use iptables on Astlinux to REDIRECT traffic from pi-hole's static ip going to port 53 and send it instead to 2853, I think that might work.
>
> I do agree it is a pity that pi-hole isn't a whole lot simpler... would be great if it could just be added to AstLinux, but clearly that is not the approach they took and given cost of a Raspberry Pi it is maybe not that unreasonable for them to take the approach they did.
>
> Not at home this week so I cannot do any experimenting. I did leave pi-hole active at home, lets hope I don't return to annoyed family... I have already had to whitelist some domains just to get google sponsored search results to work.
>
> David
>
> On Sun, Oct 21, 2018 at 11:28 PM Lonnie Abelbeck <li...@lo...> wrote:
> > This is not a problem for standard AstLinux because that does not support DHCP for IPv6 so on a AstLinux LAN dual IPv4/IPv6 is required and DNS comes from IPv4.
>
> Indeed, and is why I like the idea of only supporting DHCPv4 on internal interfaces, it just works, and works consistently.
>
>
> > The changes to support that (IPv4 only for standard AstLinux) can be found here..
> > https://github.com/dkerr64/astlinux/commit/d20a4f40571258bbbf8725bfde6ec5a4254630ec
>
> David, nicely done (I have a few quibbles) but you put your finger on where it would go.
>
>
> Taking a step back, if a dedicated Raspberry Pi was performing DNS for the whole network, wouldn't it be better for AstLinux to just use it as it's static DNS source ? like ...
>
> Network -> DNS: ____
>
> In this case all the requests would be coming from AstLinux itself, would you be loosing any interesting statistics on the pi-hole web interface ?
>
> More importantly, the pi-hole should offer DNS-TLS upstream (via stubby like we do), I'm not sure if that has been implemented (lots of requests for it by DuckDuckGo'ing it).
>
> If you have a simple single LAN, then I can see tweaking the DHCP "option:dns-server" would be a reasonable choice, but when you have multiple LAN's/VLAN's and a single pi-hole it would require adding a bunch of firewall rules for DNS to be accessed across subnets. Not to mention requiring dnsmasq setup tweaks like what David proposed above.
>
> I would imagine that pi-hole should support DNS-TLS upstream at some point. I suppose we could optionally have our stubby daemon listen on 0.0.0.0@2853 instead of 127.0.0.1@2853 so a local pi-hole could direct DNS to it's internal gateway at port 2853 ... bypassing dnsmasq's DNS altogether. It would take some testing, assuming pi-hole can forward upstream to both address and port.
>
> Sadly the pi-hole project basically requires a full "Linux system" rather than just a single daemon, the later could be easily incorporated into AstLinux directly.
>
> Lonnie
>
>
>
>
> > On Oct 21, 2018, at 7:57 PM, David Kerr <da...@ke...> wrote:
> >
> > Moving this to developer list...
> >
> > I decided to go the same route as Michael. I found a old Raspberry Pi lying around and set it up as a pi-hole server. Then I went the route of setting dnsmasq option to replace the DNS server pushed out to DHCP clients.
> >
> > As I did this I found a quirk of dnsmasq...
> > NOTE... following does NOT apply to standard AstLinux, only to my version, but it is worth documenting.
> > For IPv4 all is fine. The dhcp-option statement in dnsmasq.static seems to replace/overwrite that in dnsmasq.conf.
> > However for IPv6 it was not as clean cut as that. On iOS devices both the IPv6 address in dnsmasq.conf and that in dnsmasq.static was getting picked up by the IPv6 network stack on iOS devices. This did not appear to be happening on MacOS devices however, very odd.
> > This is not a problem for standard AstLinux because that does not support DHCP for IPv6 so on a AstLinux LAN dual IPv4/IPv6 is required and DNS comes from IPv4. I have implemented much richer IPv6 support for local networks but this has not been incorporated back into the standard AstLinux (yet?).
> >
> > I decided therefore that it would make sense to allow for manual configuration of DNS servers in Astlinux, so that it would be done by the system into dnsmasq.conf and not require setting in dnsmasq.static. I therefore implemented support for...
> > INTDNS="192.168.1.1"
> > that can be set in user.conf.
> > And of course all the other interfaces as well... INT2DNS, INT3DNS, INT4DNS, DMZDNS and EXTDNS
> > These can be a space or comma separated list of IP addresses, so if you want to push a primary and secondary you can...
> > INT2DNS="8.8.8.8 8.8.4.4"
> >
> > The changes to support that (IPv4 only for standard AstLinux) can be found here..
> > https://github.com/dkerr64/astlinux/commit/d20a4f40571258bbbf8725bfde6ec5a4254630ec
> > The full IPv6 version is in my "develop" branch.
> >
> > Up to Lonnie if he wants to pull the IPv4 version into the Astlinux master.
> >
> > David
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On Sat, Oct 20, 2018 at 6:00 PM Michael Keuter <li...@mk...> wrote:
> >
> > > Am 20.10.2018 um 23:50 schrieb David Kerr <da...@ke...>:
> > >
> > > So, been thinking this through. I didn't realize that primary and secondary DNS could in fact be both used in parallel. I had assumed that secondary would be used only if primary failed. If I had a dedicated DNS server for pi-hole this might be okay (raspberry pi on my network maybe?) but I have it running in a VM which is running on Astlinux and it is also my UniFi Controller. I am trying to cover the possibility of that VM not being running, even if for just a few minutes during a reboot. When Astlinux reboots the VM image also restarts but maybe delayed by a minute or two as it goes through its boot. So DNS will take longer to come back up.
> > >
> > > I think two choices. I can change DHCP to push out the IP address of pi-hole VM. Or I can put some iptables rules in place to reroute DNS requests that come in to Astlinux (using NAT rules, needs both DNAT and SNAT rules). The benefit of iptables rules is that I could apply it to entire network (even statically assigned clients) if I want and I can quickly revert the entire network to using Astlinux directly for DNS if I need to. But it is a more complex solution than just pushing out a DNS server address.
> > >
> > > Pondering over this. Any thoughts?
> > >
> > > David
> >
> > Hi David,
> >
> > I am running a real Raspi 3 Model B+ with Pi hole, and my AstLinux router does DHCP and upstream DNS.
> > All DHCP devices get only the Pi as DNS server, which does Ad-blocking and then forwards the requests to the AstLinux router (with the config described in my former email). The Raspi is always on.
> >
> > > On Fri, Oct 19, 2018 at 5:33 PM Lonnie Abelbeck <li...@lo...> wrote:
> > > Ahhh, pi-hole ....
> > >
> > > Keep in mind that depending on the DNS client, given two DNS server IP's they can be queried in parallel and not just failover as primary/secondary would imply.
> > >
> > > Can you configure AstLinux to use the pi-hole IP as the system's static DNS server ? or is there a startup chicken/egg issue ?
> > >
> > > Network -> DNS: ____
> > >
> > > Lonnie
> > >
> > >
> > >
> > > > On Oct 19, 2018, at 4:13 PM, David Kerr <Da...@Ke...> wrote:
> > > >
> > > > I'll try dnsmasq.static. As to why... I have installed pi-hole (https://pi-hole.net/) on a VM and want to point clients at it as primary DNS, astlinux as secondary in case it fails. I configured pi-hole to use my astlinux as its primary DNS so all queries will ultimately go through astlinux, after pi-hole has done its thing to filter out the unwanted. No idea if I will keep this but thought I would give it a try and see if the family notices or if anything breaks.
> > > >
> > > > David
> > > >
> > > > On Fri, Oct 19, 2018 at 4:54 PM Lonnie Abelbeck <li...@lo...> wrote:
> > > >
> > > >
> > > > > On Oct 19, 2018, at 3:44 PM, David Kerr <da...@ke...> wrote:
> > > > >
> > > > > I'm probably just overlooking it, but is there a way for me to define the DNS servers that get pushed to clients in DHCP responses? Say I wanted to push out 192.168.1.2 instead (or as well as) 192.168.1.1, how would I do that?
> > > >
> > > > No trivial way. Possibly you could override the "dhcp-option=lan,option:dns-server,.." value using /mnt/kd/dnsmasq.static .
> > > >
> > > > Which begs the question, Why ? :-)
> > > >
> > > > Lonnie
> >
> > Michael
> >
|
|
From: David K. <da...@ke...> - 2018-10-24 01:32:31
|
Hi Lonnie, Interesting thought about making pi-hole the upstream DNS for Astlinux (and therefore the whole network). You would certainly loose a lot of the metrics that pi-hole captures, though I am not sure how much I care about those. Mainly for geek interest I think. I do notice on pi-hole settings page support for DNSSEC with a note that it only works with google, norton, dns.watch and quad9 servers. I do not see a way to specify port number for pi-hole's upstream servers, but you could use iptables on Astlinux to REDIRECT traffic from pi-hole's static ip going to port 53 and send it instead to 2853, I think that might work. I do agree it is a pity that pi-hole isn't a whole lot simpler... would be great if it could just be added to AstLinux, but clearly that is not the approach they took and given cost of a Raspberry Pi it is maybe not that unreasonable for them to take the approach they did. Not at home this week so I cannot do any experimenting. I did leave pi-hole active at home, lets hope I don't return to annoyed family... I have already had to whitelist some domains just to get google sponsored search results to work. David On Sun, Oct 21, 2018 at 11:28 PM Lonnie Abelbeck <li...@lo...> wrote: > > This is not a problem for standard AstLinux because that does not > support DHCP for IPv6 so on a AstLinux LAN dual IPv4/IPv6 is required and > DNS comes from IPv4. > > Indeed, and is why I like the idea of only supporting DHCPv4 on internal > interfaces, it just works, and works consistently. > > > > The changes to support that (IPv4 only for standard AstLinux) can be > found here.. > > > https://github.com/dkerr64/astlinux/commit/d20a4f40571258bbbf8725bfde6ec5a4254630ec > > David, nicely done (I have a few quibbles) but you put your finger on > where it would go. > > > Taking a step back, if a dedicated Raspberry Pi was performing DNS for the > whole network, wouldn't it be better for AstLinux to just use it as it's > static DNS source ? like ... > > Network -> DNS: ____ > > In this case all the requests would be coming from AstLinux itself, would > you be loosing any interesting statistics on the pi-hole web interface ? > > More importantly, the pi-hole should offer DNS-TLS upstream (via stubby > like we do), I'm not sure if that has been implemented (lots of requests > for it by DuckDuckGo'ing it). > > If you have a simple single LAN, then I can see tweaking the DHCP > "option:dns-server" would be a reasonable choice, but when you have > multiple LAN's/VLAN's and a single pi-hole it would require adding a bunch > of firewall rules for DNS to be accessed across subnets. Not to mention > requiring dnsmasq setup tweaks like what David proposed above. > > I would imagine that pi-hole should support DNS-TLS upstream at some > point. I suppose we could optionally have our stubby daemon listen on > 0.0.0.0@2853 instead of 127.0.0.1@2853 so a local pi-hole could direct > DNS to it's internal gateway at port 2853 ... bypassing dnsmasq's DNS > altogether. It would take some testing, assuming pi-hole can forward > upstream to both address and port. > > Sadly the pi-hole project basically requires a full "Linux system" rather > than just a single daemon, the later could be easily incorporated into > AstLinux directly. > > Lonnie > > > > > > On Oct 21, 2018, at 7:57 PM, David Kerr <da...@ke...> wrote: > > > > Moving this to developer list... > > > > I decided to go the same route as Michael. I found a old Raspberry Pi > lying around and set it up as a pi-hole server. Then I went the route of > setting dnsmasq option to replace the DNS server pushed out to DHCP clients. > > > > As I did this I found a quirk of dnsmasq... > > NOTE... following does NOT apply to standard AstLinux, only to my > version, but it is worth documenting. > > For IPv4 all is fine. The dhcp-option statement in dnsmasq.static seems > to replace/overwrite that in dnsmasq.conf. > > However for IPv6 it was not as clean cut as that. On iOS devices both > the IPv6 address in dnsmasq.conf and that in dnsmasq.static was getting > picked up by the IPv6 network stack on iOS devices. This did not appear to > be happening on MacOS devices however, very odd. > > This is not a problem for standard AstLinux because that does not > support DHCP for IPv6 so on a AstLinux LAN dual IPv4/IPv6 is required and > DNS comes from IPv4. I have implemented much richer IPv6 support for local > networks but this has not been incorporated back into the standard AstLinux > (yet?). > > > > I decided therefore that it would make sense to allow for manual > configuration of DNS servers in Astlinux, so that it would be done by the > system into dnsmasq.conf and not require setting in dnsmasq.static. I > therefore implemented support for... > > INTDNS="192.168.1.1" > > that can be set in user.conf. > > And of course all the other interfaces as well... INT2DNS, INT3DNS, > INT4DNS, DMZDNS and EXTDNS > > These can be a space or comma separated list of IP addresses, so if you > want to push a primary and secondary you can... > > INT2DNS="8.8.8.8 8.8.4.4" > > > > The changes to support that (IPv4 only for standard AstLinux) can be > found here.. > > > https://github.com/dkerr64/astlinux/commit/d20a4f40571258bbbf8725bfde6ec5a4254630ec > > The full IPv6 version is in my "develop" branch. > > > > Up to Lonnie if he wants to pull the IPv4 version into the Astlinux > master. > > > > David > > > > > > > > > > > > > > > > > > > > > > On Sat, Oct 20, 2018 at 6:00 PM Michael Keuter <li...@mk...> > wrote: > > > > > Am 20.10.2018 um 23:50 schrieb David Kerr <da...@ke...>: > > > > > > So, been thinking this through. I didn't realize that primary and > secondary DNS could in fact be both used in parallel. I had assumed that > secondary would be used only if primary failed. If I had a dedicated DNS > server for pi-hole this might be okay (raspberry pi on my network maybe?) > but I have it running in a VM which is running on Astlinux and it is also > my UniFi Controller. I am trying to cover the possibility of that VM not > being running, even if for just a few minutes during a reboot. When > Astlinux reboots the VM image also restarts but maybe delayed by a minute > or two as it goes through its boot. So DNS will take longer to come back > up. > > > > > > I think two choices. I can change DHCP to push out the IP address of > pi-hole VM. Or I can put some iptables rules in place to reroute DNS > requests that come in to Astlinux (using NAT rules, needs both DNAT and > SNAT rules). The benefit of iptables rules is that I could apply it to > entire network (even statically assigned clients) if I want and I can > quickly revert the entire network to using Astlinux directly for DNS if I > need to. But it is a more complex solution than just pushing out a DNS > server address. > > > > > > Pondering over this. Any thoughts? > > > > > > David > > > > Hi David, > > > > I am running a real Raspi 3 Model B+ with Pi hole, and my AstLinux > router does DHCP and upstream DNS. > > All DHCP devices get only the Pi as DNS server, which does Ad-blocking > and then forwards the requests to the AstLinux router (with the config > described in my former email). The Raspi is always on. > > > > > On Fri, Oct 19, 2018 at 5:33 PM Lonnie Abelbeck < > li...@lo...> wrote: > > > Ahhh, pi-hole .... > > > > > > Keep in mind that depending on the DNS client, given two DNS server > IP's they can be queried in parallel and not just failover as > primary/secondary would imply. > > > > > > Can you configure AstLinux to use the pi-hole IP as the system's > static DNS server ? or is there a startup chicken/egg issue ? > > > > > > Network -> DNS: ____ > > > > > > Lonnie > > > > > > > > > > > > > On Oct 19, 2018, at 4:13 PM, David Kerr <Da...@Ke...> wrote: > > > > > > > > I'll try dnsmasq.static. As to why... I have installed pi-hole ( > https://pi-hole.net/) on a VM and want to point clients at it as primary > DNS, astlinux as secondary in case it fails. I configured pi-hole to use > my astlinux as its primary DNS so all queries will ultimately go through > astlinux, after pi-hole has done its thing to filter out the unwanted. No > idea if I will keep this but thought I would give it a try and see if the > family notices or if anything breaks. > > > > > > > > David > > > > > > > > On Fri, Oct 19, 2018 at 4:54 PM Lonnie Abelbeck < > li...@lo...> wrote: > > > > > > > > > > > > > On Oct 19, 2018, at 3:44 PM, David Kerr <da...@ke...> wrote: > > > > > > > > > > I'm probably just overlooking it, but is there a way for me to > define the DNS servers that get pushed to clients in DHCP responses? Say I > wanted to push out 192.168.1.2 instead (or as well as) 192.168.1.1, how > would I do that? > > > > > > > > No trivial way. Possibly you could override the > "dhcp-option=lan,option:dns-server,.." value using /mnt/kd/dnsmasq.static . > > > > > > > > Which begs the question, Why ? :-) > > > > > > > > Lonnie > > > > Michael > > > > http://www.mksolutions.info > > > > > > > > > > > > _______________________________________________ > > Astlinux-users mailing list > > Ast...@li... > > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > > > Donations to support AstLinux are graciously accepted via PayPal to > pa...@kr.... > > _______________________________________________ > > Astlinux-devel mailing list > > Ast...@li... > > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > > > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > |
|
From: Lonnie A. <li...@lo...> - 2018-10-22 03:28:01
|
> This is not a problem for standard AstLinux because that does not support DHCP for IPv6 so on a AstLinux LAN dual IPv4/IPv6 is required and DNS comes from IPv4. Indeed, and is why I like the idea of only supporting DHCPv4 on internal interfaces, it just works, and works consistently. > The changes to support that (IPv4 only for standard AstLinux) can be found here.. > https://github.com/dkerr64/astlinux/commit/d20a4f40571258bbbf8725bfde6ec5a4254630ec David, nicely done (I have a few quibbles) but you put your finger on where it would go. Taking a step back, if a dedicated Raspberry Pi was performing DNS for the whole network, wouldn't it be better for AstLinux to just use it as it's static DNS source ? like ... Network -> DNS: ____ In this case all the requests would be coming from AstLinux itself, would you be loosing any interesting statistics on the pi-hole web interface ? More importantly, the pi-hole should offer DNS-TLS upstream (via stubby like we do), I'm not sure if that has been implemented (lots of requests for it by DuckDuckGo'ing it). If you have a simple single LAN, then I can see tweaking the DHCP "option:dns-server" would be a reasonable choice, but when you have multiple LAN's/VLAN's and a single pi-hole it would require adding a bunch of firewall rules for DNS to be accessed across subnets. Not to mention requiring dnsmasq setup tweaks like what David proposed above. I would imagine that pi-hole should support DNS-TLS upstream at some point. I suppose we could optionally have our stubby daemon listen on 0.0.0.0@2853 instead of 127.0.0.1@2853 so a local pi-hole could direct DNS to it's internal gateway at port 2853 ... bypassing dnsmasq's DNS altogether. It would take some testing, assuming pi-hole can forward upstream to both address and port. Sadly the pi-hole project basically requires a full "Linux system" rather than just a single daemon, the later could be easily incorporated into AstLinux directly. Lonnie > On Oct 21, 2018, at 7:57 PM, David Kerr <da...@ke...> wrote: > > Moving this to developer list... > > I decided to go the same route as Michael. I found a old Raspberry Pi lying around and set it up as a pi-hole server. Then I went the route of setting dnsmasq option to replace the DNS server pushed out to DHCP clients. > > As I did this I found a quirk of dnsmasq... > NOTE... following does NOT apply to standard AstLinux, only to my version, but it is worth documenting. > For IPv4 all is fine. The dhcp-option statement in dnsmasq.static seems to replace/overwrite that in dnsmasq.conf. > However for IPv6 it was not as clean cut as that. On iOS devices both the IPv6 address in dnsmasq.conf and that in dnsmasq.static was getting picked up by the IPv6 network stack on iOS devices. This did not appear to be happening on MacOS devices however, very odd. > This is not a problem for standard AstLinux because that does not support DHCP for IPv6 so on a AstLinux LAN dual IPv4/IPv6 is required and DNS comes from IPv4. I have implemented much richer IPv6 support for local networks but this has not been incorporated back into the standard AstLinux (yet?). > > I decided therefore that it would make sense to allow for manual configuration of DNS servers in Astlinux, so that it would be done by the system into dnsmasq.conf and not require setting in dnsmasq.static. I therefore implemented support for... > INTDNS="192.168.1.1" > that can be set in user.conf. > And of course all the other interfaces as well... INT2DNS, INT3DNS, INT4DNS, DMZDNS and EXTDNS > These can be a space or comma separated list of IP addresses, so if you want to push a primary and secondary you can... > INT2DNS="8.8.8.8 8.8.4.4" > > The changes to support that (IPv4 only for standard AstLinux) can be found here.. > https://github.com/dkerr64/astlinux/commit/d20a4f40571258bbbf8725bfde6ec5a4254630ec > The full IPv6 version is in my "develop" branch. > > Up to Lonnie if he wants to pull the IPv4 version into the Astlinux master. > > David > > > > > > > > > > > On Sat, Oct 20, 2018 at 6:00 PM Michael Keuter <li...@mk...> wrote: > > > Am 20.10.2018 um 23:50 schrieb David Kerr <da...@ke...>: > > > > So, been thinking this through. I didn't realize that primary and secondary DNS could in fact be both used in parallel. I had assumed that secondary would be used only if primary failed. If I had a dedicated DNS server for pi-hole this might be okay (raspberry pi on my network maybe?) but I have it running in a VM which is running on Astlinux and it is also my UniFi Controller. I am trying to cover the possibility of that VM not being running, even if for just a few minutes during a reboot. When Astlinux reboots the VM image also restarts but maybe delayed by a minute or two as it goes through its boot. So DNS will take longer to come back up. > > > > I think two choices. I can change DHCP to push out the IP address of pi-hole VM. Or I can put some iptables rules in place to reroute DNS requests that come in to Astlinux (using NAT rules, needs both DNAT and SNAT rules). The benefit of iptables rules is that I could apply it to entire network (even statically assigned clients) if I want and I can quickly revert the entire network to using Astlinux directly for DNS if I need to. But it is a more complex solution than just pushing out a DNS server address. > > > > Pondering over this. Any thoughts? > > > > David > > Hi David, > > I am running a real Raspi 3 Model B+ with Pi hole, and my AstLinux router does DHCP and upstream DNS. > All DHCP devices get only the Pi as DNS server, which does Ad-blocking and then forwards the requests to the AstLinux router (with the config described in my former email). The Raspi is always on. > > > On Fri, Oct 19, 2018 at 5:33 PM Lonnie Abelbeck <li...@lo...> wrote: > > Ahhh, pi-hole .... > > > > Keep in mind that depending on the DNS client, given two DNS server IP's they can be queried in parallel and not just failover as primary/secondary would imply. > > > > Can you configure AstLinux to use the pi-hole IP as the system's static DNS server ? or is there a startup chicken/egg issue ? > > > > Network -> DNS: ____ > > > > Lonnie > > > > > > > > > On Oct 19, 2018, at 4:13 PM, David Kerr <Da...@Ke...> wrote: > > > > > > I'll try dnsmasq.static. As to why... I have installed pi-hole (https://pi-hole.net/) on a VM and want to point clients at it as primary DNS, astlinux as secondary in case it fails. I configured pi-hole to use my astlinux as its primary DNS so all queries will ultimately go through astlinux, after pi-hole has done its thing to filter out the unwanted. No idea if I will keep this but thought I would give it a try and see if the family notices or if anything breaks. > > > > > > David > > > > > > On Fri, Oct 19, 2018 at 4:54 PM Lonnie Abelbeck <li...@lo...> wrote: > > > > > > > > > > On Oct 19, 2018, at 3:44 PM, David Kerr <da...@ke...> wrote: > > > > > > > > I'm probably just overlooking it, but is there a way for me to define the DNS servers that get pushed to clients in DHCP responses? Say I wanted to push out 192.168.1.2 instead (or as well as) 192.168.1.1, how would I do that? > > > > > > No trivial way. Possibly you could override the "dhcp-option=lan,option:dns-server,.." value using /mnt/kd/dnsmasq.static . > > > > > > Which begs the question, Why ? :-) > > > > > > Lonnie > > Michael > > http://www.mksolutions.info > > > > > > _______________________________________________ > Astlinux-users mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr.... > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel |
|
From: David K. <da...@ke...> - 2018-10-22 00:59:14
|
Moving this to developer list... I decided to go the same route as Michael. I found a old Raspberry Pi lying around and set it up as a pi-hole server. Then I went the route of setting dnsmasq option to replace the DNS server pushed out to DHCP clients. As I did this I found a quirk of dnsmasq... NOTE... following does NOT apply to standard AstLinux, only to my version, but it is worth documenting. For IPv4 all is fine. The dhcp-option statement in dnsmasq.static seems to replace/overwrite that in dnsmasq.conf. However for IPv6 it was not as clean cut as that. On iOS devices both the IPv6 address in dnsmasq.conf and that in dnsmasq.static was getting picked up by the IPv6 network stack on iOS devices. This did not appear to be happening on MacOS devices however, very odd. This is not a problem for standard AstLinux because that does not support DHCP for IPv6 so on a AstLinux LAN dual IPv4/IPv6 is required and DNS comes from IPv4. I have implemented much richer IPv6 support for local networks but this has not been incorporated back into the standard AstLinux (yet?). I decided therefore that it would make sense to allow for manual configuration of DNS servers in Astlinux, so that it would be done by the system into dnsmasq.conf and not require setting in dnsmasq.static. I therefore implemented support for... INTDNS="192.168.1.1" that can be set in user.conf. And of course all the other interfaces as well... INT2DNS, INT3DNS, INT4DNS, DMZDNS and EXTDNS These can be a space or comma separated list of IP addresses, so if you want to push a primary and secondary you can... INT2DNS="8.8.8.8 8.8.4.4" The changes to support that (IPv4 only for standard AstLinux) can be found here.. https://github.com/dkerr64/astlinux/commit/d20a4f40571258bbbf8725bfde6ec5a4254630ec The full IPv6 version is in my "develop" branch. Up to Lonnie if he wants to pull the IPv4 version into the Astlinux master. David On Sat, Oct 20, 2018 at 6:00 PM Michael Keuter <li...@mk...> wrote: > > > Am 20.10.2018 um 23:50 schrieb David Kerr <da...@ke...>: > > > > So, been thinking this through. I didn't realize that primary and > secondary DNS could in fact be both used in parallel. I had assumed that > secondary would be used only if primary failed. If I had a dedicated DNS > server for pi-hole this might be okay (raspberry pi on my network maybe?) > but I have it running in a VM which is running on Astlinux and it is also > my UniFi Controller. I am trying to cover the possibility of that VM not > being running, even if for just a few minutes during a reboot. When > Astlinux reboots the VM image also restarts but maybe delayed by a minute > or two as it goes through its boot. So DNS will take longer to come back > up. > > > > I think two choices. I can change DHCP to push out the IP address of > pi-hole VM. Or I can put some iptables rules in place to reroute DNS > requests that come in to Astlinux (using NAT rules, needs both DNAT and > SNAT rules). The benefit of iptables rules is that I could apply it to > entire network (even statically assigned clients) if I want and I can > quickly revert the entire network to using Astlinux directly for DNS if I > need to. But it is a more complex solution than just pushing out a DNS > server address. > > > > Pondering over this. Any thoughts? > > > > David > > Hi David, > > I am running a real Raspi 3 Model B+ with Pi hole, and my AstLinux router > does DHCP and upstream DNS. > All DHCP devices get only the Pi as DNS server, which does Ad-blocking and > then forwards the requests to the AstLinux router (with the config > described in my former email). The Raspi is always on. > > > On Fri, Oct 19, 2018 at 5:33 PM Lonnie Abelbeck < > li...@lo...> wrote: > > Ahhh, pi-hole .... > > > > Keep in mind that depending on the DNS client, given two DNS server IP's > they can be queried in parallel and not just failover as primary/secondary > would imply. > > > > Can you configure AstLinux to use the pi-hole IP as the system's static > DNS server ? or is there a startup chicken/egg issue ? > > > > Network -> DNS: ____ > > > > Lonnie > > > > > > > > > On Oct 19, 2018, at 4:13 PM, David Kerr <Da...@Ke...> wrote: > > > > > > I'll try dnsmasq.static. As to why... I have installed pi-hole ( > https://pi-hole.net/) on a VM and want to point clients at it as primary > DNS, astlinux as secondary in case it fails. I configured pi-hole to use > my astlinux as its primary DNS so all queries will ultimately go through > astlinux, after pi-hole has done its thing to filter out the unwanted. No > idea if I will keep this but thought I would give it a try and see if the > family notices or if anything breaks. > > > > > > David > > > > > > On Fri, Oct 19, 2018 at 4:54 PM Lonnie Abelbeck < > li...@lo...> wrote: > > > > > > > > > > On Oct 19, 2018, at 3:44 PM, David Kerr <da...@ke...> wrote: > > > > > > > > I'm probably just overlooking it, but is there a way for me to > define the DNS servers that get pushed to clients in DHCP responses? Say I > wanted to push out 192.168.1.2 instead (or as well as) 192.168.1.1, how > would I do that? > > > > > > No trivial way. Possibly you could override the > "dhcp-option=lan,option:dns-server,.." value using /mnt/kd/dnsmasq.static . > > > > > > Which begs the question, Why ? :-) > > > > > > Lonnie > > Michael > > http://www.mksolutions.info > > > > > > _______________________________________________ > Astlinux-users mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > Donations to support AstLinux are graciously accepted via PayPal to > pa...@kr.... > |
|
From: Lonnie A. <li...@lo...> - 2018-10-12 17:53:59
|
Added the checkbox option: https://github.com/astlinux-project/astlinux/commit/5b8cc833638bc8aacb565b3b97bd1b2edf9fdb77 Thanks for the feedback. Lonnie > On Oct 12, 2018, at 3:27 AM, Michael Keuter <li...@mk...> wrote: > > >> Am 12.10.2018 um 06:04 schrieb Michael Knill <mic...@ip...>: >> >> I like the checkbox option. Always better to give an option even if it is rarely changed I say. >> >> Regards >> Michael Knill > > +1 > > That would be more consistent wih our other firewall options. I would vote for NOT enabled by default. > Those few people who would need that, could enabled this by themselves. > >> On 12/10/18, 1:41 pm, "Lonnie Abelbeck" <li...@lo...> wrote: >> >> Hi Dev minded, >> >> >> A few days back, Michael Knill authored a "[Astlinux-users] Access to VPN endpoint from external" topic. >> >> In the discussion I offered a allow_wireguard_openvpn() function in /mnt/kd/arno-iptables-firewall/custom-rules to allow WireGuard and OpenVPN to forward traffic. >> >> That got me thinking, perhaps we should have a Firewall sub-tab option to make this a standard feature ... then more thinking considering that WireGuard's config limits only AllowedIP's, I can't see any reason why WireGuard and OpenVPN can't safely forward traffic between themselves since WireGuard has allow rules of it's own ... meaning no user option is really necessary. >> >> Proposal, when both Wireguard and OpenVPN Server-or-Client are enabled, then allow the firewall to forward packets between the two VPN types. >> >> Other than testing for both VPN types, the AIF code boils down to simply: >> -- >> IF_TRUSTS="$IF_TRUSTS${IF_TRUSTS:+|}wg+ tun+" >> -- >> >> This looks safe to be enabled by default, but for documentation purposes we could add a rc.conf variable and make it an option: >> >> >> ___ Allow WireGuard VPN tunnel(s) to OpenVPN tunnel(s) >> >> >> Should we add this as a Firewall feature ? Of so, should be automatically enabled when both WireGuard and OpenVPN Server-or-Client are enabled, or add a rc.conf firewall option with a web interface checkbox ? >> >> >> BTW, until WireGuard is ubiquitous, mixing both WireGuard and OpenVPN on the same box will be common. >> >> Lonnie > > > Michael > > http://www.mksolutions.info > > > > > > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel |
|
From: Michael K. <li...@mk...> - 2018-10-12 08:27:22
|
> Am 12.10.2018 um 06:04 schrieb Michael Knill <mic...@ip...>:
>
> I like the checkbox option. Always better to give an option even if it is rarely changed I say.
>
> Regards
> Michael Knill
+1
That would be more consistent wih our other firewall options. I would vote for NOT enabled by default.
Those few people who would need that, could enabled this by themselves.
> On 12/10/18, 1:41 pm, "Lonnie Abelbeck" <li...@lo...> wrote:
>
> Hi Dev minded,
>
>
> A few days back, Michael Knill authored a "[Astlinux-users] Access to VPN endpoint from external" topic.
>
> In the discussion I offered a allow_wireguard_openvpn() function in /mnt/kd/arno-iptables-firewall/custom-rules to allow WireGuard and OpenVPN to forward traffic.
>
> That got me thinking, perhaps we should have a Firewall sub-tab option to make this a standard feature ... then more thinking considering that WireGuard's config limits only AllowedIP's, I can't see any reason why WireGuard and OpenVPN can't safely forward traffic between themselves since WireGuard has allow rules of it's own ... meaning no user option is really necessary.
>
> Proposal, when both Wireguard and OpenVPN Server-or-Client are enabled, then allow the firewall to forward packets between the two VPN types.
>
> Other than testing for both VPN types, the AIF code boils down to simply:
> --
> IF_TRUSTS="$IF_TRUSTS${IF_TRUSTS:+|}wg+ tun+"
> --
>
> This looks safe to be enabled by default, but for documentation purposes we could add a rc.conf variable and make it an option:
>
>
> ___ Allow WireGuard VPN tunnel(s) to OpenVPN tunnel(s)
>
>
> Should we add this as a Firewall feature ? Of so, should be automatically enabled when both WireGuard and OpenVPN Server-or-Client are enabled, or add a rc.conf firewall option with a web interface checkbox ?
>
>
> BTW, until WireGuard is ubiquitous, mixing both WireGuard and OpenVPN on the same box will be common.
>
> Lonnie
Michael
http://www.mksolutions.info
|
|
From: Michael K. <mic...@ip...> - 2018-10-12 04:04:54
|
I like the checkbox option. Always better to give an option even if it is rarely changed I say.
Regards
Michael Knill
On 12/10/18, 1:41 pm, "Lonnie Abelbeck" <li...@lo...> wrote:
Hi Dev minded,
A few days back, Michael Knill authored a "[Astlinux-users] Access to VPN endpoint from external" topic.
In the discussion I offered a allow_wireguard_openvpn() function in /mnt/kd/arno-iptables-firewall/custom-rules to allow WireGuard and OpenVPN to forward traffic.
That got me thinking, perhaps we should have a Firewall sub-tab option to make this a standard feature ... then more thinking considering that WireGuard's config limits only AllowedIP's, I can't see any reason why WireGuard and OpenVPN can't safely forward traffic between themselves since WireGuard has allow rules of it's own ... meaning no user option is really necessary.
Proposal, when both Wireguard and OpenVPN Server-or-Client are enabled, then allow the firewall to forward packets between the two VPN types.
Other than testing for both VPN types, the AIF code boils down to simply:
--
IF_TRUSTS="$IF_TRUSTS${IF_TRUSTS:+|}wg+ tun+"
--
This looks safe to be enabled by default, but for documentation purposes we could add a rc.conf variable and make it an option:
___ Allow WireGuard VPN tunnel(s) to OpenVPN tunnel(s)
Should we add this as a Firewall feature ? Of so, should be automatically enabled when both WireGuard and OpenVPN Server-or-Client are enabled, or add a rc.conf firewall option with a web interface checkbox ?
BTW, until WireGuard is ubiquitous, mixing both WireGuard and OpenVPN on the same box will be common.
Lonnie
_______________________________________________
Astlinux-devel mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-devel
|
|
From: Lonnie A. <li...@lo...> - 2018-10-12 02:41:33
|
Hi Dev minded,
A few days back, Michael Knill authored a "[Astlinux-users] Access to VPN endpoint from external" topic.
In the discussion I offered a allow_wireguard_openvpn() function in /mnt/kd/arno-iptables-firewall/custom-rules to allow WireGuard and OpenVPN to forward traffic.
That got me thinking, perhaps we should have a Firewall sub-tab option to make this a standard feature ... then more thinking considering that WireGuard's config limits only AllowedIP's, I can't see any reason why WireGuard and OpenVPN can't safely forward traffic between themselves since WireGuard has allow rules of it's own ... meaning no user option is really necessary.
Proposal, when both Wireguard and OpenVPN Server-or-Client are enabled, then allow the firewall to forward packets between the two VPN types.
Other than testing for both VPN types, the AIF code boils down to simply:
--
IF_TRUSTS="$IF_TRUSTS${IF_TRUSTS:+|}wg+ tun+"
--
This looks safe to be enabled by default, but for documentation purposes we could add a rc.conf variable and make it an option:
___ Allow WireGuard VPN tunnel(s) to OpenVPN tunnel(s)
Should we add this as a Firewall feature ? Of so, should be automatically enabled when both WireGuard and OpenVPN Server-or-Client are enabled, or add a rc.conf firewall option with a web interface checkbox ?
BTW, until WireGuard is ubiquitous, mixing both WireGuard and OpenVPN on the same box will be common.
Lonnie
|
|
From: Michael K. <mic...@ip...> - 2018-10-11 20:30:20
|
Awesome thanks guys. I figured you already had it sorted.
Regards
Michael Knill
On 12/10/18, 2:26 am, "Lonnie Abelbeck" <li...@lo...> wrote:
> On Oct 11, 2018, at 3:32 AM, Michael Keuter <li...@mk...> wrote:
>
>
>> Am 11.10.2018 um 06:31 schrieb Michael Knill <mic...@ip...>:
>>
>> I noticed that the ‘comp-lzo’ and ‘ns-cert-type’ options are now deprecated.
>> Just wondering if we could get them changed in the next release as they are disappearing soon.
>>
>> Regards
>> Michael Knill
>
> Look at the latest (webinterface) commits. 'ns-cert-type' was changed to 'remote-cert-tls', and compression will default to 'off' in the next version (we still need to support 2.3.x clients!).
>
> For reference:
> https://community.openvpn.net/openvpn/wiki/DeprecatedOptions
>
> Michael
+1
Michael Keuter and I have been pondering this subject for the past week, prompted by the latest iOS OpenVPN Connect. In this case the exported .ovpn file, created by the AstLinux OpenVPN Server config was containing ‘comp-lzo’ and ‘ns-cert-type’ and generated warnings. We have to be careful for our .ovpn files to work with older OpenVPN versions (2.3.x).
More interesting is the "comp-lzo" setting, long story short we recommend users to move to disable compression for new OpenVPN setups. This is why ...
1) The VORACLE attack on OpenVPN requires compression to be enabled. While this is a difficult to exploit attack, the fact compression is a requirement is somewhat troubling.
Ref: https://nordvpn.com/blog/voracle-attack/
2) The first release of OpenVPN was in 2001, 17 years ago, at that time 0.5 Mbps internet speeds were top-of-the-line, and non-encrypted (compressible) DNS/HTTP/FTP were the primary transports. At that time compression in OpenVPN made some sense, as in "why not". Fast forward to today, most traffic is encrypted (non-compressible), as such enabling compression in OpenVPN adds 1-byte to every frame, and for mobile devices the extra computation may use extra battery resources.
3) OpenVPN's compression configuration has always been a mess, such that "comp-lzo no" is not the same as "comp-lzo" which is not the same as not-defining "comp-lzo" at all. Adding a new "compress" option multiplies the mess.
Ref: https://community.openvpn.net/openvpn/ticket/952
Summary, we recommend users to move to disable compression for new OpenVPN setups. Starting with AstLinux 1.3.5 "Compression: [Off]" will be the default, but "Compression: [LZO]" will be supported for backward compatibility in existing configurations.
Lonnie
_______________________________________________
Astlinux-devel mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-devel
|
|
From: Lonnie A. <li...@lo...> - 2018-10-11 15:26:04
|
> On Oct 11, 2018, at 3:32 AM, Michael Keuter <li...@mk...> wrote: > > >> Am 11.10.2018 um 06:31 schrieb Michael Knill <mic...@ip...>: >> >> I noticed that the ‘comp-lzo’ and ‘ns-cert-type’ options are now deprecated. >> Just wondering if we could get them changed in the next release as they are disappearing soon. >> >> Regards >> Michael Knill > > Look at the latest (webinterface) commits. 'ns-cert-type' was changed to 'remote-cert-tls', and compression will default to 'off' in the next version (we still need to support 2.3.x clients!). > > For reference: > https://community.openvpn.net/openvpn/wiki/DeprecatedOptions > > Michael +1 Michael Keuter and I have been pondering this subject for the past week, prompted by the latest iOS OpenVPN Connect. In this case the exported .ovpn file, created by the AstLinux OpenVPN Server config was containing ‘comp-lzo’ and ‘ns-cert-type’ and generated warnings. We have to be careful for our .ovpn files to work with older OpenVPN versions (2.3.x). More interesting is the "comp-lzo" setting, long story short we recommend users to move to disable compression for new OpenVPN setups. This is why ... 1) The VORACLE attack on OpenVPN requires compression to be enabled. While this is a difficult to exploit attack, the fact compression is a requirement is somewhat troubling. Ref: https://nordvpn.com/blog/voracle-attack/ 2) The first release of OpenVPN was in 2001, 17 years ago, at that time 0.5 Mbps internet speeds were top-of-the-line, and non-encrypted (compressible) DNS/HTTP/FTP were the primary transports. At that time compression in OpenVPN made some sense, as in "why not". Fast forward to today, most traffic is encrypted (non-compressible), as such enabling compression in OpenVPN adds 1-byte to every frame, and for mobile devices the extra computation may use extra battery resources. 3) OpenVPN's compression configuration has always been a mess, such that "comp-lzo no" is not the same as "comp-lzo" which is not the same as not-defining "comp-lzo" at all. Adding a new "compress" option multiplies the mess. Ref: https://community.openvpn.net/openvpn/ticket/952 Summary, we recommend users to move to disable compression for new OpenVPN setups. Starting with AstLinux 1.3.5 "Compression: [Off]" will be the default, but "Compression: [LZO]" will be supported for backward compatibility in existing configurations. Lonnie |
|
From: Michael K. <li...@mk...> - 2018-10-11 08:33:02
|
> Am 11.10.2018 um 06:31 schrieb Michael Knill <mic...@ip...>: > > I noticed that the ‘comp-lzo’ and ‘ns-cert-type’ options are now deprecated. > Just wondering if we could get them changed in the next release as they are disappearing soon. > > Regards > Michael Knill Look at the latest (webinterface) commits. 'ns-cert-type' was changed to 'remote-cert-tls', and compression will default to 'off' in the next version (we still need to support 2.3.x clients!). For reference: https://community.openvpn.net/openvpn/wiki/DeprecatedOptions Michael http://www.mksolutions.info |
|
From: Michael K. <mic...@ip...> - 2018-10-11 04:31:39
|
I noticed that the ‘comp-lzo’ and ‘ns-cert-type’ options are now deprecated. Just wondering if we could get them changed in the next release as they are disappearing soon. Regards Michael Knill |
28 messages has been excluded from this view by a project administrator.
