Routing only. NO NAT

Started by rm4foe0r, February 02, 2025, 01:37:12 AM

Previous topic - Next topic
February 02, 2025, 01:37:12 AM Last Edit: February 02, 2025, 01:56:39 AM by rm4foe0r
I'm perplexed by the exact same problem as was described here, namely why putting NAT rules to "Disable outbound NAT rule generation (outbound NAT is disabled)" disables outbound routing between interfaces? I expected it to disable NAT, but let traffic be forwarded freely between interfaces (after allowing it in firewall rules).

As the last poster in your linked thread said, it's likely a rule configuration issue... but the possibilities are practically endless. If you want help with such, start by posting a brief explanation of your intent, and your interface (Interfaces: Overview) and rule (Firewall: Rules: [interface]) configs. Perhaps some logs from Firewall: Log Files: Live View, assuming you have rule logging enabled.


February 02, 2025, 02:35:28 PM #2 Last Edit: February 02, 2025, 05:24:00 PM by rm4foe0r
thanks, I would very much appreciate help. I've only had experience with iptables on linux, but firewall seems much different on openbsd. My intent: two interfaces with two separate private networks routed by opnsense. No NAT, just routing. WAN interface isn't internet facing, it's part of another private LAN.

Interfaces Overview: https://0x0.st/8KX9.png
WAN rules: https://0x0.st/8KX1.png
LAN rules: https://0x0.st/8KXj.png
pfctl -sr: https://0x0.st/8K8C.txt
NAT disabled: https://0x0.st/8KXe.png
Logs Live View: https://0x0.st/8KXy.png https://0x0.st/8KXv.png
however logs only show blocked IN packets, even though I expected OUT packets blocked (when trying to run curl/ping from LAN subnet)

Now device from WAN subnet can reach device on LAN subnet, but not the other way around (device on LAN subnet can't reach devices on WAN subnet, it can't reach internet gateway neither).

Any hint would be greatly appreciated.

I'm totally lost, tried everything and this still doesn't work ;/ may as well just enable NAT even though it doesn't make sense to NAT two private networks

Port forwarding *is* NAT. If you just want hosts to communicate between those networks on certain ports, you need firewall "allow" rules, not port forwarding.
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)

Hi Patrick, thanks for looking into this, yes, I don't think I mentioned port forwarding, like you said they just should communicate between these networks. I tried adding firewall allow rules to every interface in many combinations (all quick) and they do nothing ;/

February 02, 2025, 05:23:38 PM #6 Last Edit: February 02, 2025, 05:28:55 PM by rm4foe0r
also here is output from pfctl -sr currently: https://0x0.st/8K8C.txt
I'm able to ping 9.9.9.9 from opnsense  if pfctl -d disables firewall, although still unable to  ping it from devices behind igb1 (assuming firewall needs to explicitly allow forwarding of traffic between interfaces?)

February 02, 2025, 07:49:31 PM #7 Last Edit: February 02, 2025, 10:56:50 PM by rm4foe0r Reason: you know...
thanks to [chatgpt](https://chatgpt.com/share/679fc7de-9a00-800c-9dea-d665f0e70549) I was finally able to recognize that issue wasn't related to firewall rules at all, but to lack of route to subnet behind opnsense in the internet facing router. I initially erroneously thought that adding route will be only required on the host from which connection was initiated and forgot about the internet facing router

I didn't appreciate complexity of routing, makes me question if performance advantage of disabling NAT was worth it, perhaps I will read more about it to avoid getting tripped in the future again

troubleshooting opnsense proves to be very difficult when you can't just disable half of the automatically inserted firewall rules (big part of it though is just complexity of networking in general)

UPDATE: it turned out that modification to firewall was needed after all, otherwise opnsense itself isn't able to reach internet in current configuration for some reason
floating rule did the trick, but not sure if it's too permissive, need to test other options, not sure why it's needed in the first place yet though

It would be good,
to provide Source and Destination IPs, from where to where you are pinging for example?

If you see in live view you that are getting blocked, then basically you don't have proper rules. You lock the RULEs to WAN and LAN net. This means only IPs from these WAN and LAN networks will be permitted and nothing else.

Regards,
S.
Networking is love. You may hate it, but in the end, you always come back to it.

OPNSense HW
APU2D2 - deceased
N5105 - i226-V | Patriot 2x8G 3200 DDR4 | L 790 512G - VM HA(SOON)
N100   - i226-V | Crucial 16G  4800 DDR5 | S 980 500G - PROD

Yeah, I should have drawn a network topology before asking this question, otherwise it's quite to hard to wrap your head around (especially when you don't have access to the network.) I was pinging from a device on "main" subnet (192.168.1.182) to a device in a subnet behind opnsense (10.176.54.16)