for port WG and 80 to the router via WAN2 absolutely the same rules.
and if go via WAN2 via 80 to the router - everything works, WG - no (both with packet marking and static route)
[TUN] [HM562] Handshake for peer 1 (x:x) not completed after 5 seconds, repeating (let’s try 2)
Packets arrive on port WG, but they do not leave. At that time packets arrive on port 80 and respond as need.
It seems that the gateway IP, not the peer, comes to the WG interface via WAN2, I’m not sure. How to see a log of Wireguard server ?
However, with the same configuration, but on WAN1 - everything works.
so here’s the question, has anyone implemented WG on the 2nd WAN? Could you show your configuration?
There was an issue pre 7.15.3 where the second WAN for wireguard ( secondary wAN) would not work even if one mangled for wireguard.
So Im assuming before looking at the config, that there may other issues at play since you are using 7.15.3.
Can you clarify why there are two Configs for one device?
The simple is the actual router hosting wireguard, what is the purpose of WAN2 config…
Is that simply the device providing LTE termination, and you pass the private IP to the other router as WAN2??
I also tend to think that there is a bug that has survived to the current version.
simple.rsc is the main router, wan2.rsc is wan2 itself.
The purpose of wan2 is to provide an independent separate channel for specific needs. And planing to use 4-6 additional WAN.
Yes, wan.src is just an LTE modem that works as a laboratory device, it forwards ports, it can’t do anything else.
In fact, some WAN devices will be GPoN in bridge mode or router mode.
Nope, your config needs to be fixed first, then we can properly assess if you still have issues. Since others are using 7.15.3 with secondary WAN without issue, its likely the config.
The config is so hosed and confusing…
I dont know where to begin… which means its so nonesensical there is no logical easy mod… a complete rewrite is required.
So many firewall rules not needed as well.
Before I bother, did you realize the ltap is only giving you a WAN2 throughput of like 100Mbps or less??
Only really useful I suppose to config the router, or maybe reach something on the CCR1009 LAN
The other things is no need for IP DHCP on the CCR1009 for WAN2, just set the DHCP lease statically on the LTAP to 192.168.80.10
This is just notional because there is much not known. A network diagram would be very helpful to try to explain what you are attempting to do and what the ports are connected to!!
QUESTION: Do your LTE connection get a PUBLIC IP ADDRESS? If not wireguard may not be possible. In fact you may have to do it through your PPPOE connection if that gives you a public IP.
I think there is no error in this lab configuration, except for the WAN2 line and Wireguard.
And I think you don’t need my configuration, this is a basic initial standard configuration, it works and there are no questions about it.
There is only a question about Wireguard on WAN2.
As I wrote earlier, LtAP is only for lab research. If I manage to run Wireguard on this, then I plan to transfer the settings to a working router with GPON PPPoE.
Of course, the LTE connection has a static public address.
And the thing is that I have already tried to run Wireguard on WAN2 with PPPoE, it also does not work.
Therefore, it was decided to create a separate lab and practice on it, since it is impossible to do this on a working system.
I just need to know if Wireguard works on WAN2 for anyone? 2nd question, I would like to see a working configuration for Wireguard on WAN2, only routing.
Total configuration doesn’t matter, I’m only looking for the settings for Wireguard via WAN2, everything else doesn’t affect Wireguard via WAN2.
Well, the diagram couldn’t be simpler, I’m attaching it.
Basically, the ROS implementation has a bug where Wireguard’s initial handshake always gets sent back through the default gateway instead of the interface the traffic came from which makes the connection fail due to a protocol error. And since the handshake isn’t tracked, you can’t use mangle to manage it either.
The only way to work around the bug is by using policy routing:
Well this fix assumes one is still mangling to ensure traffic coming into wan2 goes out WAN2 and using a special route table for the WAN2.
If you are talking using Routing Rules, if the situation permits it, and it works, then that is another approach which uses same table and same route as above.
Do you mean… like
add action=lookup-only-in-table dst-address=fixed-static-public-IP-of-WAN2 table=use-WAN2
Yeah, that was the solution I was thinking of but I had NAT in mind and just didn’t have the energy to figure out a good variation like the one you just showed.
I tried it first, cause I prefer static rules instead marks. But handshake did not work.
Tried different combinations in the routing rule to route the handshake packets back.
Mikrotik has had a few supout reports on this matter and is hopefully working on a fix.
The problem we are facing is that the response to the handshake leaves WAN2 and then ends up bleeding out WAN1. Therefore the originating device gets a response from an unknown destination address and is rejected.
Therefore we tell the router that all traffic coming from ether2 (wan2) is destinatted to WAN1 for that port.
Thus when WAN1 is chosen (incorrectly) to reply to that traffic ( before leaving the door so to speak ) the router sees the dstnat rules and “un-destination nats” the traffic out through WAN2.
Yeah, the first WireGuard handshake is like a secret handshake between two routers (Peer A and Peer B) that want to communicate securely. Peer A sends a “hello” (handshake initiation packet) to Peer B which responds with a “hello back” (handshake response packet).
But because there’s a bug in ROS, Peer B sends the “hello back” from a different address than the one it received the first “hello” from, which confuses Peer A. Peer A thinks it’s suddenly talking to someone else or that something fishy is going on so it just ignores the response and the handshake fails. It’s a built-in security measure in WireGuard to make sure both peers are actually who they say they are.
To make it work, you have to use some workarounds to ensure that the “hello back” is sent back using the same address it came from using inbound routing policies or dst-nat.
