Dropbear not listening properly on wireguard ip?

Installing and Using OpenWrt Network and Wireless Configuration
1

I have wireguard talking between two routers. Works generally fine. I can ssh from the server router to the client router, but strangely I can not ssh from the client router to the server router. In each case I am using their private wireguard-specific ip addresses. Ping works in both directions.

Is there a reason dropbear server would not be listening properly on the wg interface? It looks below like it is listening everywhere.

# netstat -ltn | grep 22
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN
tcp        0      0 :::22                   :::*                    LISTEN

[Peer]
AllowedIPs = 0.0.0.0/1, 128.0.0.0/1      # this is same on client & server
2

Ssh from client to server fails as follows (with odd blank line):

# ssh root@192.168.209.1

ssh: Connection to root@192.168.209.1:22 exited: Connect failed: Connection refused
3

On the server side modify:

AllowedIPs = WG_CLIENT_IP/32
4

On the server I changed the config from

AllowedIPs = 0.0.0.0/1, 128.0.0.0/

to

AllowedIPs = 0.0.0.0/1, 128.0.0.0/1, 192.168.209.2/32

but it does not seem to have made a different.

Also, the original AllowedIPs range spans all IP addresses so the change (in theory) should not make a difference.

5

I'd suspect it's probably a firewall issue. What's the output of cat /etc/config/firewall?

6

I had to add firewall input for WG (at the bottom). But otherwise it is vanilla.

# cat /etc/config/firewall

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

config zone 'lan'
        option name 'lan'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'ACCEPT'
        option network 'lan '

config zone 'wan'
        option name 'wan'
        option input 'REJECT'
        option output 'ACCEPT'
        option forward 'REJECT'
        option masq '1'
        option mtu_fix '1'
        option network 'wan wan6 wg0'

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

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'

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'

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

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

This is also empty

8

The wireguard interface is in the WAN zone and there's no rule to open the SSH port. Depending on your setup I'd either move the wireguard interface into the LAN zone, or put it in it's own zone and open the SSH port.

9

Why do you need these on the server?

There's no "original" value as AllowedIPs is empty by default, which means it spans no addresses.

1 Like
10

This may be it! I will check.

I am curious though. When would I want wg0 to be in WAN zone, and when would I want it in LAN? I am unclear of the tradeoffs of each of these.

11

Generally it depends on what traffic is coming through the tunnel. If you are using wireguard between trusted devices then you should be fine just putting it in the LAN zone. If, on the other hand, you were using wireguard to tunnel internet traffic through a remote host then you should probably consider having it in the WAN zone.

1 Like
12

Good point. I probably don't for what I am doing.

It would have been clearer to say "my original AllowedIPs".

13

In that case it might be useful if you posted the output of

uci export network; uci export dhcp; \
uci export firewall; \
head -n -0 /etc/firewall.user; \
iptables-save -c; \
ip -4 addr ; ip -4 ro li tab all ; ip -4 ru; wg

from both routers along with an explanation of what your setup is, then we can see if everything looks right. If you do post any output make sure to redact sensitive info like keys and public IPs.

14

Got the ssh working with a new firewall rule. Thank you!

I am curious about the benefits of putting the wg interface in it's own zone. What does it that give you?

15

It means you can apply rules to just the wg interface.

16

Mind sharing that rule? Thanks.

17

You mean firewall rules?

18

Yes. It lets you be more finely grained so, for example, you could open an SSH port for just the wg interface rather than the entire WAN zone.

19

Typically, on your own server you can trust WG enough to assign it to the LAN zone, so there's no need to expose SSH to the WAN.
A more realistic use case for a separate firewall zone is to prevent traffic leak on the WG client.

1 Like