Messages

1

General Discussion / Re: OPNsense rule chaining challenge

« on: April 11, 2020, 05:54:50 pm »

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. 

2

General Discussion / Re: OPNsense rule chaining challenge

« on: April 08, 2020, 11:42:11 pm »

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?

3

General Discussion / Re: OPNsense rule chaining challenge

« on: April 08, 2020, 12:16:37 am »

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.

4

General Discussion / Re: OPNsense rule chaining challenge

« on: April 07, 2020, 11:33:33 pm »

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

5

General Discussion / Re: OPNsense rule chaining challenge

« on: April 07, 2020, 10:44:38 pm »

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.

6

General Discussion / Re: OPNsense rule chaining challenge

« on: April 07, 2020, 10:36:33 pm »

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.

7

General Discussion / Re: OPNsense rule chaining challenge

« on: April 07, 2020, 10:29:58 pm »

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?

8

General Discussion / Re: OPNsense rule chaining challenge

« on: April 07, 2020, 10:20:08 pm »

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

9

General Discussion / OPNsense rule chaining challenge

« on: April 07, 2020, 10:12:59 pm »

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?