Configure Routing to get LAN access via Wireguard

tharwan · August 14, 2019, 6:12pm

Hi there,

I can currently not provide any configuration files as I do not have access to the hardware, however I think I am struggling more with the concept anyway.

I have the following setup, I have two LAN networks. One of them has an Internet connection the other one does not. I would like to "dial" into the not internet connected LAN (intranet) from the other. I set up a router dedicated as VPN access point. Wireguard seems to be the only VPN to give decent speed.

So setup is the following:
Internet <-> Router <-> LAN (192.168.2.0) <-VPN Router-> Intranet (192.168.100.0)

I managed to setup Wireguard together with tunsafe just fine.

The interfaces and firewall are setup like here. So the VPN interface is it its own firewall zone. The ips in the tunnel are 10.0.4.0/32. On the client the allowed ips are set to 192.168.100.0/24.

The problem I am struggeling with is that I can not reach the Intranet clients (192.168.100.x) from the machine dialed in via VPN. I can reach the VPN router on its Intranet adress and login into the config page. The VPN router can also ping the other Intranet clients.

I set the allowed ips in the tunnel to 10.0.4.0/24 and 192.168.100.0/24. If I turn on route_allowed_ips things go haywire and I can not reach the Intranet behind the VPN router anymore from the router itself.

So what to I need to do so I can reach the Intranet behind the VPN router? Do I need to add some route from the tunnels ip range to the the Intranet? Is there something missing on the client?

I would appreciate any hints or help. Thanks in advance, the topic drove me mad last weekend.

mikma · August 14, 2019, 7:22pm

Wasn't the client located in 192.168.2.0/24? Allowed ips are the remote IP addresses you want to allow on the given peer.

Having two network in your description with the same name "LAN" doesn't make it easier to follow...

tharwan · August 14, 2019, 7:57pm

You are right sorry about, I changed it to intranet, and the other one was a typo. The tunsafe client adds a local route to 192.168.100.0/24.

mikma · August 14, 2019, 8:22pm

Is this on the client? You already mentioned 192.168.100.0/24 was used on the client before.
What's allowed ips on the VPN router?

tharwan · August 14, 2019, 8:35pm

No, I this is on the server. In the Client I set it to only 192.168.100.0/24 which I guess it is needed so the client knows where to look. I tried multiple things on the server, allowing 10.0.4.0/24 and or 192.168.100.0/24. Do I need to set this to the clients ip on the server?

tharwan · August 15, 2019, 11:35am

I am not sure how to do this with tunsafe, or if this is even necessary with tunsafe. I believe the error is, as was pointed out by @mikma, the allowed ips on the VPN router. I just did not realize how this was meant to work.

Either way I will keep it in mind and try it out if the solution suggested from @mikma does not work.

Thanks!

tharwan · August 17, 2019, 11:31am

So setting the allowed IPs on the VPN router to include the LAN addresses did not help, infact int resulted in a config where I could not reach the VPN router on the WAN site anymore. So no VPN connection at all.

I set the client to now route all trafic towads the VPN, because I found that @vgaetera was indeed partially correct, the route that tunsafe added was not used. Anyway it is now, but not very successful. If I do a traceroute on the client I get:

tracert 192.168.100.36
 1     5 ms     5 ms    33 ms  10.0.10.1
 2     *        *        *
....

So the client is now trying to reach 192.168.100.36 via the VPN endpoint in the VPN router, but then nothing happen?

Any ideas how I can proceed? It still feels like there is only a small thing missing....

cat /etc/config/firewall 

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

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

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

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 zone
	option name 'VPN'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option network 'VPN'
	option forward 'ACCEPT'

config rule
	option src '*'
	option target 'ACCEPT'
	option proto 'udp'
	option dest_port '51863'
	option name 'Allow-Wireguard-Inbound'

config forwarding
	option src 'lan'
	option dest 'VPN'

config forwarding
	option dest 'lan'
	option src 'VPN'

config forwarding
	option dest 'wan'
	option src 'VPN'

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

vgaetera · August 17, 2019, 12:21pm

Actually, I tested it yesterday using OpenWrt as a client and server and both methods work for me.
Make sure the destination host firewall allows incoming traffic outside of the local subnet.

tharwan · August 17, 2019, 4:56pm

Well thats good to know, but it does not help me too much. I know that other VPN solutions already worked (but too slow) so I think there is no issue with the firewalls on the clients.

vgaetera · August 18, 2019, 5:14am

Check the runtime configuration:

ip a; ip r; ip ru; iptables-save; wg

tharwan · August 18, 2019, 6:00pm

Yeah. Thanks for the help, but I think I have to abandon this for now. Takes to much time, so I will buy some commercial solution.

SirToffski · August 18, 2019, 6:25pm

I've actually just posted my config which includes wireguard. Internal LAN is reachable given proper rules on the router are present. Link to the post. Maybe it will help somewhat.

vgaetera · August 19, 2019, 11:00am

Well, it's your money and you decide how to spend it, but I think it's better pay someone to set up a WireGuard based solution than become vendor-locked.

tharwan · August 19, 2019, 11:16am

Any suggestions of who to pay?

Other than that, if WireGuard and tunsafe work more stable I can still switch there. This is only about 2 clients. No real vendor lock-in either way.

tharwan · August 19, 2019, 11:18am

I will have a look at it, any specifics I should watch out for that might be off in my config?

cpunk · August 20, 2019, 2:27pm

I think it would help if you explain the configuration more clearly, along with what isn't working. Part of it is the diagram - you're not making it clear which network the VPN Router is on. If I understand it, this seems to be what's happening.

Hosts:
VPN Router on Intranet network, using IPs 192.168.100.1/24 on ethernet and 10.0.4.1/24 in the tunnel.
VPN Client in LAN, using IPs 192.168.100.?/24 on ethernet and 10.0.4.2/24 in the tunnel.
Is that correct?

If it is what you have set up, then In that scenario you want the VPN Client to have AllowedIPs = 10.0.4.0/24, 192.168.100.0/24 so that it can reach both networks. The VPN Router has the peer configuration for the client, and that should have AllowedIPs = 10.0.4.2/32.

Once you set that up, try to make the connection from client and then run 'wg show' on each end. That should show a handshake for the remote peer on each side (if you can't do this command on the client side then just look at it on the router end). See this page for an example with a "latest handshake".

If you don't show a recent handshake for the peer, then the traffic to establish the connection is not getting through. That's probably a network issue (wrong IP, mismatched ports, routing to the public IP not working, etc), a firewall issue on either end (port not open), or wrong keys used.

If you have a handshake but can't send traffic through, then it's probably an allowedips issue, or routing problem on the VPN router.

You can investigate these kinds of issues a bit more using 'iptables -L -v', which will show how many packets are passing through your iptables rules. Zero them first with 'iptables -Z', then do some testing, and run the -L -v command. See whether you can see packets pass through those rules appropriately. If you're not sure, post back with more info on the configuration (are my assumptions correct?), the wg show output, what test you tried and the iptables -L -v output.

lleachii · August 20, 2019, 5:14pm

To be clear:

you have Tunsafe VPN setup on your device
but then you want to connect to your router directly; and use Tunsafe Internet via a second Wireguard connection

Does the location you'll be connecting from remotely have a static IP address?
Did you setup 2 different Wireguard interfaces?

tharwan · August 20, 2019, 5:40pm

@lleachii I don’t want to do any of that, I want to separate two local networks so that one has no internet connection and I can only „dial“ into it from the other local network

@cpunk I am not sure what you mean, or what I can explain better. The VPN Router is part of two networks one LAN (192.168.100.0) side one WAN (192.168.2.0) side. The tunnel ips are correct as you stated them too. The connection is not the problem, this works just fine.

I just can not reach anything behind the VPN router except the VPN router itself. I will try to look at the routing as you suggested if I find the time, seems like something useful to learn.

lleachii · August 20, 2019, 5:47pm

Do you have masquerade enabled on the VPN interface?

If so, you may need to exclude that LAN from the masquerading.

cpunk · August 20, 2019, 7:28pm

The tunnel ips are correct as you stated them too. The connection is not the problem, this works just fine.

What about the AllowedIPs entries on each end (VPN Router and Client)?