Internal DNS used by lan logging public ip

[gixnex]

Hi all,

I'm hoping someone can help me troubleshoot a strange behavior I'm encountering with my network setup. Here's a summary of my current configuration:

LAN interface: 192.168.2.0/24

WAN interface: 192.168.1.0/24

ISP router: 192.168.1.254

Internal DNS server: 192.168.1.5

Any VM connected to the LAN network (192.168.2.0/24) and configured to use 192.168.1.5 (the internal DNS server) for DNS resolution is treated as if the request is coming from my router's public IP, not the actual VM.

I tried setting a NAT exemption rule (to avoid NAT for traffic from LAN to WAN targeting 192.168.1.5), but it doesn't work—the DNS requests don't seem to get through unless NAT is enabled.

What's confusing me is:

Why does traffic from LAN to a WAN-side internal DNS result in NAT behavior that shows the public IP as the source?

Would moving the DNS server to the LAN network avoid this, or is there a cleaner solution?

Any insight would be appreciated. Thanks in advance!

[meyergru]

Obviously, you have a router-behind-router scenacrio, as indicated by your "WAN" having a non-routeable RFC1918 IP.

With these scenarios, you have but two choices to make them work:

a. You can set up a route on your ISP router to your internal LAN network. This is often infeasible.
b. You can set up your OpnSense to NAT outbound requests on its WAN interface. It seems you went that route.

Thus, all outbound connections will pass NAT, this includes requests for 192.168.1.0/24, because this is your WAN network. Presumably, your ISP router has 192.168.1.1 and your OpnSense has 192.168.1.5.

You could either help that by excluding 192.168.1.0/24 from NAT or, more transparently, by using 192.168.2.1 as your internal DNS server. I usually do it like that, anyway. Or, preferably, avoid router-behind-router scenarios altogether, if at all possible.

[EricPerl]

Also, I suspect outbound traffic to the current DNS router is bouncing off of the ISP router, unless reply-to has been disabled (FW advanced settings).

If you disable NAT on OPN, even if it's just for the ISP router LAN only, you'll have to route reply traffic back to OPN WAN, which is essentially choice a.
You might as well disable NAT completely at that point... Most of the work involved ends up being on the edge router (ISP router).

[gixnex]

Obviously, you have a router-behind-router scenacrio, as indicated by your "WAN" having a non-routeable RFC1918 IP.

With these scenarios, you have but two choices to make them work:

a. You can set up a route on your ISP router to your internal LAN network. This is often infeasible.
b. You can set up your OpnSense to NAT outbound requests on its WAN interface. It seems you went that route.

Thus, all outbound connections will pass NAT, this includes requests for 192.168.1.0/24, because this is your WAN network. Presumably, your ISP router has 192.168.1.1 and your OpnSense has 192.168.1.5.

You could either help that by excluding 192.168.1.0/24 from NAT or, more transparently, by using 192.168.2.1 as your internal DNS server. I usually do it like that, anyway. Or, preferably, avoid router-behind-router scenarios altogether, if at all possible.

Thanks Meyergru, I think that moving from 192.168.1.5 to 192.168.2.5 is going to be the cleanest solution. However, I was wondering that in my case if my "WAN" can behave like another LAN using 192.168.1.254 as gateway (ISP router ip), because anything in 192.168.1.0/24 network is going to have "issues" like this one.

Just to clarify, 192.168.1.5 is a VM with Bind installed, used as DNS cache server not the OPNsense server(192.168.1.2 for WAN and 192.168.2.1 for LAN).

[gixnex]

Also, I suspect outbound traffic to the current DNS router is bouncing off of the ISP router, unless reply-to has been disabled (FW advanced settings).

If you disable NAT on OPN, even if it's just for the ISP router LAN only, you'll have to route reply traffic back to OPN WAN, which is essentially choice a.
You might as well disable NAT completely at that point... Most of the work involved ends up being on the edge router (ISP router).

I didn't succeded with NAT, I think that my issue is treating my "WAN" as another "LAN" inside the ISP router network. I guess avoiding that is the key here.

[EricPerl]

With NAT on OPN, the ISP-router LAN is flat (all traffic coming for hosts in that subnet).
The main downside is that you lose visibility into the OPN LAN hosts. That's a feature at the edge router!

If you disable NAT on OPN, you end up propagating traffic with sources in OPN LAN into the ISP-router LAN.
You need to route that traffic back there:
* Internal-GW pointing to OPN WAN IP.
* static route OPN-LAN -> Internal-GW
You might be able to take care of that if your ISP router allows you to specify static routes.

[gixnex]

With NAT on OPN, the ISP-router LAN is flat (all traffic coming for hosts in that subnet).
The main downside is that you lose visibility into the OPN LAN hosts. That's a feature at the edge router!

If you disable NAT on OPN, you end up propagating traffic with sources in OPN LAN into the ISP-router LAN.
You need to route that traffic back there:
* Internal-GW pointing to OPN WAN IP.
* static route OPN-LAN -> Internal-GW
You might be able to take care of that if your ISP router allows you to specify static routes.

Thanks for the suggestion, it seems that my ISP router is quite simple not many routing features available. As workaround I will move everything to 192.168.2.0/24.

I guess that getting another OPN box to replace the ISP router seems an option to use any advanced configuration (ONT is connected via ethernet to ISP router). Is this feasible?

OPN box 1 (homelab box):

- LAN 192.168.2.0/24 (192.168.2.1)
- WAN 192.168.1.0/24 (192.168.1.2)

OPN box 2 (Internet facing box):

- LAN 192.168.1.0/24 (192.168.1.254)
- WAN (whatever the ONT assigns here)

Thanks

[meyergru]

If you have a separate ONT available that can be used from OpnSense, why use the ISP router at all? What I am saying is: Why should you use two OpnSense boxes, when one suffices?

All of the discussed problems arise form the fact that you did not use OpnSense as your (only) router in the first place.

[gixnex]

If you have a separate ONT available that can be used from OpnSense, why use the ISP router at all? What I am saying is: Why should you use two OpnSense boxes, when one suffices?

All of the discussed problems arise form the fact that you did not use OpnSense as your (only) router in the first place.

It's because my setup. I want to have my lab outside the main LAN (I don't want to disturb family with my tests) that's why I have a dedicated box for myself.

You're absolutely right, with this box and using the ONT connection won't have the router-behind-router scenario. If what I'm trying to do is not trivial then I will replace my ISP router with my OPN box, I just wanted to have a safe playground to learn OPNsense.

[meyergru]

You can separate the lab into a VLAN (or a physical LAN, for that matter) with just one OpnSense. I do that all day, even with a Promox server that can use both the normal LAN and the LAB network over separate VLANs.

If you need a "lab rat" OpnSense, you can virtualize that, too. The virtualized version has the advantage of being able to be rolled back to a snapshot, as well, which is still easier to do than OpnSense native snapshots.
I keep one of those around to try new OpnSense updates and patches.

[EricPerl]

When I feel like I should verify what I'm about to post, I run such tests on my secondary virtualized OPN.

[gixnex]

I'll follow your recommendations OPN -> replaces ISP router and VM for testing.

Thanks for your help.