Post by: allebone on May 20, 2021, 09:52:28 pm
I have an outbound NAT rewrite rule that captures devices that ignore DNS and forces them to go via my internal pihole. For example if a client such as my Roku TV attempts to connect to 8.8.8.8 on port 53 this is captured and sent correctly internal to my pihole.
See figure 1: (https://i.imgur.com/hbUKaZm.png)
My issue is the logs do not tell me what ip this device attempted to access externally. I would like to know how to capture this information. Eg: I can see that 192.168.2.51 tried to access an IP on port 53 as the rewrite rule kicked in. But would like to know what that IP is (ie was it 8.8.8.8 or some other Ip etc).
How can I know this?
Here is the rewrite rule: (https://i.imgur.com/QrO1pvI.png)
Here is the LAN FW rule: (https://i.imgur.com/VeZSe3S.png)
Thanks in advance :)
Pete
Post by: allebone on May 21, 2021, 02:17:40 pm
Kind regards
Pete
Post by: astuckey on May 24, 2021, 05:13:41 pm
Post by: allebone on May 24, 2021, 07:36:47 pm
My desire (and why I set it up like this) is to silently capture devices on the network that try use other dns servers and reroute them to my internal dns server without them knowing (ie blocking them).
This is working as intended but I cant see what external dns servers they are trying to query.
Sorry if you explained how to do this. I didnt fully understand your comment.
Pete
Post by: FullyBorked on May 26, 2021, 06:09:13 pm
I must be honest. I also dont fully understand what you are telling me.
My desire (and why I set it up like this) is to silently capture devices on the network that try use other dns servers and reroute them to my internal dns server without them knowing (ie blocking them).
This is working as intended but I cant see what external dns servers they are trying to query.
Sorry if you explained how to do this. I didnt fully understand your comment.
Pete
I'm doing the same NAT redirect to my DNS server. I can confirm as well even with logging enabled on that NAT rule I do not see logs for the rewrite either. At least not in the live view.
Also check this post out https://forum.opnsense.org/index.php?topic=20149.0
Post by: Meditux on May 26, 2021, 06:29:30 pm
Greeting Meditux
Post by: FullyBorked on May 26, 2021, 06:35:36 pm
Hi guys,
I do the same, however the redirects show up in the livelog for me.
Greeting Meditux
I can see the resulting rewrite as well but I think what the OP looking for is an entry like
Code: [Select]
NAT - <Orig> Dest 8.8.8.8:53 > <New> Dest 192.168.1.1:53 to see the original destination.
Post by: allebone on May 26, 2021, 10:44:22 pm
Post by: allebone on June 24, 2021, 09:02:19 pm
Post by: Greelan on June 24, 2021, 09:14:26 pm
A workaround perhaps is to have a specific firewall rule for the source IPs that are being rewritten on the DNS port and log that.
Post by: allebone on June 24, 2021, 09:20:51 pm
Post by: Greelan on June 24, 2021, 09:26:19 pm
Post by: allebone on June 24, 2021, 09:28:14 pm
Post by: Greelan on June 24, 2021, 09:30:16 pm
You do want to pass the packets on the internal interface, otherwise they will be dropped by OPNsense and there will be no DNS resolution, with or without a NAT rule
Post by: allebone on June 24, 2021, 09:33:52 pm
Post by: Greelan on June 24, 2021, 09:37:40 pm
Post by: allebone on June 24, 2021, 09:41:15 pm
The only DNS rule I have allowed is as such:
IPv4 TCP/UDP (Lan clients Alias) * 192.168.2.22 53 (DNS) * * lredirectrule DNS53Pihole
So for example a client would have 8.8.8.8 as its DNS server. in this case the packet is rewritten to go to 192.168.2.22.
Once its rewritten, the only DNS rule is the one above. Logging has no effect as its too late.
What rule are you proposing I add above this rule in order to log the client trying to access 8.8.8.8 on port 53, and is it pass, block, or reject?
Post by: Greelan on June 24, 2021, 09:42:48 pm
Post by: allebone on June 24, 2021, 09:43:46 pm
Post by: Greelan on June 24, 2021, 09:55:54 pm
Post by: allebone on June 24, 2021, 09:58:21 pm
Post by: allebone on June 24, 2021, 10:11:11 pm
IPv4 TCP/UDP * * * 53 (DNS) * *
It had no effect and this makes me think that the nat rewrite rules are processed before the firewall rule on that interface. Otherwise it should have been allowed out to 8.8.8.8.
The only logs I see are as example:
lan Jun 24 16:04:02 192.168.2.2:61891 192.168.2.22:53 udp nat rule
lan Jun 24 16:04:02 192.168.2.16:54209 192.168.2.22:53 udp
lan Jun 24 16:04:02 192.168.2.2:25605 192.168.2.22:53 udp nat rule
lan Jun 24 16:04:02 192.168.2.16:54208 192.168.2.22:53 udp
Post by: allebone on June 24, 2021, 10:16:55 pm
https://forum.opnsense.org/index.php?topic=11233.0
Post by: allebone on June 24, 2021, 10:20:10 pm
Post by: Greelan on June 24, 2021, 10:20:45 pm
Post by: allebone on June 24, 2021, 10:24:31 pm
(snipped)
# NAT Redirects
no nat proto carp all
no rdr proto carp all
# [prio: 100]
nat log on em1 inet from !$AllowQueryDNSServers to 192.168.2.22/32 port 53 -> (em1:0) port 1024:65535 # DNSOutRewrite
nat log on em1 inet from !$AllowQueryDNSServers to 192.168.2.22/32 port 853 -> (em1:0) port 1024:65535 # DNSOutRewrite853
nat on pppoe0 inet from (wireguard:network) to any -> (pppoe0:0) port 1024:65535 # Allow WG Clients to NAT
# [prio: 200]
Post by: Greelan on June 24, 2021, 10:27:44 pm
Post by: allebone on June 24, 2021, 10:37:42 pm
Post by: allebone on June 24, 2021, 10:39:44 pm
Post by: Greelan on June 24, 2021, 10:50:28 pm
So the logging is working as expected at the moment
Post by: Greelan on June 24, 2021, 11:23:39 pm
I haven’t implemented this myself yet but have disabled rules set up ready for testing when I get the chance. Will post them later FYI
Post by: allebone on June 24, 2021, 11:38:13 pm
Post by: Greelan on June 25, 2021, 02:40:10 am
Attached are the draft rules I have set up (can't test until I don't have people on the network, in case DNS breaks!). Note that ALL_LOCAL is an interface group that includes all of my local networks/VLANs.
First is a port forward rule (destination NAT) that redirects to the pi-hole any DNS request from a local host that is not the pi-hole and that is not already destined for the pi-hole.
Second are outbound NAT rules (source NAT) to fix any source address errors as a result of the redirection.
Finally, my filter rules. The second rule in this screenshot is automatically created by the port forward. The first rule is to ensure that the pi-hole itself is able to access external DNS servers.
If logging is enabled on the port forward, does that not give the original destination IP in the logs? If not, then I agree that this functionality probably doesn't exist currently.
Post by: allebone on June 25, 2021, 02:15:31 pm
Post by: allebone on June 25, 2021, 02:19:35 pm
cat /tmp/rules.debug
Ie the Nat rewrite rules listed first in that file. Since its done first, anything that happens after is happening after the rewrite and so logging later on is not going to help. There would need to be a logging mechanism that processes before the (current) very first rule processed which does not exist :(
Post by: Greelan on June 26, 2021, 02:22:21 am
On the processing order I actually don’t agree that the order in rules.debug is the order they are applied. My understanding is that destination NAT occurs first, then the filter rules, and then source NAT. The issue here is simply that OPNsense does not log the original destination IP in the port forward logs. Presumably it could with a code change, because OPNsense has the information when it applies the port forward.
Post by: Greelan on June 26, 2021, 02:27:23 am
Post by: Greelan on June 26, 2021, 04:35:05 am
Edit: the tag does actually work. It just had a syntax error when I originally tried it (for some reason I can’t figure out)
Post by: KeyHand on June 27, 2021, 11:06:33 am
It's been established (https://forum.opnsense.org/index.php?topic=11233.msg50896#msg50896) (and confirmed by franco (https://forum.opnsense.org/index.php?topic=11233.msg50900#msg50900)) that OPNsense processes NAT and firewall rules in the same order as pfSense. I.e. the pfSense documentation (https://docs.netgate.com/pfsense/en/latest/nat/process-order.html) on this matter is relevant in OPNsense and, most importantly, NAT occurs before firewall rules. Meaning that address translation occurs first and any subsequent firewall rules (and associated logging) occurs on the translated address. So there is no opportunity to log any details about the pre-NAT'ed traffic, including the original destination address.
That's not to say obtaining this information is impossible. Searching for prior art on the subject, I came across these projects
- pfnattrack - Logging NAT Translations on PF firewalls (https://github.com/italovalcy/pfnattrack)
- pf_poc (https://github.com/monsterxx03/pf_poc)
- pf_nat_log_freebsd_10.2r.patch (https://gist.github.com/raitech/4150c8767d8f1f8642ccd9d44c4c57c6)
The above is based purely on my limited understanding of OPNsense and FreeBSD internals gained from poking around the source. I'd really appreciate if someone more knowledgeable could let me know if I'm on the right track. Better yet, if would be great if one of the developers could chime in on the feasibility of my speculative implementation.
Post by: Greelan on June 27, 2021, 11:22:54 am
The pfSense docs seem a little inconsistent on the rule processing order. The first section refers to outbound NAT being processed first, but then the examples given show it near the end. The latter makes more sense to me, and is also consistent with the fact that a local tag set on my port forward is picked up by my outbound NAT rule. If the outbound NAT rule was processed first, that presumably could not happen.
Post by: KeyHand on June 27, 2021, 01:26:40 pm
Post by: Greelan on June 27, 2021, 01:30:11 pm
Post by: allebone on June 28, 2021, 02:29:15 pm
Only issue is that the problem is misdescribed - it is not outbound NAT that is the issue, it is the port forward. Outbound NAT is source NAT, whereas the issue of concern is destination NAT (ie port forward)
I raised the issue to the best of my ability at the time on github. A lot more info has come through on this thread since then. Just trying my best man :)
Post by: Greelan on June 28, 2021, 02:31:29 pm
Post by: allebone on June 28, 2021, 02:37:29 pm
Post by: franco on June 30, 2021, 09:54:53 am
Pete and me exchanged a few messages on GitHub. Basically, NAT logging is possible, but has some caveats...
Nevertheless, two patches can help with this in the future:
https://github.com/opnsense/core/commit/3eb235f25
We want to be able to search for "rdr" (port forward) or "nat" (outbound NAT) logs directly.
https://github.com/opnsense/src/commit/bdb244c37
The logging already works for builtin "pass" NAT rules, but with an associated firewall rule the logging is muted. Furthermore, while post-NAT logging makes sense for the associated firewall rule the NAT logging should probably be done pre-NAT as it would match the packet.
You can see the result in action here:
https://github.com/opnsense/core/issues/5005#issuecomment-871176383
I think that addresses all problems discussed here?
Cheers,
Franco
Post by: allebone on June 30, 2021, 04:17:21 pm
I posted a screenshot anyone else in this thread can now view on:
https://github.com/opnsense/core/issues/5005
That shows how logging now looks with this patch. It is working for me and I will continue to monitor it for any undesirable effects but so far clients accessing port 53 are rerouted to my internal DNS and now logged correctly so it appears everything is working as desired and this provides logging as desired so it looks really good to me :)
Kind regards
Pete
Post by: cookiemonster on June 30, 2021, 04:40:42 pm
My question is I am on 21.1.6 . Can I use the patches on it or do I need to upgrade to 21.1.7 first if I want to try the patch?
Post by: allebone on June 30, 2021, 04:56:44 pm
You would essentially be temporarily on a dev version and only able to update once the version catches up to where the patch is, or you will lose the patch.
A reboot is required when changing. Basically I will have to now wait until the community version catches up to the version I am using, or update and lose the patch and then have to wait until the patch makes it into the community version. It apparently wont make next version so I will have to decide to wait for 2 new versions to be released where the patch will likely make it in or instead update as normal and be without it for 2 versions until we catch up to when it will make it into the community version.
One thing I would say is being split between packages like this (because only one module is updated by running the command on github) means you are not on a snapshot of an official release, so obviously its going to be unsupported and not fit for business use etc. At home you can feel free to make the call. Depends how adventurous you are. I kind of feel its fine personally, so will probs just leave it and update only again in 2 versions time (2 months?).
P
Post by: cookiemonster on June 30, 2021, 05:23:06 pm
Post by: franco on July 01, 2021, 09:55:10 am
It's not overly problematic. The kernel needs to be switched, but all other parts are untouched / allowed to be updated.
The snapshot kernel itself is basically 21.7-RC1 with the added fix on top. Deviation from 21.1x is minimal except for some driver updates.
# opnsense-update -zbkr 21.7.r_1
# opnsense-update -Lk
# opnsense-shell reboot
The above will install the newer kernel and lock it to prevent minor updates from overwriting it. You can always unlock the kernel from the GUI and reinstall the official release one or issue:
# opnsense-update -Uk
# opnsense-update -k
# opnsense-shell reboot
Cheers,
Franco
Post by: cookiemonster on July 01, 2021, 10:20:51 pm
I'll do that once I've settled a few kinks I have so I don't make changes whilst resolving.