OPNsense rule chaining challenge

[sparx42]

Hello community,

I have a challenge in getting a few simple rules chained (on WAN, access rule to DMZ -> DMZ rule to access OPT1 -> DMZ Port Fwd to OP1) on OPNsense 19.7.10_1-amd64. Maybe someone here can provide a hint how to get this achieved. The rules each on their own work just fine, yet they don't work in unison.

My intention: route traffic coming from internet, accessing the DMZ IP 121.22.0.99 on 22/tcp (ssh) and redirecting the traffic internally to a Linux machine on OPT1 IP 10.0.0.33 listening on 22/tcp (ssh).

Here is a simple IPv4 example of the network flow (security is irrelevant here):

WAN if:  1.1.1.0/29     (peering network)
DMZ if:  121.22.0.0/24  (public IP allocation)
OPT1 if: 10.0.0.0/24    (private LAN)
Linux test server IP on OPT1:  10.0.0.33/24 (firewall disabled on Linux)
DMZ IP range for public access: 121.22.0.0/24

1) On the WAN interface, I created a rule that allows internet traffic inbound access to DMZ LAN to IP: 121.22.0.99 (no VM or service bound to this IP, just the rule on OPNsense)
2) On the DMZ interface, I created a rule that allows the DMZ network (121.22.0.0/24) access to the Linux test server on 10.0.0.33 full IP.
3) I then configured a "NAT port forward" rule listening on DMZ interface and forward the incoming traffic to: 121.22.0.99/32 on port 22/tcp to 10.0.0.33/32 with port 22/tcp.

When tested individually, each rule is working perfectly fine. However, I cannot connect from the internet with ssh to 121.22.0.99 and get routed to 10.0.0.33. 

What am I missing here or what do I need to change to achieve my original intention?

[banym]

Do I understand correct that you try to route the traffice from WAN -> DMZ -> LAN but there is no real Server in the DMZ you only want to "Fake the DMZ" and route it into the LAN?

[sparx42]

Exactly my intention. I'd like to chain the rules and avoid a machine in the DMZ.

[banym]

O.k, I can't think of a practicable way that would do this.

On the other side I do not see any reason to do this. Just do a  normal NAT from WAN to the machine.

[sparx42]

I can't use the WAN address range for this. It has to be an IP from the DMZ for this matter.

Is there any way to chain rules across interfaces? Maybe I'm missing a OPNsense feature or tick-box in order to chain these rules together?

[banym]

It maybe is possible but I see no way with a Faked target IP in first place.

But this is over my head, maybe you can achieve it with a NAT setup, but no idea and never had the need for it.

Sorry, but here are more advanced guys around maybe someone can help you.

[sparx42]

Thanks banym for your time and effort.

I still hope to find a solution. However, I'm also aware that this it's not a mainstream problem that many have attempted or a need for.

[banym]

The main problem is, that after the first NAT and Firewall rule fits, to my knowledge, no further rules are processed for traffic.

First hit processed the traffic and done. You want to have it not done that way. No clue how to call it or what to search for.

[sparx42]

I understood that (hint at: Quick tick-box for rules) but OPNsense processed the packet on the WAN interface and that's ok. Then however, once that same packet lands on the DMZ interface, the "NAT port forward" should pick that same packet up and redirect it to OPT1 LAN and this last step never happens.

I don't quite understand why it processes the first rule and the packet is then never processed on the DMZ rule set or NAT rule set. I'm fairly sure that I'm missing something here.

[banym]

No you don't miss anything.

First rule hit is processed. But than the package left the firewall and is sent out the interface. There is no further processing possible. I am not aware of any other package filter that is possible to chain rules that way, but I never had the requirement.

The only thing that could come close to a chain is NAT and a rule that processes traffic, but same thing here. After the traffic is processed it leaves the interface and is not processed by other rules to my knowledge.

[sparx42]

Can I/we please have some confirmation from OPNsense that the statement here is 100% correct and reflects how OPNsense processes packets with its rule engine?

"First rule hit is processed. But than the package left the firewall and is sent out the interface. There is no further processing possible."

[sparx42]

I think I may have found a solution to match and chain rules which I will explore in more detail over the coming day or two, using local tagging on NAT & FW rules (not VLAN tagging). OPNsense offers an option to locally mark/tag rules and match them at a later stage? However, I'm not sure yet how exactly that mechanism is working to make full use of it, so further reading is in order, unless someone else can offer a solution here.

[sparx42]

Ok, so I made some interesting progress today.
1)   NAT Port Fwd Rule: listen on WAN interface, Destination DMZ with dest port 22/tcp and NAT to OPT1 IP 10.0.0.33
     NAT reflection: Enabled.
2)   Reverse NAT was automatically configured on WAN interface = OK
(!) The wizard however, did NOT generate a rule on OPT1, allowing access on this interface to enter and access IP 10.0.0.33 (!)
So I added that rule manually and now I can see with tcpdump traffic on the Linux VM coming in and the response going back out from 10.0.0.33 > public initiator IP. Great!

Remaining problem: I don’t get traffic back to the initiating client at the other end of the internet. I’m missing somehow a reverse NAT or Outbound rule?

DMZ as well as OPT1 have outbound internet access for this test. But I’m wondering how the reverse NAT has to look and where to enter that manually? Is it a rule on the WAN interface or a specific NAT Outbound rule (Hybrid NAT mode enabled)? If so, how would the Outbound NAT rule have to look?

[sparx42]

Ok, I found the problem and solution. It is working as intended now.

Solution requires 2 additional configurations entries:

1) Firewall > NAT > Outbound: public IPs do not need a NAT rule, explicitly disabled this.
   Add rule: 
   Interface: WAN
   select: "Do not NAT"   (tick the box)
   Source address: 121.22.0.99/32   (or 121.22.0.0/24)
   Comment: "Do not NAT public subnet/host"

2) Firewall > Virtual IPs > Settings (Proxy ARP for public subnet host or range)
   Add entry:
   Mode: Proxy ARP
   Interface: WAN
   Type: Network
   Address: 121.22.0.0/24  (or /32 if a single IP required)
   Comments: "Public subnet range/host"

After this, NAT Port forwarding and NAT 1:1 work flawlessly utilising a public IP range.

Of course, the WAN interface still requires a rule that allows it to access the IP: 10.0.0.33/32 on OPT1.

Viel spaß damit.