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?
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!
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'
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.
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.
Check the runtime configuration:
ip a; ip r; ip ru; iptables-save; wg
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.
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.
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.
1 Like
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.
I will have a look at it, any specifics I should watch out for that might be off in my config?
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.
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?
@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.
1 Like
Do you have masquerade enabled on the VPN interface?
If so, you may need to exclude that LAN from the masquerading.
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)?
@cpunk as mentioned above I tried many combinations. Everytime I set allowed ips on the sever to something from the LAN side, and turn on the create routes checkbox, I end up with the address range being inaccessible from the router, which also meant I locked myself out a few times.
On the client it seems, I need to set 0.0.0.0 for tunsafe to create a route that will be used. Which is not really what I want but workable. I could still correct it manually with a script.
@lleachii i tried with and without masquerading on the Wireguard interface. Did not make difference as far as I could tell.
You shouldn't need the LAN address range in allowedIPs on the server. Not unless you need hosts on intranet to access LAN hosts via the tunnel (making VPN client a router). On the server the only thing you should have in allowedIPs for a peer is that peer's tunnel IP address with a /32 mask, to tell wg to send only traffic to that one host down the tunnel.
On the client side you need what you said you were using in your initial post (I think you set it then on the server though, which is not correct) - both the full tunnel IP range and the intranet IP range in allowedIPs. You say you'e using all zeroes currently, and that should work, as long as you only want the VPN client to communicate with tunnel and intranet hosts while connected. If it needs to communicate with the Internet while connected then you should use only the required two network addresses in allowedIPs. This will ensure the client can still use it's default route to talk to real IPs on the Internet.
Saying that you tried lots of things is not so helpful. If you want to troubleshoot further it would be helpful if you pasted the current WG config from each side in a reply, along with the wg show output from the router after a connection attempt, along with a specific explanation of what test you did and the result. For example: While this configuration was active I pinged from VPN client 10.0.4.2 to intranet host 192.168.100.x and got 0 replies, but ping from that same host to the intranet-side interface of the VPN router 192.168.100.1 was successful. Or something like that. And then pull the iptables -L -v output, after the test was done.
Fully understood, but I only have access and limited time on the weekends to the box. So I can not post things right now and when I can, the turnaround times via the forum are usually too long. So this is the best I can do right now.
To my understanding the router is not correctly forwarding the packets from the wg interface to the intranet or back from the intranet. I tried all so far described combinations of allowed ips including the one you mentioned should be correct.
I can try to figure out what is going on again maybe on Saturday evening CET.
Thanks again for the help! It is very much appreciated.
@cpunk, please, note that I already asked the comprehensive runtime diagnostics and we are still waiting.