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

[Mastiff]

@tinfoilmatt So then I can't lock myself out? I have chosen WAN_DHCP for IPv4 and None for IPv6, which I don't use.That should be correct? They are the only options before I add a gateway.

Edit: I just remembered that one of the neighbours is at his summer home working, so I can't kill WAN whatever I do. I think I'll go back to plan A and continue this next weekend.

[patient0]

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

The return port from the receiver (1.200) to the Pi (1.101) seems to be varying. I see 43636 on this,

If 1.101 is setting up the TCP connection then it will choose a random port as source port. That as such is normal TCP connection behaviour.
If you access a website, your source port will be random and the destination will be 80/443.

And if HA will initiate the communication with the Yamaha receivers then it's like talking to a website and no route is needed anywhere.
But if the receivers also are trying to initiate a connection to HA then it would have to know how to get to it via 1.53.

Addition: but reading through the Python YNCA code github: mvdwetering ynca Python module it really seems to be just a tcp connection to port 50000 (per default). And then a serial protocol over tcp.

[tinfoilmatt]

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

I have chosen WAN_DHCP for IPv4 and None for IPv6, which I don't use.That should be correct?

"WAN_DCHP" selected for Default gateway IPv4 means that any traffic allowed to pass out to WAN/the Internet by the firewall ruleset and without any gateway explicity selected for a given rule (i.e., policy based routing) will use your WAN interface's gateway, meaning (I assume) your ISP's connection, as its next-hop router. This is desirable in the vast majority of cases, including your remote access to this pfSense system from outside the LAN.

(And if you're not using IPv6, then of course that's fine set to "None".)

That should be a safe change to apply without blocking your remote access. But it could require a system reinitialization/recycle/reboot if there's wonky system config elsewhere. Fair warning.

And then yes, once you do that you're perfectly safe to add a gateway (i.e., 192.168.1.53) that doesn't otherwise have anything to do with your remote access. But again—depending on overall system config, you could find yourself in a situation where the system's routing table doesn't 'come back up' right, typically requiring a reboot to resolve.

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