Why did this LAN rule require turning off the adv. feature "state type" to work?

[theprez1980]

Basically the subject line - I couldn't get this rule to work - it's a rule to allow remote access to a LAN device on port 8006 on TCP (Proxmox) from over a VPN connection.

After exhausting troubleshooting I decided to turn off the "State Type" from Keep State to None - and now it works fine.

I'm unsure why this was required and hope an expert can school me.  I've attached a packet capture if that helps.

Thanks

Here's a link to the packet capture screenshot: https://imgur.com/a/dSR4RWI

[Patrick M. Hausen]

You need to place the rule on the VPN interface, not LAN.

[theprez1980]

I don't have a VPN interface tho, my VPN server is running on a Ubuntu VM on the LAN side.

Is that an issue?

Thanks

[Patrick M. Hausen]

Then your VPN server sends the packets to OPNsense first instead of directly to the Proxmox host. Do the VPN server and Proxmox share the same LAN? Are the netmasks consistent?

[theprez1980]

Yes - same /24 (10.0.0.x) for the OpnSense, Ubuntu and Proxmox devices.   The VPN Ubuntu server has an 172.X network that's used for the tun tunnel that's a /24 also.

[Patrick M. Hausen]

OK, so my theory what happens is:

- the VPN server sends the initial packet from your client to the Proxmox host directly, because it is on a locally attached network
- the Proxmox host not knowing the VPN network sends its reply to its default gateway, namely OPNsense
- OPNsense with state tracking enabled sees a SYN/ACK without a preceding SYN and the state violation rule kick in

Solution:

- add a static route to the VPN network via the VPN server to your Proxmox host

[theprez1980]

Thanks - I'll give that a try and that makes sense with one minor change-

From the remote VPN client side it would follow this path (I believe)
Client 192.168.0.1 to VPN Tunnel GW 172.0.0.1 to UnbuntuServer 10.0.0.104 to Proxmox 10.0.0.1

[theprez1980]

Added a gateway and static route - same behavior unfortunately

[Patrick M. Hausen]

Pull out the big gun, i.e. tcpdump/wireshark, and try to find where the packets go the wrong way.