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

patient0

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

my Pi that up to now has been running this plug-in?

Btw: you could run a tcpdump on the Pi to see how the working traffic looks like. And from that it may be possible to figure out the issue.

github user graememorgan has a "Yamaha-YNCA-Receivers.pdf" in his repo (together with a short and old Python script). In that (also old) PDF under "2.2.2 Ethernet Port Settings" it mentions:

Default network port number : 50000/TCP
Variable range : 50000 to 65535

Port setting can be changed by YNCA or YNC command only. See 4.2.3 Port Number Change
for details.

You seem to be right about port 50000/tcp.

Mastiff

@patient0 The return port from the receiver (1.200) to the Pi (1.101) seems to be varying. I see 43636 on this, I'll try to open for that. Can the receiver be pushing here, so that's why it isn't working?

sudo tcpdump -i eth0 tcp portrange 50000-65535 and src 192.168.1.200
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
17:31:36.686934 IP 192.168.1.200.50000 > 192.168.1.101.43636: Flags [P.], seq 1420605076:1420605101, ack 3707639785, win 3620, options [nop,nop,TS val 2571150897 ecr 903009886], length 25
17:31:54.754639 IP 192.168.1.200.50000 > 192.168.1.101.43636: Flags [P.], seq 25:38, ack 15, win 3620, options [nop,nop,TS val 2571152704 ecr 903027941], length 13
17:31:54.759907 IP 192.168.1.200.50000 > 192.168.1.101.43636: Flags [P.], seq 38:181, ack 15, win 3620, options [nop,nop,TS val 2571152704 ecr 903027956], length 143
17:31:54.763822 IP 192.168.1.200.50000 > 192.168.1.101.43636: Flags [P.], seq 181:290, ack 15, win 3620, options [nop,nop,TS val 2571152705 ecr 903027961], length 109
17:31:59.216182 IP 192.168.1.200.50000 > 192.168.1.101.43636: Flags [P.], seq 290:308, ack 34, win 3620, options [nop,nop,TS val 2571153150 ecr 903032402], length 18
17:31:59.216819 IP 192.168.1.200.50000 > 192.168.1.101.43636: Flags [P.], seq 308:327, ack 34, win 3620, options [nop,nop,TS val 2571153150 ecr 903032417], length 19
17:31:59.829041 IP 192.168.1.200.50000 > 192.168.1.101.43636: Flags [P.], seq 327:355, ack 34, win 3620, options [nop,nop,TS val 2571153211 ecr 903032418], length 28
17:31:59.830096 IP 192.168.1.200.50000 > 192.168.1.101.43636: Flags [P.], seq 355:386, ack 34, win 3620, options [nop,nop,TS val 2571153211 ecr 903033030], length 31
17:31:59.869126 IP 192.168.1.200.50000 > 192.168.1.101.43636: Flags [P.], seq 386:425, ack 34, win 3620, options [nop,nop,TS val 2571153215 ecr 903033031], length 39
17:31:59.870113 IP 192.168.1.200.50000 > 192.168.1.101.43636: Flags [P.], seq 425:456, ack 34, win 3620, options [nop,nop,TS val 2571153215 ecr 903033070], length 31
^C
10 packets captured
10 packets received by filter
0 packets dropped by kernel

sudo tcpdump -i eth0 tcp portrange 50000-65535 and dst 192.168.1.200
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
17:33:24.784203 IP 192.168.1.101.43636 > 192.168.1.200.50000: Flags [P.], seq 3707639854:3707639868, ack 1420605582, win 501, options [nop,nop,TS val 903117985 ecr 2571159169], length 14
17:33:24.805569 IP 192.168.1.101.43636 > 192.168.1.200.50000: Flags [.], ack 14, win 501, options [nop,nop,TS val 903118007 ecr 2571161709], length 0
17:33:24.809778 IP 192.168.1.101.43636 > 192.168.1.200.50000: Flags [.], ack 266, win 501, options [nop,nop,TS val 903118011 ecr 2571161709], length 0
17:33:27.204179 IP 192.168.1.101.43636 > 192.168.1.200.50000: Flags [P.], seq 14:33, ack 266, win 501, options [nop,nop,TS val 903120405 ecr 2571161709], length 19
17:33:27.220209 IP 192.168.1.101.43636 > 192.168.1.200.50000: Flags [.], ack 284, win 501, options [nop,nop,TS val 903120421 ecr 2571161950], length 0
17:33:27.220808 IP 192.168.1.101.43636 > 192.168.1.200.50000: Flags [.], ack 303, win 501, options [nop,nop,TS val 903120422 ecr 2571161950], length 0
^C
6 packets captured
6 packets received by filter
0 packets dropped by kernel

Edit: Adding

tinfoilmatt

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

Since pfSense is NAT-ing the .6.x traffic to the 192.168.1.x address of pfSense WAN that should not be necessary.

But that doesn't account for the Yamaha receiver's default gateway not being 192.168.1.53.

Mastiff

@tinfoilmatt Correct, that's 192.168.1.1.

tinfoilmatt

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

You seem to be right about port 50000/tcp.

Nobody's contended this point.

tinfoilmatt

@Mastiff You need a static route on whatever 192.168.1.1 is—again, to route any traffic destined for the 192.168.6.0/24 subnet to use 192.168.1.53 as the gateway.

tinfoilmatt

How else is 192.168.1.1 going to know that traffic destined for 192.168.6.0/24 needs to be routed to another router on its same LAN segment?

Phrased another way—how is 192.168.1.1 going to know that the 192.168.6.0/24 network is "directly connected" to another router, 192.168.1.53, on its same LAN segment?

Another way—how is 192.168.1.1 going to know to send traffic destined for 192.168.6.0/24 somewhere else, as opposed to sending it out the WAN where it routes all other traffic destined for networks it's not attached to?

Mastiff

@tinfoilmatt Aha, now I think I understand. OK, I'm in static routes, but it seems I need to add a Gateway for that. I'm a bit gunshy of doing that since I have no other way of connecting to my boat and other stuff at my summer home, and my wife has taken the car to visit our daugther. So in case I should lock myself out, I think I'll wait with that until I'm on the inside of that network next weekend. Thanks for the help so far, I will let this lie until Friday or Saturday.

tinfoilmatt

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

I'm in static routes, but it seems I need to add a Gateway for that.

Do it.

Ensure the "Default gateway" dropdowns are set to something other than "Automatic".

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.