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

[Mastiff]

@tinfoilmatt Thanks! With no way to reboot it unless I pay for a taxi, I for once (which is very uncharacteristic for me) will opt for safe, not sorry...

[johnpoz]

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

So it's not a real WAN.

to pfsense it is - so now it nats, etc.. Such a setup is counter productive..

There is little point to such a setup.

If you want to use pfsense as an internal router - then turn off natting functions. But now your upstream device needs to nat your downstream networks and allow for them in its rules.

If a network is considered a wan or transit/connector network there shouldn't be "hosts" on this network your other devices want to talk to.

[tinfoilmatt]

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

If you want to use pfsense as an internal router - then turn off natting functions.

Completely agree that an 'internal' or 'inner' or 'core' or anything but an edge router should not be performing NAT.

[tinfoilmatt]

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

[On a] transit/connector network there shouldn't be "hosts" on this network your other devices want to talk to.

Also why so-called 'transit' IPv4 networks are typically assumed to be /30. Four IP addresses: subnet ID (at the bottom of the range), broadcast address (at the top of the range), and two 'useable' addresses assigned to two hosts in between.

[johnpoz]

@tinfoilmatt the mask doesn't really matter - but sure a /30 is common, so is /29 and even /28

There may be multiple routers on this same transit network, you might have a ha pair sort of router where there would be multiple IPs and a vip that is used, etc.

A network used to connect routers together shouldn't really have "hosts" on it - ie devices you want to interact with from your other networks. Or you would need to host route on the device in the transit, or use nat and port forwards, etc..

It leads a an unnecessary complex network.

[tinfoilmatt]

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

There may be multiple [i.e., more than two] routers on this same transit network, you might have a ha pair sort of router where there would be multiple IPs and a vip that is used, etc.

Ah, very true. And the same goes for IPv6 transit networks.

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

A network used to connect routers together shouldn't really have "hosts" on it

Re-reading, I also noticed a lack of precision in my statement "two hosts in between." I believe it'd have been more precise had I said "two routers in between." (But again, that still fails to consider transit networks with more than two routers attached for whatever the reason.) I believe you're pointing out that 'router ≠ host' and vice versa.

[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!