Hello.
I have 2 wireguard interfaces on my openwrt router. Both work great. Now I need to send all traffic from one wireguard interface through another wireguard interface. How can this be done?
It is possible, if routed properly. That means traffic from one tunnel should be forwarded to the other one.
1 Like
Thanks for the answer. Please tell me how to do it
I assume this is for learning?
For everyday use, it is discouraged to nest VPNs for reasons like the twice-reduced MTU, the extra delay (+ throughput), and the added dependency - for practically no security benefit. Likely, there is a better solution.
Since you already have Wireguard set up, you need to make sure that the MTU is configured accordingly. If you haven't changed it, the MTU for the outer interface is going to be 1420. I suggest checking the path MTU between your router and the Wireguard gateway. The MTU of the outer interface should be the path_mtu - 60 (if you access the gateway using IPv4) or path_mtu - 80 (for IPv6).
The more important MTU is that of the inner tunnel: Again, it should be reduced by the lengths of the headers depending on the protocol used to access the inner gateway. This time, the path MTU is that of the outer interface, so you subtract 60 or 80 from the that.
Finally, for nesting tunnel connections, you need to make sure that your routes are set up correctly.
You'll probably want the outer interface to create a route to the inner gateway so that it takes precedence over the default route. If your setup allows it, you can try using route_allowed_ips = 1 and allowed_ips=$gateway_ip (see here). Otherwise, you'll have to add a static route (see here.
If you want more help, you should post what you already have (redacting the private keys, of course).
1 Like
Here's my configuration:
/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 packet_steering '1'
config device
option name 'br-lan'
option type 'bridge'
list ports 'lan1'
list ports 'lan2'
config interface 'lan'
option device 'br-lan'
option proto 'static'
option ipaddr '192.168.192.1'
option netmask '255.255.255.0'
option ip6assign '60'
option ipv6 '0'
option delegate '0'
config interface 'wan'
option device 'wan'
option proto 'pppoe'
option username 'xxxxxxxxxxxxx'
option password 'xxxxxxxxxx'
option ipv6 '0'
option peerdns '0'
config interface 'WARP'
option proto 'wireguard'
option private_key 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'
list addresses '172.16.0.2/32'
list dns '1.1.1.1'
option force_link '1'
option delegate '0'
option nohostroute '1'
config wireguard_WARP
option public_key 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'
list allowed_ips '0.0.0.0/0'
option persistent_keepalive '25'
option endpoint_host 'engage.cloudflareclient.com'
option endpoint_port '2408'
option description 'cloudflare'
config interface 'HomeNet'
option proto 'wireguard'
option private_key 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'
option auto '0'
option nohostroute '1'
option delegate '0'
list addresses '10.8.0.7/24'
config wireguard_HomeNet
option description 'openwrt_wg_server'
option public_key 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'
option private_key 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'
option endpoint_host 'xxx.xxx.xxx.xxx'
option endpoint_port 'xxxxx'
option persistent_keepalive '25'
option route_allowed_ips '1'
option preshared_key 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'
list allowed_ips '10.8.0.0/24'
list allowed_ips '10.10.0.0/24'
list allowed_ips '192.168.0.0/20'
/etc/config/firewall
config defaults
option input 'REJECT'
option output 'ACCEPT'
option forward 'REJECT'
option synflood_protect '1'
config zone
option name 'lan'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
list network 'lan'
option family 'ipv4'
config zone
option name 'wan'
option input 'REJECT'
option output 'ACCEPT'
option forward 'REJECT'
option masq '1'
option mtu_fix '1'
list network 'wan'
option family 'ipv4'
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 zone
option name 'warp'
option input 'REJECT'
option output 'REJECT'
option forward 'REJECT'
list network 'WARP'
option masq '1'
option family 'ipv4'
config zone
option name 'HomeNet'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
list network 'HomeNet'
option family 'ipv4'
config rule
option name 'lan clients to warp'
option src 'lan'
option dest 'warp'
option target 'ACCEPT'
option family 'ipv4'
list proto 'all'
config forwarding
option src 'lan'
option dest 'wan'
config include 'pbr'
option fw4_compatible '1'
option type 'script'
option path '/usr/share/pbr/pbr.firewall.include'
/etc/config/pbr
config pbr 'config'
option enabled '1'
option verbosity '2'
option strict_enforcement '1'
option resolver_set 'none'
option ipv6_enabled '0'
list ignored_interface 'vpnserver'
list ignored_interface 'wgserver'
option boot_timeout '30'
option rule_create_option 'add'
option procd_reload_delay '1'
option webui_show_ignore_target '0'
list webui_supported_protocol 'all'
list webui_supported_protocol 'tcp'
list webui_supported_protocol 'udp'
list webui_supported_protocol 'tcp udp'
list webui_supported_protocol 'icmp'
config include
option path '/usr/share/pbr/pbr.user.aws'
option enabled '0'
config include
option path '/usr/share/pbr/pbr.user.netflix'
option enabled '0'
config policy
option name 'iPhone WARP'
option src_addr '192.168.192.172'
option interface 'WARP'
option dest_addr '0.0.0.0/0'
config policy
option name 'WinBook WARP'
option src_addr '192.168.192.169'
option dest_addr '0.0.0.0/0'
option interface 'WARP'
config policy
option name 'MacBook WARP'
option src_addr '192.168.192.235'
option dest_addr '0.0.0.0/0'
option interface 'WARP'
config policy
option name 'Android1 WARP'
option src_addr '192.168.192.133'
option dest_addr '0.0.0.0/0'
option interface 'WARP'
config policy
option name 'Android2 WARP'
option src_addr '192.168.192.246'
option dest_addr '0.0.0.0/0'
option interface 'WARP'
I looked at the ip address that the provider gives me on the site https://ifconfig.co. Here I will write that the ip is from the provider "ppp.ppp.ppp.ip". Later, I set up Policy-Based Routing so that devices on the local network connect to the internet via cloudflare warp. Then I went back to https://ifconfig.co to see the ip address that cloudflare warp gave me. From here on I will call it "ccc.ccc.ccc.ip".
Then I went to the remote openwrt router to check the wireguard "homenet" connection. I saw that the connection was successful, I saw that the incoming ip is the ip issued by the provider of the first router.
Now I need to route wireguard connection "homenet" traffic through wireguard connection "warp". So that on a remote openwrt router I can see the incoming ip issued by cloudflare.
I understand that nesting vpn in vpn is not a good idea, but I really need it.
It looks like what you want is different from nesting a tunnel in a tunnel.
Correct me if I am wrong but you seem to have a WG client setup to a VPN provider (Cloudfare).
You have setup a WG server which is connected to a client (router in this case but could also be a phone on the internet etc)
You want traffic coming in from the WG server (so traffic e.g. from the connected client router) going out via the VPN tunnel to Cloud fare.
if this is the case then there is no tunnel in a tunnel , traffic from your WG server is already out of the tunnel before it enters the tunnel going to cloudfare 
It is just a matter of routing and firewall.
If the above scenario is what you want please confirm because then the solution is different from what @yogo1212 posted (although excellent written and pointing out why you actually should not want a tunnel in a tunnel)
1 Like
You need to clarify what you mean by this.
Do you mean that you want devices connected to the remote router to access the internet via the cloudflare tunnel? If so, is there a need for it to be the tunnel on the local router? Can you not just add a cloudflare tunnel directly to the remote server and route internet traffic through it?
Or do you want the 'Endpoint' for the 'homenet' connection to show the IP for the cloudflare tunnel? If it's this option, why are you wanting to send the already encrypted data through another tunnel? What's the purpose for the setup?
No, I mean that devices connected to the remote router access to the internet directly.
Now I have a scheme
I need to do like this
This definitely works, since I tried to send all traffic from the router through cloudflare warp, wireguard connected the connection to the remote router through a laptop, the remote router successfully accepts the connection, the ip address issued by cloudflare sees it as the incoming ip. here is an example diagram
I would leave it that way, but unfortunately I have devices on the local network on which it is impossible to initiate a vpn connection.
I need this because my ISP greatly reduces the connection speed to the remote router via wg. it turns out 20-40 kbits.
But according to the third scheme, through cloudflare warp, the speed is all 100 mbits.
Unfortunately, this is the only ISP in my current location.
any ideas how it can be done?
Your 'scheme' pictures don't make a lot of sense if I'm honest. You have all the tunnels from either end terminating in the internet which makes it difficult to understand what is actually connected to what. It'd be more helpful to provide a diagram showing your current setup and the configs from both routers. We can then start from there.
1 Like
what is the remote router configuration for here? it just has a wg interface that accepts the wg connection from the first router. and it definitely works. I need the second router to accept a wg connection from the first router with an ip given by cloudflare. it definitely works when all the traffic of the first router goes through cloudflare, and I establish a wg connection to the second router from a computer in the local network of the first router.
i need to inject wg "homenet" traffic into cloudflare on the first router! I gave the configuration of the first router above.
Assuming the first router makes the connection then it might work if you route the 'homenet' connection via the WARP tunnel, rather than the WAN connection. You can either use static routes or PBR (maybe).
If, on the other hand, the second (or remote) router is initiating the connection then it's unlikely to work as I'm pretty sure cloudflare don't support port forwarding which would be required to make the initial connection. You'd also still need to sort out the routing on the first router to send the (return) traffic via the WARP tunnel, rather than the WAN.
If you want your cloudfare IP address to function as your public IP address you have to ask cloudfare if they support port forwarding (I highly doubt that).
There are VPN providers which do support port forwarding via the VPN IP address, unfortunately my own Mullvad just stopped doing that, but that was often used by people with CGNAT to be able to allow access to their home.
If your other router has a public IP address then you can set up the Server on that side and just make a client to connect to the other side first make a tunnel to Cloudfare, make a second tunnel but disable host routes and be sure to substract 80 of the MTU for the second tunnel.
You probably have to set some static routes also to route traffic you want via the second tunnel.
note your second router has no relation to cloudfare in just acts as a WG server
now I have this
according to the third scheme, the remote router receives a wg "homenet" connection with an incoming ip address issued by cloudflare
Exactly, I need to route wg "homenet" through wg "warp". I already tried PBR but it didn't work for me.
what routes do I need to set up?
It is actually something you usually try to avoid, so not a thing I can setup by heart and I have no time to do a setup on my router.
Luckily there are far smarter people here at the forum