Can somebody help me get to Yamaha YNCA throug a pfSense?

stephenw10

You shouldn't need a static route here because pfSense is NATing the connection to it's WAN IP. The receivers don't need a route because they are in the same subnet.

The state table there showed traffic both ways. The pcap shows the initial TCP handshake completes. Then we see no further response.

We probably need to see a more complete pcap there with the view level set higher or the actual pcap file.

tinfoilmatt

@stephenw10 said in Can somebody help me get to Yamaha YNCA throug a pfSense?:

You shouldn't need a static route here because pfSense is NATing the connection to it's WAN IP.

This doesn't account for the receiver initiating a connection to Home Assistant, nor multicasting an attempt to 'discover' (or 're-discover') Home Assistant.

OP confirmed in this post that at least one of the receivers at-issue has a default gateway of 192.168.1.1—which is homed to a Netgate 3100 sitting at the true LAN edge, and where the proposed static route would need to be configured.

tinfoilmatt

@stephenw10 I agree with you, however, that 192.168.1.200:50000 (one of the receivers) should be sending its reply traffic back to 192.168.1.53:[source port] (the virtualized 'internal' pfSense router) directly—which should then 'follow' state back to 192.168.6.2:[source port] (one of the HA VMs).

I readily admit I'd be surprised if a static route configured on 192.168.1.1 resolves this.

stephenw10

Well yes indeed. This setup only allows the HA server to open connections to the receivers not the other way around.

If the receivers are required to open connections back then this WAN-LAN setup is the wrong way to go about it.

Adding static routing on the edge pfSense will result in asymmetric routing and you would then also need to add workarounds for that. Ugly!