Please, correct me if I’m wrong. In the picture, despite having DNS servers pointing to ipfire and internal DNS server, the traceroute addon is pointing my red0 to 8.8.8.8 (dns.google)?!
Don’t understand!
Regards
G7 0P could you take a larger screenshot?
Are you redirecting DNS traffic to 192.168.1.1 ?
Could you click on the button Check DNS Servers
sure,
yes to internal DNS - portforward from host Win11 to ipfire green0 and red0 Dns’s
Correction, not red0 → gateway instead
I also disable safe DNS in browsers so it doesn’t redirect doh:443 on them (hopefully)
I have the upstream DNS set to TLS
Do you have any other Firewall rules for 8.8.8.8?
I think the traceroute will always go to 8.8.8.8 unless you somehow route all the traffic…
I asked once here but never got an answer how to do it properly using firewall rules,. for some reason , I thought Static Routes would do it.
DHCP is disabled only this win11 host @ the moment.
It’s configured like the tutorial help.
I Created these firewall rules 30min ago (Block list I was testing settup the host group and it’s the 8844 and 1111:
I have the upstream DNS set to TLS
If I enable TLS I can’t point DNS’s to internal green0 and gateway which works fine even if recursor from ipfire is disabled.
And yes ICMP request and ICMP time exceed it’s flooding 8.8.8.8 it looks like some UPnp look-up service I can’t find, hopefully not malicious or orchestrated
But I don’t see the same traffic getting in green0 from the host. have to wait untill I have some insight so
I’ll have to work on this and understand why it goes 8.8.8.8 despite all blocks
I also added the firewall ICMP block rules but it doesn’t stop.
I know exactly how to do it on an inexpensive router
but since 2021 I am still waiting for a reply on how to do it on IPFire I have to just take an uninformed guess:
Have you set the correct dns in the dhcp settings?
At my informnations windows not use 8.8.8.8 except it is manually set or configured via dhcp.
If no dns is configured microsoft use a different default dns operated by microsoft.
Maybee chrome try to use 8.8.8.8
I have simply blocked (reject not drop) all port53 access between green/blue and red
So only the IPFire DNS can used.
Also it looks that you have configured 10.10.10.1 as upstream dns which is a bad idea. (loop to itself if your IPFire is 10.10.10.1)
My guess is this is set as part of the addon.
Not sure how you would change it…
Would look at the addon configuration…
It is probably set this way to have a reliable DNS server to use.
The traceroute and also mtr addon should use the configured nameserver from /etc/resolv.conf ipfire default is 127.0.0.1
Have you changes this?
Also mtr not show the nameserver in this line. It is the target to trace.
for me it looks like you have run
mtr 8.8.8.8
True
$tmux send-keys -t 0 'iftop' enter C-1
$tmux send-keys -t 1 'mtr 8.8.8.8' enter C-1
$tmux send-keys -t 2 'bwm-ng' enter C-1
That’s part of the script I built from the example in /usr/bin/ file name mux after chmod +x file.
The statup program mtr (my trace route) it’s calling 8888.
I haven’t enabled DHCP since coreupdate 183 last week, wanted to make sure the foreground and background are using the right IP’s parameters.
I’m not quite sure of the implications of these. If I use the red0 upstreams it does looks forward for a public corresponding ip address. I don’t see any strange loops in ipfire, and doesn’t look in the net for the dns 10.10.10.1. It was the way I found to make the forward Dnat on 53 to work (redirect all dns to the ipfire DNS server inbuilt mechanism). Perhaps wrong