A couple of days ago, I get a second ISP connection from another provider and after configuring the router to use both connections via PCC, I couldn’t get working WireGuard connections for my mobile devices. I’ve added a second IP address as A record to the external DNS service for the domain name of my VPN endpoint. Internet on local devices works fine, PCC working correctly, and clients directly connected to router haven’t any issues with Internet connection.
The router works as WireGuard server and external clients connecting to it via mobile internet. When I disable interface from one of ISPs mobile clients can connect via one ISP with external IP address.
Current setup with obfuscated sensible data:
ISP RT: Static External IP - 80.80.80.80
ISP MGTS: Static External IP - 90.90.90.90
External DNS name of WireGuard VPN server endpoint: vpn.mydomain.com
Attaching config without sensible data to this topic. Maybe somebody could give me a hint what I’m doing wrong in this dual WAN configuration?
That’s not the case. I didn’t want to set 2 different wg servers on 2 different isp’s. Idea to use domain name as input point and users can connect to both ip addresses with one key.
What is important is to also understand the current construct of the dual wan as that can be a limiting factor. One that cannot be avoided when you get to the config.
SO, are we talking.
a. Primary and Failover scenario
b. Primary but some use of second WAN (lets say just for wireguard incoming).
c. Load balancing PCC - where the traffic is already mangled to death.
I’ve seen multiple complaints here on the forum before that either all UDP packets sent by the router itself, or only Wireguard transport packets in particular, have problems to use other routing table than main. But I have just tested it on my CHR running 7.5 (like your 5009) and the transport packets sent by the Wireguard do get routed according to the routing-mark value assigned. And your mangle rules seem fine to me - you assign a connection-mark depending on in-interface in prerouting, and you translate that connection-mark into a routing-mark in output. So I’d use /ip firewall connection print detail interval=1s where dst-port=12087 to check that the proper connection-mark is assigned, and I’d use /tool sniffer quick port=12087 to see whether the responses are sent via the same WAN port through which the corresponding requests were received.
(1) So you have one DYNDNS URL that all your external mobile users have for wireguard connectivity and single port (external users).
Being not familiar with records, do you mean that you have two entries for your dyndns url?
If so is their a primary record which points to lets say ISP1-WAN1 and a secondary record that points to ISP2-WAN2?
In other words is it fair to say that all users will then go via WAN1 for wireguard if both are available??
(Assuming its two separate providers of course otherwise dual wan would not provide any redundancy)
(2) With full PCC, traffic coming in on WAN1 is always going out WAN1 and same for WAN2. The conclusion is that there should be no issues, if users normally coming in wirguard on WAN1 are through a failure of ISP1-WAN1, redirected by the Dyndns recordname which switches to B and thus users are sent to ISP2-WAN2.
A new wireguard session should start!
The only thing possibly missing is the requirement for two input chain rules.
add chain=input action=accept in-interface=ether2 dst-port=xxxx protocol=udp
add chain=input action=accept in-interface=ether1 dst-port=xxxx protocol=udp
But you have that covered under a more wide open rule (any interface). So thats not the problem.
(3) Perhaps the issue is at the client side?? or perhaps your mangling for PCC is not complete??
My guess is that using capsman is bad luck! as it should work … seeing as everything else does too.
I wonder if doubling down on the return traffic for wan2 might make a difference ???
Mangles…
chain=pre-routing in-interface=ether2 dst-port=wireguard-port mark=no-mark new-packet-mark=routeWAN2 passthrough=yes
chain=pre-routing mark=routeWAN2 new routing-mark=useWAN2 passthrough=yes
chain=output routing-mark=useWAN2 out-interface=ether2 action=accept
Wireguard should work for dual wans, be it PCC with mangling or primary failover.
CASE A: PCC - The assumption is that the dyndns URL name used by the Admin has a primary and secondary Record, even though the WANs may be setup as PCC.
That is because the DYDNS URL will switch from the A record to the B record and the traffic will come into the router on the FINDABLE wan and thus a new tunnel will be initiated and work.
CASE B: PRIM/FAIL - The assumption is that dydns is used again but only record be needed and that could point to IP cloud for example or one could set it up to two wans as previous case. IF using IP cloud one has to be careful to determine/ensure IP cloud selects the primary as the default to use normally.
In either case above, the failover traffic onto the other WAN should simply work. In the case of PCC we ensure traffic coming in on any wan goes out the same WAN.
In primary failover, there is only one WAN available and thus the return traffic to create the tunnel must go out the same WAN.
The rest of the traffiic is mostly handled by firewall rules and routes which utilize the wireguard interfaces either created manually or automatically.
Being not familiar with records, do you mean that you have two entries for your dyndns url?
I mean that I’ve got personal domain and using control panel where I can place A records for my domain name.
If so is their a primary record which points to lets say ISP1-WAN1 and a secondary record that points to ISP2-WAN2?
In other words is it fair to say that all users will then go via WAN1 for wireguard if both are available??
A records are having same weight and DNS server of provider will sent A record with IPs randomly. In one moment it can be IP address that belongs to ISP1, in another moment it can be ISP2.
(Assuming its two separate providers of course otherwise dual wan would not provide any redundancy)
Yes, in my case it is 2 separated providers.
(3) Perhaps the issue is at the client side?? or perhaps your mangling for PCC is not complete??
I wonder if doubling down on the return traffic for wan2 might make a difference ???
Mangles…
chain=pre-routing in-interface=ether2 dst-port=wireguard-port mark=no-mark new-packet-mark=routeWAN2 passthrough=yes
chain=pre-routing mark=routeWAN2 new routing-mark=useWAN2 passthrough=yes
chain=output routing-mark=useWAN2 out-interface=ether2 action=accept
Yeah, let me add rules from your post and I’ll provide some feedback.
My guess is that using capsman is bad luck! > > as it should work … seeing as everything else does too.
Interesting so the domain name will randomly choose either ISP1 or ISP2 for external users attempting to access the Router and wireguard.
As stated, PCC should simply work its magic and there should be no issues.
I went back to your first post to remind myself ----> What was the stated problem. Its not there…
The router works as WireGuard server and external clients connecting to it via mobile internet. When I disable interface from one of ISPs mobile clients can connect via one ISP with external IP address.
So when one interface goes down the clients use the available interface, what is the problem LOL???
+++++++++++++++++++++++++++++++++++++++++++
So lets nail it down
ISP1 and ISP2 both up - external clients access wireguard no problem regardless of ISP reached for the connection
ISP1 disabled - external clients CAN or CANNOT use wireguard from ISP2 ???
ISP2 disabled - external clients CAN or CANNOT use wireguard from ISP1 ???
as it should work … seeing as everything else does too.