Where does that DNS point to now?
Where did these requests come from?
The request come from the Internet / WAN zone without VPN.
I have started from the scratch a 2nd time, with a little progress.
I can access from the 192.168.210.178 Windows Client the NAS with 192.168.200.10 via VPN. That works.
I can access the OpenWrt LuCi GUI under 192.168.210.1 from any client in the 192.168.200.0/24 subnet.
I cannot access a client in the 192.168.210.0/24 subnet besides the Router itself. And I don’t understand why.
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'
option ula_prefix 'fd39:***:0f4d::/48'
config device
option name 'br-lan'
option type 'bridge'
list ports 'eth1'
config interface 'lan'
option device 'br-lan'
option proto 'static'
option ipaddr '192.168.210.1'
option netmask '255.255.255.0'
option ip6assign '60'
config interface 'wan'
option proto 'static'
option device 'eth0'
option ipaddr '20*******.221'
option netmask '255.255.0.0'
option gateway '20******6.1'
list dns '94.140.14.15'
config interface 'Neckarsulm'
option proto 'wireguard'
option private_key 'GMwcTGP/xE6uKisN5*****************'
option listen_port '45312'
list addresses '10.10.10.1/24'
config wireguard_Neckarsulm
option description 'Neckarsulm-Keenetic'
option public_key 'rjHi4N9D*****'
option endpoint_host 'nsu.g******au.se'
option endpoint_port '45312'
option persistent_keepalive '25'
option route_allowed_ips '1'
list allowed_ips '192.168.200.0/24'
list allowed_ips '10.10.10.2/32'
list allowed_ips '10.10.10.0/24'
config device
option name 'Neckarsulm'
option acceptlocal '1'
config route
option interface 'Neckarsulm'
option target '192.168.200.0/24'
Firewall
config defaults
option input 'REJECT'
option output 'ACCEPT'
option forward 'REJECT'
option synflood_protect '1'
option flow_offloading '1'
config zone
option name 'lan'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
list network 'lan'
config zone
option name 'wan'
option input 'REJECT'
option output 'ACCEPT'
option forward 'REJECT'
option masq '1'
option mtu_fix '1'
list network 'wan'
list network 'wan6'
config forwarding
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 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 rule
option name 'Allow-HTTP'
option src 'wan'
option dest_port '80'
option target 'ACCEPT'
option enabled '0'
config rule
option name 'Allow-HTTPS'
option src 'wan'
option dest_port '443'
option target 'ACCEPT'
option enabled '0'
config zone
option name 'vpn'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
list network 'Neckarsulm'
config forwarding
option src 'vpn'
option dest 'lan'
config forwarding
option src 'lan'
option dest 'vpn'
config rule
option name 'Neckarsulm-nach-LAN'
option src 'vpn'
option dest 'lan'
option target 'ACCEPT'
list proto 'all'
- I have Neckarsulm-to-LAN-Allow-Everything rule.
- I have no port forwarding (yet)
- I Wireguard traffic rule is not needed…to my surprise…to acces LuCi via VPN.
When I run traceroute from a 192.168.200.0 client to 192.168.210.10, the route stops at 10.10.10.1, which is the wireguard address of OpenWrt…
Delete thes
Remove the last line here:
Delete this:
Delete that as I mentioned above -- it doesn't do anything since you already have a vpn > lan forward.
This is because the firewall zone that contains the Wireguard network has input = ACCEPT.
After making the changes, restart the router and test again. If it doesn't work, provide the updated configs as well as that of the other side.
Are you sure about deleting this route and the Wireguard Device named Neckarsulm? This is - in my understanding - the way to go from the OpenWrt to the remote system?!?
The device and routing are already set up by the wireguard interface. You don't need to add them separately.
As soon as I disable the route to the Remote Neckarsulm network, die LAN client 192.168.210.178 cannot access the Neckarsulm 192.168.200.10 with its Web GUI.
Restart the wireguard interface after you disable the rule.
To be clear, these are not valid which is why they must be deleted.
- the interface already exists, so creating a 'device' is not needed.
- the route is already defined in the wireguard interface's peer configs (under the allowed_ips section), and route_allowed_ips is also enabled which means the route is fully defined in the routing table.
- Because of #2, you don't need to (and shouldn't) define the same route again
- the route is meaningless if you define a target but no gateawy. But again, because of 2 and 3, it shouldn't be there anyway.
If it still doesn't work properly after a restart of the WG interface, try rebooting the entire router. If it still doesn't work, let's see the latest complete configs.
I confess, I am surprised, that it‘s working. Great.
Next step, I want to access a browser site across the networks:
- From 192.168.210.178 I can open https://192.168.210.10:9443 (Portainer)
- From a 192.168.200.0/24 client, I cannot.
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'
option ula_prefix 'fd39:****:0f4d::/48'
config device
option name 'br-lan'
option type 'bridge'
list ports 'eth1'
config interface 'lan'
option device 'br-lan'
option proto 'static'
option ipaddr '192.168.210.1'
option netmask '255.255.255.0'
option ip6assign '60'
config interface 'wan'
option proto 'static'
option device 'eth0'
option ipaddr '***.***.197.221'
option netmask '255.255.0.0'
option gateway '***.***.196.1'
list dns '***.***.14.15'
config interface 'Neckarsulm'
option proto 'wireguard'
option private_key '****************sN5wRTtf0XPJUF9ZSkdfxqnyjfQGs='
option listen_port '45312'
list addresses '10.10.10.1/24'
config wireguard_Neckarsulm
option description 'Neckarsulm-Keenetic'
option public_key 'rjHi4N9DGw6*******'
option endpoint_host 'n*********zuhau.se'
option endpoint_port '45312'
option persistent_keepalive '25'
option route_allowed_ips '1'
list allowed_ips '192.168.200.0/24'
list allowed_ips '10.10.10.0/24'
Firewall
config defaults
option input 'REJECT'
option output 'ACCEPT'
option forward 'REJECT'
option synflood_protect '1'
option flow_offloading '1'
config zone
option name 'lan'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
list network 'lan'
config zone
option name 'wan'
option input 'REJECT'
option output 'ACCEPT'
option forward 'REJECT'
option masq '1'
option mtu_fix '1'
list network 'wan'
list network 'wan6'
config forwarding
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 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 rule
option name 'Allow-HTTP'
option src 'wan'
option dest_port '80'
option target 'ACCEPT'
option enabled '0'
config rule
option name 'Allow-HTTPS'
option src 'wan'
option dest_port '443'
option target 'ACCEPT'
option enabled '0'
config zone
option name 'vpn'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
list network 'Neckarsulm'
config forwarding
option src 'vpn'
option dest 'lan'
config forwarding
option src 'lan'
option dest 'vpn'
config rule
option name 'Neckarsulm-nach-LAN'
option src 'vpn'
option dest 'lan'
option target 'ACCEPT'
list proto 'all'
option enabled '0'
There is nothing in your configuration that would prohibit this.
It likely comes down to one (or both) of the following:
-
A local (host-level) firewall on 192.168.210.10 that prevents access from other subnets. This is the default windows firewall configuration, and it is also true on some other OS firewall configurations. If you that host is running a local firewall, especially if it is Windows, turn off the firewall for testing purposes to see if it solves the problem. (This may also involve virtual host or containerized network configuration/firewalls, if those methods are in use).
-
The remote network (192.168.200.0/24) doesn't have a route to the one here. Is the remote side also running OpenWrt? Let's see that peer's configuration.
1 Like
What works is accessing the LuCi GUI via the LAN internal address 192.168.210.1 from a client inside 192.168.200.0/24.
When executing a traceroute command to 192.168.210.10, the command takes the path:
192.168.200.1 (Keenetic router)
10.10.10.1 (OpenWrt Wireguard address)
…and this is where it ends.
From where did you test the traceroute (what was the IP address of the origin)?
This does tell us that the traceroute got to the OpenWrt router. We would expect this:
192.168.200.x > 192.168.200.1 > 10.10.10.1 > 192.168.210.10
So, the last hop -- that is the target machine -- is not responding.
I am confident that there is nothing on the OpenWrt side that is causing this problem.
Did you check the possibility of a local firewall on the target device? What is the target device's operating system? Is the target service running directly on the OS, or is it virtualized or containerized?
Are there any other hosts (ideally not windows; Linux or Mac would be best) on the 192.168.210.0/24 network that you can ping/traceroute?
I have done a few traceroutes:
Windows 192.168.210.178 to Remote Router 192.168.200.1
Routenverfolgung zu 192.168.200.1 über maximal 30 Hops
1 ＜1 ms <1 ms <1 ms Router.cloud.me****u.se [192.168.210.1]
2 11 ms 11 ms 11 ms 192.168.200.1
Ablaufverfolgung beendet.
Windows 192.168.210.178 to Remote Client Synology NAS 192.168.200.10
Routenverfolgung zu 192.168.200.10 über maximal 30 Hops
1 ＜1 ms <1 ms <1 ms Router.cloud.me****u.se [192.168.210.1]
2 11 ms 11 ms 11 ms 10.10.10.2
3 12 ms 12 ms 12 ms 192.168.200.10 [NAS]
Ablaufverfolgung beendet.
From iPad in 192.168.200.0/24 to OpenWRT router 192.168.210.1
Traceroute - 192.168.210.1:
001 192.168.200.1;
002 192.168.210.1;
From iPad in 192.168.200.0/24 to a Debian client running on 192.168.210.10
Traceroute - 192.168.210.10:
001 192.168.200.1;
002 10.10.10.1;
003 *;?
As the last one stops at the OpenWRT Wireguard IP I searched the problem within OpenWRT firewall or dns…
This was the same as you showed before (target 192.168.210.10).
Do you have another host in 192.168.210.0/24 that you can ping/traceroute from 192.168.200.0/24?
Hello, unfortunately I only have two VPS running beyond OpenWrt.
Windows on 192.168.210.178
Debian on 192.168.210.10
Windows, as far as I know, needs settings in its own firewall to respond to ping signals from a remote network.
Yes, that is true. You could temporarily disable the windows firewall entirely for testing.
Also, when you say VPS -- these two hosts are virtualized? can you put any physical bare-metal devices (a pi would be fine) on that same subnet?
Unfortunately, as all three instances are VPS hosted by a provider with a VLAN to interconnect them. (I don‘t have to do the VLAN setup, just need to activate the Ethernet connection.)
So, there is no physical access for me.
I am quite confident that the issue is not with OpenWrt, but with the VM/VPS host configuration or the guest OS config within the VM. It would be really good to prove that, but the way to do this would normally be to use another device (bare metal) that is known to respond to pings from different subnets.
The Debian VPS, which is running on 192.168.210.10 behind the OpenWRT, has by default a public IPv4 address as well. My intention is to disable this one, to make hackers life at little less easier.
I can ping the Client via this public IPv4 from my MacBook (running in 192.168.200.0/24 network):
traceroute to 94.***.107.114 (94.***.107.114), 64 hops max, 40 byte packets
1 192.168.200.1 (192.168.200.1) 4.129 ms 2.987 ms 2.561 ms
2 p3e9bf54b.dip0.t-ipconnect.de (62.***.245.75) 17.272 ms 6.191 ms 6.251 ms
3 f-ed11-i.f.de.net.dtag.de (217.***.192.94) 11.509 ms 11.780 ms 11.878 ms
4 f-ed11-i.f.de.net.dtag.de (217.***.192.94) 11.075 ms 11.494 ms 11.239 ms
5 80.***.161.186 (80.156.161.186) 10.672 ms 10.944 ms 10.896 ms
6 ae1-0.bbr01.anx84.nue.de.anexia-it.net (144.***.208.140) 14.320 ms 14.454 ms 14.040 ms
7 94.***.25.155 (94.***.25.155) 13.480 ms 14.104 ms 14.181 ms
8 v2***************8515.hotsrv.de (94.***.107.114) 14.011 ms 14.123 ms 13.815 ms