hello, i have a cloud hosted CHR with a static public IP and a nat masquerade rule for having internet. The chr runs a wireguard server only, few firewall filter rules for security and that’s all.
I have a linux server at home running a web service at port tcp 8080, the server runs wireguard and has at allowed networks the zeros (0.0.0.0/0), all the internet is routed through the WG interface. I can confirm that when i check my public ip from server, it is the same ip of my CHR.
my problem is that the port 8080 which runs a web service at my home server, is not accessible through the public ip of CHR. I cannot access the web UI from that public IP.
server is connected to an lte chateau at my home and has internet from this router. bellow is the network diagram.
Is it possible to access my server from the chr public ip? what do i need to configure?
Okay got it,
You want to wireguard into the CHR and reach the Server on the linux machine which is also a WG client to the CHR instance.
In effect the CHR is acting as a relay…
A. Add forward chain rule. ( just after the allow to Internet rule ) add action=accept chain=forward in-interface=wireguard-chr out-interface=wireguard-chr
B. Add to allowed IPs on CHR for the peer to the linux device. /interface wireguard peers
add allowed-address=10.10.10.2/32,linuxServersubnet interface=WG-CHR public-key=
“public key”
So now traffic exiting the tunnel at the CHR will be allowed to reenter the tunnel
Then when reentering the tunnel the destination address will be checked and matched to the peer heading to the linux server.
But what route does the router have… AHA
C. Need to add a route. add dst-address=linuxServersubnet gateway=wireguard-CHR table=main
Hello, thank for the info! the server is having the CHRs public ip and it connects perfectly! my problem now is that i cannot “see” my service port 8080 from the internet.
CHR has a masquearade rule and i created a src-nat rule with destination port 8080 and to addresses the lan ip of my server (192.168.XX.XX), the nat rule is having traffic but still i am not connectible from the outside world.
You need a dst-nat rule with port 8080 not a src-nat rule.
And you need to fix the “drop all from WAN not DSTNATed” rule, which doesn’t do what it says it does, presumably because you have modfied it for some reason, and screwed it up.
As it is, you have no rule on the forward chain to allow the traffic in.
Bullocks! You dont need any such rules sourcenat or destination NAT on the CHR… The firewall rules are fine with the one addition already recommended.
The single rule you have for the standard WAN is fine…
The wireguard client will establish the connection with the CHR.
Since your allowed IPs on the wireguard client include the linuxserver subnet 192.168.1.0/24 ( and of course 10.10.10.0/24) any traffic from the client heading in that direction will be allowed by the wireguard process on the client. You may have 0.0.0.0/0 to allow internet out CHR, in which case this covers all of the above anyway, so then not needed.
When the traffic reaches the CHR, the router allowed IPs will allow the source destination of 10.10.10.2/32 as it set in the allowed IPs on the CHR.
The traffic will exit the tunnel and be at the LAN level so to speak.
The destination of the traffic will be looked at by the router. which is the linux server IP address 192.168.1.xx
The router will see the route created that includes that IP. dst-address=192.168.1.0/24 gateway=WG-CHR table=main, and then route the traffic that just exited the tunnel back into the tunnel headed towards the other client the CGNAT client (I’m assuming that is the linux wireguard client 10.10.10.3/32).
This will be allowed by the firewall rules… which basically states, allow traffic exiting the wireguard tunnel to re-enter the tunnel! add action=accept chain=forward in-interface=wireguard-chr out-interface=wireguard-chr
All good so far, so the traffic is routed to the wireguard with destination of 192.168.1.XX and the firewall rules allow it.
PROBLEM and the one thing I missed in the first post!! I put the linux subnet on the WRONG PEER…
a. assuming your remote client uses 0.0.0.0/0 to connect to the CHR (if not you need 10.10.10.0/24 and 192.168.1.0/24) so that should be covered.
b. you also need the CHR router in the wireguard settings to match/select destination addresses of 192.168.1.0/24 from local users on the CHR. Once your remote client exits the tunnel its considered a local user. The allowed IP would also be required if remote users from 192.168.1.0/24 were heading to the CHR for example. So the firewall rules allow it, a route exists and the allowed IPs, match the peer heading to CGNET and will be sent…
SO ADD on CHR peer settings for cgnet add the server subnet and remove it from the wrong peer (my bad)
From: /interface wireguard peers
add allowed-address=10.10.10.2/32,192.168.1.0/24 interface=WG-CHR public-key=
“public key”
add allowed-address=10.10.10.3/32 comment=PI interface=WG-CHR
persistent-keepalive=25m public-key=
“public key”
TO: /interface wireguard peers
add allowed-address=10.10.10.2/32 interface=WG-CHR public-key=
“public key”
add allowed-address=10.10.10.3/32,192.168.1.0/24 comment=PI interface=WG-CHR
persistent-keepalive=25m public-key=
“public key”
Sorry for the error. Fix that and you will be able to reach server directly.
Post your latest full CHR config after making changes.
/export file=anynameyouwish (minus serial number and any public WANIP information)
hello, thank for the reply, bellow is chr config. the server is running a web service at port 8080, i can access this web interface from server’s lan but i cannot access it from CHR’s public IP. when i try from another network outside of my lan the url http://:8080 i got no response. I have checked the server’s internet traffic and everything goes through CHR.
/interface ethernet
set [ find default-name=ether1 ] disable-running-check=no
/interface wireguard
add listen-port=13231 mtu=1420 name=WG-CHR
/interface list
add name=LAN
add name=WAN
add name=ADMIN
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/port
set 0 name=serial0
/ip neighbor discovery-settings
set discover-interface-list=none
/ipv6 settings
set disable-ipv6=yes
/interface list member
add interface=ether1 list=WAN
add interface=WG-CHR list=ADMIN
/interface wireguard peers
add allowed-address=10.10.10.2/32 interface=WG-CHR public-key=\
"<pub key>"
add allowed-address=10.10.10.3/32,192.168.1.0/24 comment=PI interface=WG-CHR \
persistent-keepalive=25m public-key=\
"<pub key>"
/ip address
add address=5.XXX.XXX.XXX/24 interface=ether1 network=5.XXX.XXX.0
add address=10.10.10.1/24 interface=WG-CHR network=10.10.10.0
/ip dhcp-client
add disabled=yes interface=ether1
/ip dns
set servers=XXX.XXX.XXX.XXX,XXX.XXX.XXX.XXX
/ip firewall address-list
add address=10.10.10.2 list=authorised
add address=91.XXX.XXX.XXX list=authorised
/ip firewall filter
add action=accept chain=input comment="Access CHR from WG" in-interface=\
WG-CHR src-address-list=authorised
add action=accept chain=input comment=\
"defconf: accept established,related,untracked" connection-state=\
established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=\
invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=input comment=\
"defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1
add action=accept chain=input comment="WG VPN Rule" dst-port=13231 protocol=\
udp
add action=drop chain=input comment="defconf: drop all not coming from LAN"
add action=accept chain=forward comment="defconf: accept in ipsec policy" \
ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" \
ipsec-policy=out,ipsec
add action=accept chain=forward comment=\
"defconf: accept established,related, untracked" connection-state=\
established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" \
connection-state=invalid
add action=accept chain=forward comment="allow internet traffic" \
in-interface=WG-CHR out-interface-list=WAN
add action=accept chain=forward comment="allow inter-WG traffic" \
in-interface=WG-CHR out-interface=WG-CHR
add action=drop chain=forward comment=\
"defconf: drop all from WAN not DSTNATed"
/ip firewall nat
add action=masquerade chain=srcnat ipsec-policy=out,none out-interface-list=\
WAN
add action=dst-nat chain=dstnat dst-port=8080 in-interface=ether1 protocol=\
tcp to-addresses=192.168.1.XXX to-ports=8080
/ip firewall raw
add action=drop chain=prerouting dst-port=53 in-interface-list=WAN protocol=\
udp
/ip route
add dst-address=0.0.0.0/0 gateway=5.255.110.1
add check-gateway=ping disabled=no distance=1 dst-address=192.168.1.0/24 \
gateway=10.10.10.3 pref-src="" routing-table=main scope=30 \
suppress-hw-offload=no target-scope=10
/ip service
set telnet disabled=yes
set ftp disabled=yes
set www disabled=yes
set ssh port=XXX
set api disabled=yes
set winbox port=XXX
set api-ssl disabled=yes
/ip ssh
set strong-crypto=yes
/system clock
set time-zone-name=Europe/Amsterdam
/system logging
add topics=ssh
/tool bandwidth-server
set enabled=no
/tool mac-server
set allowed-interface-list=none
/tool mac-server mac-winbox
set allowed-interface-list=ADMIN
/tool mac-server ping
set enabled=no
Hello, i changed the static route rule to WG-CHR. the autorised ip rule of 91.XXX.XXX.XXX is my static IP from my office, i added it in case if something is wrong with the wireguard to have another access method.
I removed the dst-nat rule. still i am unable to access from the outside. The wireguard tunnels works perfectly, i have checked with torch the traffic, all packets from server are going in and out from wg-tunnel
You need to add your dst-nat rule back for the server/8080 and correct your last filter rule. The comment on it is correct (drop all not dst-nated), but the rule is missing the function.
There is no requriement for the CHR to exercise any destination nat. Primarily there is no server on the CHR.
I will agree that the comments attached to the last rule in both the input chain and forward change are not accurate and reflect rules that were removed vice simply stating,
comment=“drop all else”
The user, client via 10.10.10.2 arrives via WG at the CHR, it then, with destination address of linux server 192.168.1.xx, gets routed back into the tunnel towards the CGNET device and the linux server. That is because on the CHR there is a route dst=192.168.1.0/24 gateway=wg-chr table=main. This traffic is allowed because the peer to cgnet includes allowed IPs of 192.168.1.0/24, and the firewall rules allow it as well.
What I would ask the OP is to provde BOTH CHR config and CGNAT confiig of LTE Chateau, because I suspect the problem is with the CHATEAU settings at the moment.
The return traffic if indeed the server is reached and return traffic head back to the CHR will depend on setting we have not seen yet ( LTE chateau settings).
At the CHR the same firewall rule will work for return traffic in-interface=wg-chr out-interface=chr and the destination 10.10.10.2 is already routed by the dst-address=10.10.10.0/24 gwy=wg-chr table=main that is made automagically by the CHR. The peer settings work as 10.10.10.2 is destination allowed IP on the CHR back to the originator…
WHY…
The user coming on to use the server is 10.10.10.2.
The CHR and the CGENT device recognize this user and the user is at the same level of the LAN at th LTE Chateau.
The user can reach the server
assuming the OP has a rule at the chateau
add chain=forward action=accept in-interface=WG-Chateau dst-address=server OR dst-address=subnet of server.
The route back is easy as its already exists by the nature of dst-address=10.10.10.0/24 gwy=WG-Chateau.
The allowed IPs on the CGNET permit the user to enter the LAN state
allowed IPs=10.10.10.0/24 which permit any user from CHR itself or remote users to access the chateau router ( exit the tunnel )
.
However, the OP Still has to provide the le Chateau config. So we can confirm the right rules are in place…
++++++++++++++++++++
In summary, there is no need for dst shenanigans, unless I am missing something obvious in my logic?
In other words, present how you think traffic is flowing to show me the wrongness in my thinking…
The user is trying to reach the server with the Public IP of the CHR through Wiregaurd tunnel. Again, this is the whole purpose of the CHR, to allow remote access using the Public IP of the CHR.
I am having to do the same, since only CGNAT services of T-Mobile 5G, T-Mobile LTE and Starlink are available to me.
Hmm I thought the OP described reaching the CHR THROUGH a wireguard tunnel and then reaching the server.
You are talking about anyone from a public IP address reaching the CHR via its public IP address and no wireguard to CHR.
Unfortunately I believe you are correct and I have been making the wrong approach.
In that case, It is a very weird scenario that I will have to think about…
I need the OPS configs on both devices…
Should be doable. The tricky part for me is ensuring return traffic leaves the server back into the tunnel, will probably have to mangle in this case.
Since the CGNAT (chateau device doesnt get a public IP it cannot host the server). The CHR should be able to through a wireguard tunnel to the chateau. Its an interesting scenario.
The settings for chateau should not change.
add chain=forward action=accept src-address=subnet out-interface=WG-Chateau ( so local users can enter the tunnel )
add chain=forward action=accept in-interface=WG-Chateau dst-address=subnet ( so external traffic can reach the subnet via wireguard )
/routing table add name=useWG fib
/ip route
add dst-address=0.0.0.0/0 gwy=WG-Chateau table=useWG
/routing rule add dst-address=subnet action=lookup table=main ( so local users can access server )
/routing rule add src-address=subnet action=lookup-only-in-table table=useWG
On Chateau router, Allowed IPs 0.0.0.0/0 for peer of CHR.
my problem is that the port 8080 which runs a web service at my home server, is not accessible through the public ip of CHR. I cannot access the web UI from that public IP.
The CHR is the used as Wiregaurd server, the Home Server is acting as Wiregaurd client. The only tunnel is between the Home Server and the CHR. The Home Server has Web UI running on port 8080. The goal, use public.ip.of.chr:8080 to access the Home Server that is behind CGNAT.
