[J65nko]

To establish a TCP connection, the client and the server perform a ritual, the 3-way TCP handshake. See https://en.wikipedia.org/wiki/TCP_ha..._establishment.

The tcpdump show that the ssh server at 192.168.0.150 receives the first packet from the handshake, but never replies. That is why the ssh client retries a couple of times and then gives up.

22:33:15.252514 WAN Address.49885 > 192.168.0.150.ssh: S 2849765595:2849765595(0) win 65535 <mss 1420,nop,wscale 4,nop,nop,timestamp 1686270204 0,sackOK,eol> (DF)
22:33:16.355518 WAN Address.49885 > 192.168.0.150.ssh: S 2849765595:2849765595(0) win 65535 <mss 1420,nop,wscale 4,nop,nop,timestamp 1686271299 0,sackOK,eol> (DF)
22:33:17.458050 WAN Address.49885 > 192.168.0.150.ssh: S 2849765595:2849765595(0) win 65535 <mss 1420,nop,wscale 4,nop,nop,timestamp 1686272396 0,sackOK,eol> (DF)
22:33:18.562520 WAN Address.49885 > 192.168.0.150.ssh: S 2849765595:2849765595(0) win 65535 <mss 1420,nop,wscale 4,nop,nop,timestamp 1686273495 0,sackOK,eol> (DF)
22:33:20.665826 WAN Address.49885 > 192.168.0.150.ssh: S 2849765595:2849765595(0) win 65535 <mss 1420,nop,wscale 4,nop,nop,timestamp 1686275589 0,sackOK,eol> (DF)
22:33:24.709605 WAN Address.49885 > 192.168.0.150.ssh: S 2849765595:2849765595(0) win 65535 <mss 1420,sackOK,eol> (DF)

An example of a completed TCP handshake:

10:41:24.547759 192.168.222.20.45334 > 192.168.222.10.22: S 2228673326:2228673326(0)
    win 16384 <mss 1460,nop,nop,sackOK,nop,wscale 3,nop,nop,timestamp 976484773 0> (DF)
10:41:24.548305 192.168.222.10.22 > 192.168.222.20.45334: S 1527702330:1527702330(0) ack 2228673327
     win 16384 <mss 1460,nop,nop,sackOK,nop,wscale 3,nop,nop,timestamp 4149019602 976484773> (DF)
10:41:24.548327 192.168.222.20.45334 > 192.168.222.10.22: . ack 1 win 2048 
    <nop,nop,timestamp 976484773 4149019602> (DF)

I never played with vether interfaces. Several years ago I set up a bridged firewall with 3 NICs. Two NICs without an IP address formed the bridge. The third NIC had an IP to make remote administration from the local LAN possible.

If you can ssh into the box from the the local LAN, it probably is an routing issue.
The ssh server does not know which route it should use to reply to the public WAN address. You could try to add a default route with the -iface modifier:

# route add default 192.168.0.150 -iface

From route(8):

-iface        ~RTF_GATEWAY     destination is directly reachable

In the past I have used this -iface modifier to connect two boxes with a UTP cross cable. One OpenBSD box had a 192.168.0.0/24 address, the other box running FreeBSD had a 10.0.0.0/24 address.