Hi All,
I was wondering how to set up a wireguard server on CHR with only public loopback.
I mean the following :
Default route with an eBGP one - interco with edge routers is built with RFC6598.
a bridge in / 32 (loopback) is used to NAT trafic - works fine.
the same loopback is uded for incoming PAT UDP/13231 for Wireguard - we got matching packet (changing port is not the solution).
Wireguard tunnel won’t come up as IP from physical interface facing Internet is always used for trafic from the CHR and it’s not a routable.
Any NAT rule for changing the behaviour will not affect it (even if the rule is matched !).
In connection table, I did not see any trafic from the CHR (it did not try to answer in any way to my Windows 10 client)
Is wireguard designed to keep physical IP for outgoing trafic based on routing table ?
This issue does not occur when tunnel is set up without any NAT
Hi,
You’re right, big picture required
In order to provide public IPv4 IP to our customers (we are ISP) with strict use (you get what you need, no more), Internet access is always configured with RFC6598.
This is also good for security because most of the time, the CHR does not own public IP, it routes only.
Sometimes, we have to host public IP (for small customers) and provide VPN Access.
Loopback do the job (even with OVPN for example) but we’re stuck with Wireguard.
I have tried to mangle outgoing trafic (marking packet for output chain) : I can hide wireguard IP but the source port remains randomized.
And use public IP as secondary network on the WAN interface did not help.
CHR is hosted on our own Cloud, vmware-based.
On the left side, you can see the roadwarrior Windows 10.
It uses a public internet connexion with its own ISP.
And in this case, the CHR has an internet connexion too via loopback.
Internet connectivity is OK from both side.
Not sure what you mean by loopback its a cute term but does nothign but distract from the rest.
So you have no MT device at home simply an MT CHR on the cloud, hosting wireguard.
You have road warrior using WG windows.
So whats the user requirement for the windows client?
What is the problem he gets a wireguard IP and connects to the CHR…
At the CHR, you have
a. allowed IP for that peer being its wireguad IP address
b. the DAC route on CHR allows return traffic for the windows user to be routed back into the tunnel
c. via firewall rules you determine what traffic the wireguard user is allowed to access
The windows box is not the problem.
The CHR is.
The WAN IP of the CHR is the loopback and does not belong to any physical interface.
We do not have public IP on the WAN interface.
All internet trafic must be hold by this loopback.
As mentionned, there is no problem when I want to use this loopback for outgoing trafic (from LAN for example)
There is no problem too when I set up the DNAT (loopback → wireguard)
The issue occurs when WG server answered to the client : it uses the WAN interface which seems correct BUT current IP won’t work as long as it is 100.94.0.2/27.
I think I have to NAT this output trafic but SRC NAT will change the SRC port, meaning 13231/udp is no more part of the socket.