Cannot ssh into router, double NAT but can connect via wiregard

I am working on a RPi4 router running OW. Currently, I have it in a double NAT configuration to emulate my ISP. It is connected via ethernet to my normal OW router through an unmanaged switch. The RPi4 has its own IP range. I have a wireguard interface on the RPi4 running fine.
I can connect to it from a phone and traffic flows as expected (target from the phone is is my DDNS IP address).

I cannot ssh into it from a device connected to the normal OW router if I use the DDNS address:

% ssh -p 30122 root@my.ddns.ipaddy

BUT, if I target the internal IP, it does connect.

% ssh -p 30122 root@10.20.10.238
BusyBox v1.33.1 (2021-08-30 07:28:17 UTC) built-in shell (ash)

  _______                     ________        __
 |       |.-----.-----.-----.|  |  |  |.----.|  |_
 |   -   ||  _  |  -__|     ||  |  |  ||   _||   _|
 |_______||   __|_____|__|__||________||__|  |____|
          |__| W I R E L E S S   F R E E D O M
 -----------------------------------------------------
 OpenWrt SNAPSHOT, r0+17456-a7aa237c28
 -----------------------------------------------------
#

Interestingly, I can also connect if I use a device totally outside of my network (a remote server is able to connect).

I am wondering why.

Network architecture:

modem <--> normal router <--> unmanaged switch

Everything else including my workstation and RPi4 are connected to the unmanaged switch.

Was there a question here...? :wink:

Hint: firewall

Yeah, the question is why is it not working :smiley:

The firewall is setup on properly I believe on both the normal router (forwarding the port to the internal IP of the RPi4) and on the RPi4 (allowing the port from WAN zone to local device).

Since I can ssh if I directly hit the internal IP, I think that shows the firewall on the RPi4 is correct.
If I disable the forwarded port on the normal router, my connection is actively refused. If I re-enable the forwarded port, it is not actively refused, it just sits there until it times out.

please post your firewall config (/etc/config/firewall)

Did you also want to see the forwarding rule on the normal router? Note that I know it works because I can connect from a remote server.

Here it is from the RPi4:

/etc/config/firewall

config defaults
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'REJECT'
	option synflood_protect '1'

config rule
	option name 'Allow-DHCP-Renew'
	option src 'wan'
	option proto 'udp'
	option dest_port '68'
	option target 'ACCEPT'
	option family 'ipv4'

config rule
	option name 'Allow-Ping'
	option src 'wan'
	option proto 'icmp'
	option icmp_type 'echo-request'
	option family 'ipv4'
	option target 'ACCEPT'
	option enabled '0'

config rule
	option name 'Allow-IGMP'
	option src 'wan'
	option proto 'igmp'
	option family 'ipv4'
	option target 'ACCEPT'

config rule
	option name 'Allow-DHCPv6'
	option src 'wan'
	option proto 'udp'
	option src_ip 'fc00::/6'
	option dest_ip 'fc00::/6'
	option dest_port '546'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-MLD'
	option src 'wan'
	option proto 'icmp'
	option src_ip 'fe80::/10'
	list icmp_type '130/0'
	list icmp_type '131/0'
	list icmp_type '132/0'
	list icmp_type '143/0'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-ICMPv6-Input'
	option src 'wan'
	option proto 'icmp'
	list icmp_type 'echo-request'
	list icmp_type 'echo-reply'
	list icmp_type 'destination-unreachable'
	list icmp_type 'packet-too-big'
	list icmp_type 'time-exceeded'
	list icmp_type 'bad-header'
	list icmp_type 'unknown-header-type'
	list icmp_type 'router-solicitation'
	list icmp_type 'neighbour-solicitation'
	list icmp_type 'router-advertisement'
	list icmp_type 'neighbour-advertisement'
	option limit '1000/sec'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-ICMPv6-Forward'
	option src 'wan'
	option dest '*'
	option proto 'icmp'
	list icmp_type 'echo-request'
	list icmp_type 'echo-reply'
	list icmp_type 'destination-unreachable'
	list icmp_type 'packet-too-big'
	list icmp_type 'time-exceeded'
	list icmp_type 'bad-header'
	list icmp_type 'unknown-header-type'
	option limit '1000/sec'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-IPSec-ESP'
	option src 'wan'
	option dest 'lan'
	option proto 'esp'
	option target 'ACCEPT'

config rule
	option name 'Allow-ISAKMP'
	option src 'wan'
	option dest 'lan'
	option dest_port '500'
	option proto 'udp'
	option target 'ACCEPT'
	option enabled '0'

config rule
	option name 'Support-UDP-Traceroute'
	option src 'wan'
	option dest_port '33434:33689'
	option proto 'udp'
	option family 'ipv4'
	option target 'REJECT'
	option enabled '0'

config include
	option path '/etc/firewall.user'

config zone 'lan'
	option name 'lan'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'REJECT'
	list device 'br-main.1'
	list network 'lan'
	list network 'wg0'

config zone 'wan'
	option name 'wan'
	option output 'ACCEPT'
	option masq '1'
	option mtu_fix '1'
	option forward 'REJECT'
	list device 'br-wan'
	list network 'wan'
	option input 'ACCEPT'

config zone
	option name 'guest'
	option output 'ACCEPT'
	option forward 'REJECT'
	list device 'br-main.3'
	option input 'REJECT'
	list network 'guest'
	list network 'LXCGUEST'

config rule
	option name 'guest ping'
	list proto 'icmp'
	option src 'lan'
	option dest 'guest'
	option target 'ACCEPT'

config rule
	option name 'guest dhcp'
	list proto 'udp'
	option src 'guest'
	option dest_port '67 68'
	option target 'ACCEPT'

config rule
	option name 'guest dns'
	list proto 'tcp'
	option src 'guest'
	option dest_port '53'
	option target 'ACCEPT'

config forwarding 'lan_wan'
	option src 'lan'
	option dest 'wan'

config forwarding
	option src 'guest'
	option dest 'wan'

config forwarding
	option src 'lan'
	option dest 'guest'

config rule
	option name 'incoming ssh'
	option target 'ACCEPT'
	list proto 'tcp'
	option dest_port '30122'
	option src 'wan'

config rule 'wg'
	option name 'Allow-WireGuard'
	option dest_port '51820'
	option proto 'udp'
	option target 'ACCEPT'
	option src 'wan'

did you change your dropbear listening port?

Yes, I have two dropbears running, one on 22 and another on 30122 and again, I can connect from an external server. I can also connect hitting the internal IP from my workstation. I just cannot connect hitting my DDNS IP address from the workstation. So odd.

Where is the workstation relative to the OpenWrt router? Is it on the WAN side (i.e. within the first NAT) or on the LAN side (double-NAT) of the OpenWrt router?

Both the work station and the RPi4 are physically connected to the same unmanaged switch.

[modem] <--> [normal router] <--> [unmanaged switch]
                                        |     |
                                        |     |
                                        |     |
                             [work station]  [RPi4]

So I think it's on the WAN side (within the first NAT) using your terminology.

It is actually not clear if that is the WAN or LAN side, actually, since the ethernet port could be configured as LAN or WAN. It is likely that it is the WAN in your situation because you said WG works. But just to be sure, please post your /etc/config/network file.

Also, with respect to the workstation ssh connections -- if you use the address of the RPi4 on the LAN (rather than your DDNS or external IP address), does it connect?

You may want to post your dropbear config as well. Are you sure the 30122 port instance is listening on WAN?

1 Like
/etc/config/network

config interface 'loopback'
	option device 'lo'
	option proto 'static'
	option ipaddr '127.0.0.1'
	option netmask '255.0.0.0'

config globals 'globals'

config device
	option name 'br-main'
	option type 'bridge'
	list ports 'eth0'
	option ipv6 '0'

config interface 'lan'
	option proto 'static'
	option ipaddr '10.9.7.1'
	option netmask '255.255.255.0'
	option device 'br-main.1'

config interface 'wan'
	option proto 'dhcp'
	option peerdns '0'
	option delegate '0'
	list dns '1.1.1.1'
	list dns '1.0.0.1'
	option device 'br-wan'

config bridge-vlan
	option device 'br-main'
	option vlan '1'
	list ports 'eth0'

config bridge-vlan
	option device 'br-main'
	option vlan '3'
	list ports 'eth0:t'

config device
	option name 'br-main.1'
	option type '8021q'
	option ifname 'br-main'
	option vid '1'
	option ipv6 '0'

config device
	option name 'br-main.3'
	option type '8021q'
	option ifname 'br-main'
	option vid '3'
	option ipv6 '0'

config device
	option type 'bridge'
	option name 'br-wan'
	list ports 'eth1'
	option ipv6 '0'

config interface 'guest'
	option proto 'static'
	option device 'br-main.3'
	option ipaddr '172.16.1.1'
	option netmask '255.255.255.0'
	list dns '1.1.1.1'
	list dns '1.0.0.1'

config interface 'wg0'
	option proto 'wireguard'
	option private_key 'xxx'
	option listen_port '51820'
	list addresses '192.168.9.1/24'

config wireguard_wg0
	option description 'me'
	option public_key 'xxx'
	list allowed_ips '192.168.9.2/32'
	option route_allowed_ips '1'
	option preshared_key 'xxx'

config device
	option name 'wg0'
	option ipv6 '0'

config device
	option type 'bridge'
	option name 'br-guest'
	list ports 'br-main.3'
	option ipv6 '0'

config interface 'LXCGUEST'
	option device 'br-guest'
	option proto 'static'
	option ipaddr '10.0.4.1'
	option netmask '255.255.255.0'
	option auto '0'

config device
	option name 'eth0'
	option ipv6 '0'

config device
	option name 'eth1'
	option ipv6 '0'

Yes, if I use the address of the RPi4 from the workstation (ie not going out via DDNS) it works. It does not work if I use the DDNS IP address. But again, I am forwarding 30122 and I can connect to it from a remote server so this is really confusing to me.

/etc/config/dropbear
config dropbear
	option PasswordAuth 'on'
	option Port '22'
	option Interface 'lan'

config dropbear
	option Port '30122'
	option verbose '1'
	option PasswordAuth 'off'
	option RootPasswordAuth 'off'

Yes, it is listening.

This sounds like a NAT Loopback issue

Are you able to establish a WG connection from the same workstation that you are using to test ssh?

1 Like

Have not tried that. I should probably pull the plug on this and thank both you @psherman and @stangri for helping with this. Great community here but this is more trouble to figure out that it's worth :smiley: