Messages

You can keep repeating the same thing, but it is still not true.

Even the GUI tells you are wrong - have a look at the bottom of the Rules page for each interface: "Everything that is not explicitly passed is blocked by default."

Yes, with the default LAN "allow to any" rules, anything coming into the LAN interface will be allowed anywhere, including to the DMZ subnet. But the reverse does not apply (other than of course stateful replies to incoming LAN traffic).

Outbound NAT has nothing to do with it. The automatic Floating rules block everything into an interface by default (with limited exceptions), and allow everything out of an interface by default (coz OPNsense's default policy is to filter inbound).

So do you have suggestions for the User who posted ??? why not help them?

client setup:  192.168.0.x(Corp net) -----  10.10.10.x (DMZ network)
The default rules allow all networks to access each other until you enter some block rules.

In fact not true. The basic philosophy of OPNsense is that, with limited exceptions like for DHCP and ICMP, traffic between subnets/VLANs is blocked by default.

It is true that the LAN interface is created with two allow any rules for IPv4 and IPv6 - basically to ensure that OPNsense works out of the box. But any other interface/VLAN created does not have any allow any rules, and so virtually all traffic from those subnets is blocked by default.

I'm not sure how helpful it is to be repeating the same info in different threads when the focus of the OP question is on other issues, eg double NAT in this thread or SNAT in another thread? No doubt you are keen to promote your business but I don't think this is the place for that. Just sayin'...

First - I am here to share my experience and help others, not make money.  In fact responding to posts costs me time and money.

2nd:  In each of our clients opnsense deployment out of the box - default configuration all networks were able to communicate with each other.  Even when VLAN's were created, those networks were all able to communicate with each other.  This in fact was a real issue, especially in a designated DMZ network.  The only way I was able to stop inter network communications was by adding a block rule in each network for which network was to be blocked.
Correction: Yes it seems we created an LAN(1)(2)etc ==} Any rule for each network so it could get out to the internet but this rule also allowed each network to communicate with each other... which was resolved by adding Block rules

3rd: As for posting near similar information in another post as a reply, well the content and answer worked for both inquiries.  With that said, in the other post, I missed the first time the user was trying to mask their source IP, so I created an edit to suggest a possible solution path to explore.

Instead of critiquing my response.. why not provide a useful response to the person who created the post.

Further, I have provided screen shots so the User who posted can see which rules produced which result which I believe answers their question as well as provide guidance on how to create the rules.

Cheers

Okay routing between networks is really easy.. I just resolved this for a client.

client setup:  192.168.0.x(Corp net) -----  10.10.10.x (DMZ network)
*edit*The default rules allow all networks to access each other until you enter some block rules.  However the client needed certain ports and servers on the Corp side accessible, here is what we did.
*correction* No rule is created by default.  We created an Allow All rule for each network to enable internet access simply however had to add a Block Rule for each network to prevent inter-network routing that was not desired

I went to the DMZ Rules and I created the Allow rules for the ports and destination(corp) we wanted to allow and moved them to the top of the list.  Then I created an all Block rule for the DMZ==}Corp network so has to secure the Corp network from the DMZ.

Next the CORP Rules: in this case we left the all network access rule that is created by default as the client did not care about whether any system could access the DMZ network/server from the Corp network.

I have provided pictures of the rule sets that allowed specific access from the DMZ to the Corp network/servers and blocking the rest while allowing the Corp Network to have unrestricted access to DMZ.

If we wanted to lock down Corp==}DMZ we could make rules in the Corp Network Rules section like we did in the DMZ so that only some ports and systems could access the DMZ from the Corp Network.

Hope this helps.

Okay DMZ is really easy.. I just resolved this for a client. 

client setup:  192.168.0.x(Corp net) -----  10.10.10.x (DMZ network)
The client needed certain ports and servers on the Corp side accessible, here is what we did.

I went to the DMZ Rules and I created the Allow rules for the ports and destination(corp) we wanted to allow and moved them to the top of the list.  Then I created an all Block rule for the DMZ==}Corp network so has to secure the Corp network from the DMZ.

Next the CORP Rules: in this case we left the all network access rule that is created by default as the client did not care about whether any system could access the DMZ network/server from the Corp network.

I have provided pictures of the rule sets that allowed specific access from the DMZ to the Corp network/servers and blocking the rest while allowing the Corp Network to have unrestricted access to DMZ. 

If we wanted to lock down Corp==}DMZ we could make rules in the Corp Network Rules section like we did in the DMZ so that only some ports and systems could access the DMZ from the Corp Network.

Hope this helps.

*edit*
If you are trying to mask the server IP or translate the server IP to a DMZ ip, this is fraught with challenges and generally you call not do this without some advanced networking.
If there is a chance you would need to create a 1:1 NAT for the Server LAN IP to be associated to the DMZ IP and then create an Outbound NAT rule.

Since the upgrade 2FA using either google or MS authenticators are resulting in authentication failures.
Once I changed the authentication to "local database" then Users could authenticate and connect to the vpn.

Things working perfectly find prior to the update.

I have already verified; time servers on the appliance, the phone used with the the Authenticator app and desktop

The TOTP is setup for 60 seconds duration and 10 seconds grace.  Even when the grace period is extended to 15, the authentication fails.

I also created a new user, new user certificated and OTP seed however the issue continues with existing and new users.

I have also installed the latest version of the openvpn software "openvpn-connect-v3-windows-x86" as I noticed in the logs that opn sense was using tls 1.3.
The logs are just showing authentication failed?

Not sure where to go from here.

*edited: nov-12-2021 @ 8:09pm EST*

After some additional testing I have found after the update the OPT Seed is generating via the QR Code 30 second timer sessions.  This is an issue as the Access Server setup for TOTP was configured for 60 seconds.  Now after the update, I did notice the '60 seconds' custom setting was cleared and I thought that was an error however it may have been by design.  The problem this causes is that all existing Users have authenticators setup using the 60 second timer and this is why authentication is failing.
It does not seem to matter what ever setting I make in the section "Time window", Opnsense seems to be generating authenticator timers setups of 30 seconds.

I have confirmed even using the previously release OTP Seed QR code, it is creating a 30 second timer authenticator where as Users have 60 second timers.

Thus something has changed with the update and not sure if it is a bug, I am guessing it is since this forced 30 second time negates the option to set the Time Window to 60 seconds.

So the solution is, for Users to delete their current authenticator and then generate a new one and to have the OTP Access Server to be configured with no Time Window defined thus leaving it to the default.

Perhaps OPNsense Dev's will resolve this, as Users have complained with a 30 second timer.