Routing only. NO NAT

[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).

[pfry]

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.

[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.

[rm4foe0r]

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

[Patrick M. Hausen]

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.

[rm4foe0r]

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 ;/

[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?)

[rm4foe0r]

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

[Seimus]

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.

[rm4foe0r]

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)

[EricPerl]

Check out Diagram tool

[Seimus]

If

Source 192.168.1.182
Destination 10.176.54.16

Than you should be able to pass thru the Rules you have set on WAN/LAN. You can see in your Live view there is an Egress on LAN, allowed rule, thus it must have passed on Ingress from WAN.

However the pics you show for detail on a specific session https://0x0.st/8KXv.png has completely different Source, that source is a Public one. And this one will not pass cause you do not have a rule for that.

Regards,
S.

[EricPerl]

I was a bit curious about this setup so I just gave it a try starting from a fresh 25.1 install on my spare OPN2 (behind OPN1).
So everything default apart from disabling bogons/private on WAN since the spare is on my internal network.

On OPN2, I obviously had to disable NAT.

But most of the configuration to get thing to (at least superficially) work was done on OPN1:
* FW rule on the VLAN for OPN2.WAN allowing IN from 192.168.1.0/24 sources to !RFC1918 destinations (since unNATted traffic would not match my existing rule).
* Change Outbound NAT mode to hybrid (because by default OPN only NATs for its known networks).
* Outbound NAT rule to NAT for 192.168.1.0/24 on WAN.
* Create gateway to route traffic back to 192.168.1.0/24 (pointing to OPN2.WAN_IP on the VLAN interface used to access it).
* Create a manual route 192.168.1.0/24 -> GW from previous step.

I had never done anything similar. I just observed the live view on OPN1 and corrected accordingly.
I also did a quick packet capture on OPN2 WAN to confirm packets weren't reaching it before the manual route.

I'll probably revert these changes quickly...
I trust the experts to tell me if that was NOT the appropriate way to handle this issue.

HTH