Rule not taking effect

[cybernet1981]

Hello everyone,

New to the forum and newish to Opnsense. Love the product but I have been knocking my head against the firewall(  ) regarding a rule that just does not seem to work.

My current environment is  OPNsense 21.1.1-amd64 with 4 interfaces (1 LAN 3 OPT). So this rule used to work then suddenly stopped... i cleared states, rebooted, reloaded services to no avail:

Rule is:
IN ipv4 interface:opt3 src:opt3-net any port dst:10.8.0.0/24 any port

Log gives the following:

__timestamp__   Feb 18 01:53:21
action   [block]
anchorname   
dir   [in]
dst   10.8.0.2
ecn   
id   32008
interface   em3
interface_name   OPT3
ipflags   none
label   Default deny rule
length   60
offset   0
proto   1
protoname   icmp
reason   match
rid   02f4bab031b57d1e30553ce08e0ec131
ridentifier   0
rulenr   12
src   178.100.0.10
subrulenr   
tos   0x0
ttl   128
version   4

Any ideas why it applies the default rule even though I have an explicit rule set? ANy help would be greatly appreciate, my demo depends on this

[Greelan]

Is the source IP in that log within opt3-net?

[cybernet1981]

Yes it is. I even destroyed the rule and redone it a couple of times.

Could there be a DB issue?

[Gauss23]

Please provide a network plan
https://forum.opnsense.org/index.php?topic=7216.0

178.x.x.x is a strange network for internal usage.

[Fright]

hi

Rule is:
IN ipv4 interface:opt3 src:opt3-net any port dst:10.8.0.0/24 any port

and

src   178.100.0.10

you sure that 178.100.0.10 is in opt3-net?

[cybernet1981]

Yes it is the actual ip (the real one, sorry habit of obfuscating IPs in forums) 172.25.XX is in OPT3 net

my network is as follows:


| OPNsense|             
| LAN          |-----192.xx/24-----Management
|OPT 1        |-----10.2.xx/24-----Main  **DHCP active
|OPT 2        |-----172.20.xx/24-----Wireless **DHCP active
|                 |
|OPT 3        |-----172.25.xx/24-----Remote----DHCP active---------------175.25.xx/24--|VPN Server|------10.8.0.0/24


FYI, just rebuilt the whole setup and still same effect...what am I missing

[Fright]

sorry. I still can't figure out what should be happening on the OPT3. and how, according to this scheme, a packet from 172.25/24 for 10.8/24 should appear on OPT3 interface

[Gauss23]

I don't understand

Code: [Select]

|OPT 3        |-----172.25.xx/24-----Remote----DHCP active---------------175.25.xx/24--|VPN Server|------10.8.0.0/24
Why is the same network there twice? And what does remote mean? Is this your WAN/upstream gateway?

What is this VPN-Server?

I don't see the problem with private IPs. No need to obfuscate in my opinion.

Please send screenshots of firewall rules on OPT3 and Floating.

[cybernet1981]

So by VPN server , this is my external facing remote access appliance (not Opnsense) running OpenVPN it connects to OPT3 so it has an opnsense provided IP 175.25.25.10

When I connect remotely to the VPN i receive the IP 10.8.0.2 for my client which is then routed to access OPT3 network (175.25.25.0/24).

This worked when I routed to the management interface (LAN) and used to work on OPT3. I know it gets to OPNSENSe on OPT3

[Gauss23]

I think we have a case of asymmetric routing here.
On your last screenshot you see traffic coming from port 3389 (RDP) to a high port on 10.8.0.2. What you see are the responses of the RDP server. Usually those packets are covered by the state from the opening packet going FROM 10.8.0.2 to 172.25.25.11.
What I think is: the packets are going another way FROM 10.8.0.2 TO 172.25.25.11. The OPNsense is blocking those packets because they claim to be an established connection but your OPNsense does not have a state saved for it.

You need to check the routing. Packets need to take the same way in both directions.

[cybernet1981]

Ahhh , I had a suspicion it could be that. Thank you for pointing me in the right direction. Would adding a far Gateway solve this? trying to figure out the easiest way of solving this.

[Gauss23]

The problem is not in the OPNsense as far as I can see. It’s the way from 10.8.0.2 to 172.25.25.11 you need to check.  You need to make sure that the packets are going through your OPNsense in both directions

[cybernet1981]

Thank you I will look into it! and share my progress

[Fright]

you definitely need clients from the 10.8/24 network to communicate with servers from 172.25/24 through the opnsense? why not make the 175.25.25.10 static/reserved and add routes on 172.25/24 to 10.8/24 net trough the 175.25.25.10?

[cybernet1981]

So this is a very interesting proposition. I need remote clients to be able to access internal servers as I'm trying to implement a "cloud environment" . Would yo be able to point me in the direction of the ressources that would help me accomplish the routing strategy you mention. FYI 172.25.25.10 is already static as well as the VPN server 172.25.25.15 Thank you again for the ideas