Can't get firewall to pass some subnet traffic

Started by thinkentropy, Today at 02:07:36 AM

Previous topic - Next topic
I had the bright idea of moving my Opnsense from bare metal to virtualized in Proxmox. Everything seems to be working except the firewall seems to be blocking some subnet traffic that I think should be passing. I've been struggling with this for days so if I can't figure this out I will go back to bare metal. Any help would be so greatly appreciated!! Here is my current setup--

I have Opnsense (192.168.1.1) running in a VM in Proxmox (192.168.1.101). They're both sharing a physical network interface over a virtual bridge within Proxmox. I setup this network and called it "LAN," 192.168.1.0/24.

I created a 2nd virtual bridge within Proxmox for another physical network interface on my machine. In Opnsense, I assigned this network as 192.168.3.0/24 and called it "VLANs". I created a Truenas VM in Proxmox and assigned it to use the 2nd virtual bridge I setup. In Opnsense, I assigned IP 192.168.3.248 to this Truenas VM.

In my firewall rules, I have added "pass" rules to allow all traffic into the "VLANs" interface, and "pass" rules to allow all traffic into the "LAN" interface. I can successfully ping computers to and from both subnets. Pinging 192.168.3.248 from 192.168.1.222 works.



The problem is when I try and access the Truenas webgui. The firewall live view shows "Default Deny" blocking the TCP request on port 80 going into the VLANs interface.



Shouldn't the rules I created allow this TCP traffic to pass?

Quote from: thinkentropy on Today at 02:07:36 AMShouldn't the rules I created allow this TCP traffic to pass?
Yes, but the blocks seems to be non-SYN packets (state violation).
Tick the "i" at the right to display the details and check the TCP flag.
Filter rules are only applied to SYN packets. If this is permitted, OPNsense adds the connection to its state table and let subsequent packets pass.

Possibly you did something wrong with the VLAN configuration, so that the SYN packet can go directly from the client to the server, but the response packet has to pass OPNsense.

This could be a case of asymmetric routing or maybe, problems because of mixing tagged and untagged VLANs on the same interface.

Since it is Proxmox, you may have also configured both subnets on that...
Intel N100, 4* I226-V, 2* 82559, 16 GByte, 500 GByte NVME, Leox LXT-010H-D

1100 down / 450 up, Bufferbloat A+

Quote from: viragomann on Today at 01:30:41 PM
Quote from: thinkentropy on Today at 02:07:36 AMShouldn't the rules I created allow this TCP traffic to pass?
Yes, but the blocks seems to be non-SYN packets (state violation).
Tick the "i" at the right to display the details and check the TCP flag.
Filter rules are only applied to SYN packets. If this is permitted, OPNsense adds the connection to its state table and let subsequent packets pass.

Possibly you did something wrong with the VLAN configuration, so that the SYN packet can go directly from the client to the server, but the response packet has to pass OPNsense.

Hello! Thank you so much for sharing your insight into this! I am super grateful.



You are correct--if I tick the information button to view the details of the block, it does show the TCP flag is SA. I will start looking into this today to see if I can figure out how to fix this as I'm not familiar with SYN packets at the moment. I will have to do some reading today.

Quote from: meyergru on Today at 02:13:29 PMThis could be a case of asymmetric routing or maybe, problems because of mixing tagged and untagged VLANs on the same interface.

Since it is Proxmox, you may have also configured both subnets on that...

Thank you!!

I don't have any Vlan tagging (at least not intentionally). But, it I agree it sounds like I have indeed screwed something up in Proxmox. I will poke through it today and see if I can figure out what I did wrong. Really appreciate your help thank you thank you!

Since your OPNsense is virtualized you can consider to do the whole VLAN stuff in Proxmox and just provide the respective virtual interfaces to the VM.