Setup for Home remote acces using two routers

Installing and Using OpenWrt Network and Wireless Configuration
1

Hello everyone,

I did not found any answer to this. I need help on how to setup my routers in such a way that I will be able to access my network from other city, in a secure way.

image
image880×355 14.4 KB

I have something that look like the image above. My first plan was to put the ISP Router in bridge mode (to just provide the internet access), and the OpenWrt as the main router. But the issue with this approach is that I would no longer have Wifi access at home in the first floor (where the ISP router is).

My second idea is to keep the ISP router as the main one, and configure the OpenWrt router to AP mode (connecting via ethernet cable the LAN port from ISP router to the WAN port of the OpenWrt router). Is this a good idea?

But then, how (with this AP setup) would I access my computer from another city?
I was thinking in setting a DDNS service on the ISP router and do a port forwarding to the OpenWrt router. Also, since I am behind a CGNAT, I was thinking in using IPV6, not sure if this is going to work.

Final question, does installing WireGuard on the OpenWrt router give me an extra layer of security (I am concerned with my computer exposition)?

Thank you

2

If you are using wifi on the ISP router, and you want to be able to have all your devices on the same network (i.e. easiest way to allow them all to connect to each other), then yes, a dumb AP configuration is the best option here.

The dumb AP guide will tell you to connect via the lan port. However, if you want to use the wan port, that can often be done with a minor edit to the config after you are done with the general dumb AP setup.

This can still work... but...

You have a few options -- IPv6 is the most likely to work assuming the ISP is giving you proper public IPv6 addresses. The CGNAT for IPv4 will make using IPv4 harder, but not impossible if you don't mind setting up a 3rd system -- a virtual private server that you'd spin-up and configure a WG 'middle man' that that your home and remote peers would both use as their connecting point. It's more work, for sure.

No, this will have zero effect on your computer's security.

1 Like
3

What about ZeroTier or TailScale, either on the OpenWrt router (not sure if this can be done in AP mode) or on your endpoint devices? ZeroTier can use IPv6 to avoid trying to traverse double NAT; I assume but can't confirm the same for TailScale.

1 Like
4

I haven't used ZT or TS, but they should theoretically work, and yes, they are designed to be able to negotiate CG-NAT/double-NAT.

1 Like
5

I use ZeroTier on my own OpenWrt routers. ZeroTier's documentation explicitly says to avoid double NAT. In my own experience pre-IPv6, it didn't seem to be a big deal; I didn't notice any major instability problems while VNC'ing a remote system through CG-NAT on both ends. On the other hand, I only ever had a single device at each end communicating at any given time, which might make a difference?

Now that my ISP offers IPv6, I've "encouraged" ZeroTier to use that path instead of the CG-NATed IPv4. I can't actually tell any difference so far, but I guess it can't hurt.

It's about the only thing I use IPv6 for, hehe (since my XBox was so uncooperative about going IPv6-only).

1 Like
6

I did not know about this option.

I installed the ZeroTier on the OpenWrt router, but I do not thing that I will be able to make this work with the router in AP mode... I mean, how will the ISP router know that the incomming traffic should be directed to the OpenWrt router?

I will need to study this further. In the end I think that I will not scape from putting the ISP router in bridge mode.

7

We're getting outside of my experience here, so I can only make some guesses.

Was the OpenWrt router picked up as a member of your ZeroTier network? That's the first big thing and should tell you if ZT can traverse the ISP router. You can encourage ZT to use IPv6 if you restrict the firewall rule allowing port 9993 to IPv6 only.

What I'm most unclear about is how devices connected to the OpenWrt router will be accessed over ZeroTier if the OpenWrt router is in AP mode and not routing.

This might be a possible use-case for bridging the ZT network with your LAN or a VLAN, rather than routing? I'm not entirely sure. Hopefully one of the gurus here can offer more advice.

Here's a ZeroTier discussion about bridging vs. routing in case it's helpful:

https://discuss.zerotier.com/t/bridging-or-managed-routes/18196

1 Like
8

Typically, this can be done by enabling masquerading on the lan firewall zone, putting the VPN network into a new zone, and then allowing forwarding from the vpn zone > lan zone. In this way, the dumb AP will actually be routing (for the VPN only).

I cannot speak to ZT, though... I assume this would still work, but I have no specific experience with the protocol.

1 Like
9

That's almost the default ZeroTier "managed routes" configuration.

ZT gets its own zone, masquerading enabled, and can forward to the LAN zone. LAN can also forward to the ZT zone. But masquerading isn't enabled on the LAN.

I'm pretty clueless on this specific aspect -- could you explain what masquerading on the LAN changes for the AP setup, please? Sorry for the probably dumb question; I only know enough to be dangerous.

1 Like
10

I can speak to WG or OpenVPN (road warrior/remote-access/inbound type configs). The same applies for a guest wifi network on a dumb AP (link). I think that this would apply to ZT, but I don't have experience with it, so please take my statements with a grain of salt in the event that this isn't applicable to ZT.

A dumb AP can be viewed in the context of 'just another device on the lan' since it has an address on the lan and doesn't do any routing. When you add a routed protocol such as WG or OpenVPN onto a dumb AP, there are two ways to ensure that the traffic is routed properly:

  1. Setup a static route on the router so that the router knows what gateway to use to route traffic that should go back to the tunnel's subnet (this can actually be done at the host level, but that is typically not the best option; depends on the situation).
    --or--
  2. enable masquerading on the lan firewall zone (as described earlier) so that the traffic appears to originate from (and should be returned to) the dumb AP device that is actually running the VPN.

Let's say that we have a lan of 192.168.1.0/24, a dumb AP on say 192.168.1.2, and a WG or OpenVPN subnet of 192.168.9.0/24 (setup on the dumb AP). We'll also assume (in the case of WG/OpenVPN) that the main router is port-forwarding the listen port to the dumb AP at 192.168.1.2.

We can make a connection to the VPN server from outside, and our remote device/peer/client will have an address on the tunnel subnet (192.168.9.0/24). Now, the dumb AP has traffic with source address 192.168.9.x that is destined for hosts on the lan (192.168.1.0/24) and/or the internet.

The traffic can egress the dumb AP and then there will be packets with the source address in the .9.0/24 subnet. A host on the lan may get that packet, but now it doesn't know how to send a reply -- yes, it'll set a destination address matching earlier the source address, but then it is sent to the main router because the host doesn't know what gateway to use for the 9.0/24 subnet.

The main router also doesn't know where to send the traffic, so option 1 is that we set up a static route that is 192.168.9.0/24 via 192.168.1.2 (i.e. 192.168.1.2 exists on the network you know about -- send all traffic that is destined for the .9.0/24 network to that .1.2 and it will take care of the rest.

Or, alternatively, we enable masquerading on the lan firewall zone of the dumb AP. When masquerading is enabled, all traffic is routed and the source address upon egress form the dumb AP (towards the lan/main router) is modified to be itself (192.168.1.2). At this point, all of the hosts and the main router itself on the upstream network (lan) are unaware of the .9.0/24 network, but they see a source address of 192.168.1.2, so they know to send all replies back to that same address (it's on the same network so it's just L2, no gateways/routing involved). When the traffic returns to the dumb AP, it routes back to the VPN tunnel as appropriate based on the principle of NAT masquerading.

Does that help explain it?

3 Likes
11

Yes, that's much clearer! Thank you for such a detailed (but straightforward) explanation.

It will be interesting to see if this works for @rs75.

1 Like
12

Thank you for the detailed explanations @psherman :smiley: I will work through it and post the results here once I finish.

13

I have many questions, and I am confident that they are all dumb. But I am struggling with this setup, and I do not know how to advance.

Regarding the subnet: I am following the "Guest Wifi net on dumb AP" guide (masquerading option). But I did not follow "3. Firewall Part 2 - Firewall traffic rules" onwards and did not set DHCP for the subnet. Is this correct?

Also, it is not clear for me how the OpenWrt clients will connect to the subnet (192.168.9.x)?

I will try with WireGuard instead of ZeroTier.

14

Sorry for the late reply, I thought I hit "Post" on this but it was just sitting there as a draft.

If this is going to work in the typical way, you'll want to add a "managed route" in your ZT network configuration. That's at the top of the "Advanced" section of the ZT network page. There should already be a default route called "LAN" that's just the subnet of your ZT network. For the new route, "Destination" will be your LAN subnet behind the router (i.e. 192.168.9.0/24 following your example) and "Via" will be the ZeroTier address of your router (you might want to set that to a static IP down in the "members" section to make sure it can't change).

That route tells the rest of your ZT network to talk to your local devices (192.168.9.x) through the OpenWrt router. From another member, you should be able to connect to one of those devices by just specifying that local IP (i.e. ssh user@192.168.9.103 from a remote member should go over your ZT network to the local device).

Hopefully @psherman will weigh in on your other questions.

2 Likes
15

Thank you for the clarifications. Is it possible to make the VPN subnet (i.e. 192.169.9.0) to be vinculated only with my physical WAN port? I mean, I will have my PC connected to the WAN port (from the openwrt router) only i.e. the other devices/clients connected to the LAN ports/Wireless don't need to be in the separated VPN subnet.

My use case is to access my PC via VPN when I'm not at home. The idea is to turn it on using WoL (form the physical WAN port) to work remotely on it. I can use ZT, but I think I'd rather use WG, since there would be no third party in the middle.

Not sure if this is possible and how to accomplish that. I read somewhere that it doesn't matter if I am behind a CGNAT, since my ISP provides a proper IPv6 address.

I tried to find a solution in the forum, but I do not understand many of the answers due to my lack of knowledge/experience.

Sorry for all these questions and thank you for your patience so far.

16

Zerotier is designed to push static routes to the clients, so in a basic site-to-site use case there is no need to NAT into a Zerotier tunnel-- use symmetric routing. On your zerotier account, configure a route to each lan via that site's Zerotier tunnel IP. For symmetric routing to work, the two LANs and the tunnel must be all unique IP subnets. Place the zerotier interface in the lan firewall zone not wan. This assumes you trust everything in both lans. It is also possible to define a new zone (without masquerade) and write more restrictive firewall rules in and out of the zerotier tunnel.

Zerotier will automatically use IPv6 for the outer (encrypted) connection if the router has usable IPv6 service. zerotier-cli peers will show the IP type of the outer connections.

I don't know if WoL works at layer 3 allowing you to send wake-up packets through a tunnel. You may need to run a process on the local router to send the wake-up packets. Once the PC is awake of course you can reach it through the layer 3 tunnel.

17

I followed this guide.

cat /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'
        option ula_prefix 'EDITED'
        option packet_steering '1'

config device
        option name 'br-lan'
        option type 'bridge'
        list ports 'lan1'
        list ports 'lan2'
        list ports 'lan3'
        list ports 'lan4'

config interface 'lan'
        option device 'br-lan'
        option proto 'static'
        option ipaddr '192.168.0.2'
        option netmask '255.255.255.0'
        option ip6assign '60'
        option gateway '192.168.0.1'
        list dns '8.8.8.8'

config interface 'vpn'
        option proto 'wireguard'
        option private_key 'EDITED'
        option listen_port '51820'
        list addresses '192.168.9.1/24'
        list addresses 'EDITED'

config wireguard_vpn 'wgclient'
        option public_key 'EDITED'
        option preshared_key 'EDITED'
        list allowed_ips '192.168.9.2/32'
        list allowed_ips 'EDITED'

cat /etc/config/wireless

config wifi-device 'radio0'
        option channel '1'
        option band '2g'
        option htmode 'HE20'
        option cell_density '0'

config wifi-device 'radio1'
        option channel '36'
        option band '5g'
        option htmode 'HE80'
        option cell_density '0'

config wifi-iface 'wifinet0'
        option device 'radio0'
        option mode 'ap'
        option ssid 'EDITED'
        option encryption 'psk2'
        option key 'EDITED'
        option network 'lan'

config wifi-iface 'wifinet1'
        option device 'radio1'
        option mode 'ap'
        option ssid 'EDITED'
        option encryption 'psk2'
        option key 'EDITED'
        option network 'lan'

cat /etc/config/firewall

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

config zone 'lan'
        option name 'lan'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'ACCEPT'
        list network 'lan'
        option masq '1'

config zone 'wan'
        option name 'wan'
        option input 'REJECT'
        option output 'ACCEPT'
        option forward 'REJECT'
        option masq '1'
        option mtu_fix '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'

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 forwarding
        option src 'lan'
        option dest 'wan'

Not sure if the WG subnet is configured as expected for this scenario? Is there anything else I need to do to connect remotely?

Also, is it possible for this VPN configuration to be restricted only to the physical WAN port?

Another question, what I need to do on my ISP router? I understand that I need to do some port-forwarding, but I do not know how. Also, because of the CGNAT, I need to use the IPv6 address from the main router to reach from outside, correct?

18

The general wireguard config looks fine, but it's not associated with a firewall zone.

Add this:

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

config forwarding
        option src 'vpn'
        option dest 'lan'

Not if the wan port is part of the upstream network. But if you had some entirely separate network on the wan port, sure.

I can't speak to your specific ISP router, but in general, you'll look for the port forwarding options and then forward UDP port 51820 to the 192.168.0.2.

If your main router's IP is still in the CG-NAT range, the above port forwarding won't work. You'll need to do a similar thing in terms of accepting the IPv6 traffic on that port destined for your OpenWrt router.

19

It is not an issue to have a separate network on the wan, I just do not know how to do this. I understand that I need to use the eth0 device. That means that the lan ports and the wan port can't be bridged, correct? The devices that are connected using the Wifi / LAN ports are under 192.168.0.2 network (no DHCP, no NAT, no firewall , with gateway at 192.168.0.1). And the device that will connect to my WAN port is the same, but it will have the VPN firewall zone . Is this correct?

Yes, the main router is in the CG-NAT range. But I have a IPv6 that I can use. Could you elaborate what is the similar thing that I will need to do?

20

Tactically setting this up isn't usually difficult, but let's actually take a step back...

Your title asks for "home remote access" -- can you clarify what that means in your situation? The reason I'm asking for this is because if your goal is to be able to access network resources when you are away from home, the implication is that they are part of your normal lan. If you were to move some or all of them to another network, then the dumb AP that you're using would be kind of pointless since the idea (normally) is that you want to join your network via wifi when you are home... if the networks are isolated from each other, that might defeat the purpose... but maybe I'm not understanding exactly what you are trying to achieve.

Can you provide more detail?