Community discussions

MikroTik App
 
haris013
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 80
Joined: Mon Jun 18, 2018 2:13 am

Wireguard tunnel to CHR and Public ip port forward

Tue Dec 13, 2022 7:09 pm

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.

Image

Is it possible to access my server from the chr public ip? what do i need to configure?
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 19324
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: Wireguard tunnel to CHR and Public ip port forward

Tue Dec 13, 2022 7:14 pm

So why didnt you post your CHR config??

/export file=anynameyouwish ( minus chr serial number and any public WANIP information)
 
haris013
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 80
Joined: Mon Jun 18, 2018 2:13 am

Re: Wireguard tunnel to CHR and Public ip port forward

Tue Dec 13, 2022 9:18 pm

So why didnt you post your CHR config??

/export file=anynameyouwish ( minus chr serial number and any public WANIP information)
bellow is the chr config:
/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=\
    "public key"
add allowed-address=10.10.10.3/32 comment=PI interface=WG-CHR \
    persistent-keepalive=25m public-key=\
    "public key"
/ip address
add address=XXX.XXXX.XXXX.XXXX interface=ether1 network=XXXX.XXXX.XXXX
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=XXXX,XXXXX
/ip firewall address-list
add address=10.10.10.2 list=authorised
add address=XXXXXXX 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=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
/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=XXX.XXX.XXX.XXXX
/ip service
set telnet disabled=yes
set ftp disabled=yes
set www disabled=yes
set ssh port=XXXX
set api disabled=yes
set winbox port=XXXX
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
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 19324
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: Wireguard tunnel to CHR and Public ip port forward

Tue Dec 13, 2022 9:32 pm

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

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

The rest is up to your settings on the linux device so not my problem. :-)
Last edited by anav on Mon Dec 19, 2022 3:50 am, edited 1 time in total.
 
haris013
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 80
Joined: Mon Jun 18, 2018 2:13 am

Re: Wireguard tunnel to CHR and Public ip port forward

Sun Dec 18, 2022 1:52 pm

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.

any ideas?
 
sid5632
Long time Member
Long time Member
Posts: 554
Joined: Fri Feb 17, 2017 6:05 pm

Re: Wireguard tunnel to CHR and Public ip port forward

Sun Dec 18, 2022 2:24 pm

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.
 
User avatar
broderick
Member Candidate
Member Candidate
Posts: 242
Joined: Mon Nov 30, 2020 7:44 pm

Re: Wireguard tunnel to CHR and Public ip port forward

Sun Dec 18, 2022 3:41 pm

did you open the wireguard port in your cloud?
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 19324
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: Wireguard tunnel to CHR and Public ip port forward

Mon Dec 19, 2022 4:13 am

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)
 
haris013
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 80
Joined: Mon Jun 18, 2018 2:13 am

Re: Wireguard tunnel to CHR and Public ip port forward

Tue Dec 20, 2022 8:13 pm

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://<chr public IP>: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
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 19324
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: Wireguard tunnel to CHR and Public ip port forward

Wed Dec 21, 2022 4:53 am

(1) No friggen NO.......
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[/i]

This rule is intended for people coming in through wireguard to be able to config the router.
What in heck is 91.xxxx ?????????????????

The people coming in on wireguard are 10.10.10.2 and 10.10.10.3.

(2) Put that rule AFTER the default input chain rules aka after capsman rule and remove the 91.xxxx it doesnt apply.

(3) NO,
From
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


TO:
add dst-address=192.168.1.0/24 gateway=WG-CHR table=main

(4) Why is this rule on the CHR, its not doing any destination nat to a local server at all.........
REMOVE IT.

add action=dst-nat chain=dstnat dst-port=8080 in-interface=ether1 protocol=\
tcp to-addresses=192.168.1.XXX to-ports=8080
 
haris013
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 80
Joined: Mon Jun 18, 2018 2:13 am

Re: Wireguard tunnel to CHR and Public ip port forward

Wed Dec 21, 2022 11:12 am

(1) No friggen NO.......
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[/i]

This rule is intended for people coming in through wireguard to be able to config the router.
What in heck is 91.xxxx ?????????????????

The people coming in on wireguard are 10.10.10.2 and 10.10.10.3.

(2) Put that rule AFTER the default input chain rules aka after capsman rule and remove the 91.xxxx it doesnt apply.

(3) NO,
From
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


TO:
add dst-address=192.168.1.0/24 gateway=WG-CHR table=main

(4) Why is this rule on the CHR, its not doing any destination nat to a local server at all.........
REMOVE IT.

add action=dst-nat chain=dstnat dst-port=8080 in-interface=ether1 protocol=\
tcp to-addresses=192.168.1.XXX to-ports=8080


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
 
2frogs
Forum Veteran
Forum Veteran
Posts: 713
Joined: Fri Dec 03, 2010 1:38 am

Re: Wireguard tunnel to CHR and Public ip port forward

Wed Dec 21, 2022 5:08 pm

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.
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 19324
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: Wireguard tunnel to CHR and Public ip port forward

Wed Dec 21, 2022 8:57 pm

Disagree two frogs,

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 <dac> 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..........
 
2frogs
Forum Veteran
Forum Veteran
Posts: 713
Joined: Fri Dec 03, 2010 1:38 am

Re: Wireguard tunnel to CHR and Public ip port forward

Thu Dec 22, 2022 7:00 pm

The purpose of the CHR is to provide Public IP for the server behind CGNAT by way of a Wiregaurd tunnel. This needs NAT...
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 19324
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: Wireguard tunnel to CHR and Public ip port forward

Thu Dec 22, 2022 11:55 pm

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 <dac> 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.........
 
2frogs
Forum Veteran
Forum Veteran
Posts: 713
Joined: Fri Dec 03, 2010 1:38 am

Re: Wireguard tunnel to CHR and Public ip port forward

Fri Dec 23, 2022 12:26 am

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.
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 19324
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: Wireguard tunnel to CHR and Public ip port forward

Fri Dec 23, 2022 12:40 am

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.
 
User avatar
broderick
Member Candidate
Member Candidate
Posts: 242
Joined: Mon Nov 30, 2020 7:44 pm

Re: Wireguard tunnel to CHR and Public ip port forward

Fri Dec 23, 2022 1:15 pm

Hmm I thought the OP described reaching the CHR THROUGH a wireguard tunnel and then reaching the server.
I thought exactly the same. What would Wireguard have to do with it otherwise?
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 19324
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: Wireguard tunnel to CHR and Public ip port forward

Fri Dec 23, 2022 1:30 pm

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.
Last edited by anav on Fri Dec 23, 2022 11:03 pm, edited 1 time in total.
 
2frogs
Forum Veteran
Forum Veteran
Posts: 713
Joined: Fri Dec 03, 2010 1:38 am

Re: Wireguard tunnel to CHR and Public ip port forward

Fri Dec 23, 2022 6:25 pm

From the third paragraph of original post.
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.
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 19324
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: Wireguard tunnel to CHR and Public ip port forward

Fri Dec 23, 2022 11:04 pm

Yup piece of cake,,,,,,,,
When the OP posts both configs, it will take 30 seconds to clean it up.
 
Shon3
just joined
Posts: 6
Joined: Thu Dec 08, 2022 7:35 pm

Re: Wireguard tunnel to CHR and Public ip port forward

Sun Jan 01, 2023 2:12 am

In that case, It is a very weird scenario that I will have to think about......
I do not find it that weird. Many ISPs are not able to provide their customers with public IP. So one way to deal with it if I want to have my home servers reachable from internet is to get a cheap VPS with a dedicated public IP and setup a tunnel to my home router.
Another reason for this scenario could be increased privacy of home users (so that their internet activity is not linked to a dedicated public IP with my domain name).
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.
More hints on this?
I plan:
  1. Subscribe to a VPS with dedicated WAN IP address.
  2. Install OpenWRT there, setup WireGuard tunnel to my Home LAN Mikrotik.
  3. @VPS: DNAT _all_ incoming packets from WAN via WireGuard tunnel my Home LAN Mikrotik and let Mikrotik do another DNAT to various computers in my Home LAN.
  4. When Home LAN users access public internet, they would not utilise the WireGuard tunnel at all.
The double DNAT looks troublesome, yet I would prefer to manage firewall and portforwading at my Home LAN Mikrotik rather than in VPS.

At the moment, I am not sure how to arrange that response from servers on my Home LAN gets routed by Mikrotik via Wireguard tunnel back to VPS...
Internet --> VPS OpenWRT <-- wg tunnel --> LAN router Mikrotik <---> LAN server1 port-forwarded from VPS and Mikrotik
                                            |                   |--> LAN server2 port-forwarded from VPS and Mikrotik
                                            |                   |--> LAN clients accessing internet (not via WG tunnel, but directly)
Internet <----------------------------------|
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 19324
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: Wireguard tunnel to CHR and Public ip port forward

Mon Jan 02, 2023 6:37 pm

Still waiting for haris to post both configs!!

@shon, start your own thread happy to help there.........
 
haris013
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 80
Joined: Mon Jun 18, 2018 2:13 am

Re: Wireguard tunnel to CHR and Public ip port forward

Wed Jan 04, 2023 1:59 am

From the third paragraph of original post.
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.
;
2frogs you are correct! this is exactly what i want to do. Is it possible to do it without routing all traffic from chateau to chr? I DONT want to tunnel the chateau to the chr, only the server to chr.

is that possible to achieve and use public.ip.of.chr:8080 where the web service at 8080 runs at my local server?

my chr config is above, i don't have change anything
chateau config is the default configuration at 192.168.1.0/24 lan subnet. default firewall rules, default everything. lte interface is the wan
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 19324
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: Wireguard tunnel to CHR and Public ip port forward

Wed Jan 04, 2023 2:15 am

Yes to your questions,
but I have to see the current configs of both to provide advice..........
 
haris013
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 80
Joined: Mon Jun 18, 2018 2:13 am

Re: Wireguard tunnel to CHR and Public ip port forward

Sun Jan 08, 2023 11:37 pm

Yes to your questions,
but I have to see the current configs of both to provide advice..........
i am posting the configs:

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=\
    "PUBKEY"
add allowed-address=10.10.10.3/32,192.168.1.0/24 comment=PI interface=WG-CHR \
    persistent-keepalive=25m public-key=\
    "PUBKEY"
/ip address
add address=XXXXXXXX/24 interface=ether1 network=XXXXX
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=185.31.172.240,89.188.29.4
/ip firewall address-list
add address=10.10.10.2 list=authorised
add address=XXXXX 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=10.10.10.3 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=xxxxx
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=xxxx
set api disabled=yes
set winbox port=xxxx
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
CHATEAU
/interface bridge
add admin-mac=18:FD:74:8F:32:2A auto-mac=no comment=defconf name=bridge \
    priority=0x1000
/interface lte
set [ find default-name=lte1 ] allow-roaming=no band=""
/interface wireless
set [ find default-name=wlan1 ] band=2ghz-b/g/n country= disabled=no \
    distance=indoors installation=indoor mode=ap-bridge ssid=ROG \
    wireless-protocol=802.11
set [ find default-name=wlan2 ] band=5ghz-a/n/ac channel-width=\
    20/40/80mhz-XXXX country=  disabled=no distance=indoors frequency=\
    auto installation=indoor mode=ap-bridge skip-dfs-channels=all ssid=ROG \
    wireless-protocol=802.11
/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
/interface lte apn
set [ find default=yes ] use-network-apn=no use-peer-dns=no
/interface wireless security-profiles
set [ find default=yes ] authentication-types=wpa-psk,wpa2-psk mode=\
    dynamic-keys supplicant-identity=MikroTik
/ip hotspot profile
set [ find default=yes ] html-directory=hotspot
/ip pool
add name=dhcp_pool0 ranges=192.168.1.2-192.168.1.180
/ip dhcp-server
add address-pool=dhcp_pool0 interface=bridge lease-time=1w name=dhcp1
/interface bridge port
add bridge=bridge comment=defconf interface=ether1
add bridge=bridge comment=defconf interface=ether2
add bridge=bridge comment=defconf interface=ether3
add bridge=bridge comment=defconf interface=ether4
add bridge=bridge comment=defconf interface=ether5
add bridge=bridge comment=defconf interface=wlan1
add bridge=bridge comment=defconf interface=wlan2
/ip neighbor discovery-settings
set discover-interface-list=LAN
/interface list member
add comment=defconf interface=bridge list=LAN
add comment=defconf interface=lte1 list=WAN
/ip address
add address=192.168.1.1/24 comment=defconf interface=bridge network=\
    192.168.1.0
/ip dhcp-server network
add address=192.168.1.0/24 gateway=192.168.1.1
/ip dns
set allow-remote-requests=yes servers=1.1.1.1,1.0.0.1
/ip dns static
add address=192.168.88.1 comment=defconf name=router.lan
/ip firewall filter
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=drop chain=input comment="defconf: drop all not coming from LAN" \
    in-interface-list=!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=fasttrack-connection chain=forward comment="defconf: fasttrack" \
    connection-state=established,related hw-offload=yes
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=drop chain=forward comment=\
    "defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat \
    connection-state=new in-interface-list=WAN
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" \
    ipsec-policy=out,none out-interface-list=WAN
/ipv6 firewall address-list
add address=::/128 comment="defconf: unspecified address" list=bad_ipv6
add address=::1/128 comment="defconf: lo" list=bad_ipv6
add address=fec0::/10 comment="defconf: site-local" list=bad_ipv6
add address=::ffff:0.0.0.0/96 comment="defconf: ipv4-mapped" list=bad_ipv6
add address=::/96 comment="defconf: ipv4 compat" list=bad_ipv6
add address=100::/64 comment="defconf: discard only " list=bad_ipv6
add address=2001:db8::/32 comment="defconf: documentation" list=bad_ipv6
add address=2001:10::/28 comment="defconf: ORCHID" list=bad_ipv6
add address=3ffe::/16 comment="defconf: 6bone" list=bad_ipv6
/ipv6 firewall filter
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 ICMPv6" protocol=\
    icmpv6
add action=accept chain=input comment="defconf: accept UDP traceroute" port=\
    33434-33534 protocol=udp
add action=accept chain=input comment=\
    "defconf: accept DHCPv6-Client prefix delegation." dst-port=546 protocol=\
    udp src-address=fe80::/10
add action=accept chain=input comment="defconf: accept IKE" dst-port=500,4500 \
    protocol=udp
add action=accept chain=input comment="defconf: accept ipsec AH" protocol=\
    ipsec-ah
add action=accept chain=input comment="defconf: accept ipsec ESP" protocol=\
    ipsec-esp
add action=accept chain=input comment=\
    "defconf: accept all that matches ipsec policy" ipsec-policy=in,ipsec
add action=drop chain=input comment=\
    "defconf: drop everything else not coming from LAN" in-interface-list=\
    !LAN
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=drop chain=forward comment=\
    "defconf: drop packets with bad src ipv6" src-address-list=bad_ipv6
add action=drop chain=forward comment=\
    "defconf: drop packets with bad dst ipv6" dst-address-list=bad_ipv6
add action=drop chain=forward comment="defconf: rfc4890 drop hop-limit=1" \
    hop-limit=equal:1 protocol=icmpv6
add action=accept chain=forward comment="defconf: accept ICMPv6" protocol=\
    icmpv6
add action=accept chain=forward comment="defconf: accept HIP" protocol=139
add action=accept chain=forward comment="defconf: accept IKE" dst-port=\
    500,4500 protocol=udp
add action=accept chain=forward comment="defconf: accept ipsec AH" protocol=\
    ipsec-ah
add action=accept chain=forward comment="defconf: accept ipsec ESP" protocol=\
    ipsec-esp
add action=accept chain=forward comment=\
    "defconf: accept all that matches ipsec policy" ipsec-policy=in,ipsec
add action=drop chain=forward comment=\
    "defconf: drop everything else not coming from LAN" in-interface-list=\
    !LAN
/system clock
set time-zone-name=Europe/Athens
/system identity
set name=HomeRouter
/system routerboard mode-button
set enabled=yes on-event=dark-mode
/system script
add comment=defconf dont-require-permissions=no name=dark-mode owner=*sys \
    policy=ftp,reboot,read,write,policy,test,password,sniff,sensitive,romon \
    source="\r\
    \n   :if ([system leds settings get all-leds-off] = \"never\") do={\r\
    \n     /system leds settings set all-leds-off=immediate \r\
    \n   } else={\r\
    \n     /system leds settings set all-leds-off=never \r\
    \n   }\r\
    \n "
/tool mac-server
set allowed-interface-list=LAN
/tool mac-server mac-winbox
set allowed-interface-list=LAN
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 19324
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: Wireguard tunnel to CHR and Public ip port forward

Mon Jan 09, 2023 4:06 am

CHR.

(1) I would move the first rule on the input chain to where the current rule is to allow WG connections.....
Also modified the last rule comment to reflect accuracy.

So it would look like this......
/ip firewall filter
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=accept chain=input comment="Access CHR from WG" in-interface=\
WG-CHR src-address-list=authorised

add action=drop chain=input comment="drop all else"

(2) On the forward chain I am assuming the in out rule for WG is for traffic that is using the CHR as a relay only. Exits the tunnel and enters the tunnel heading for another site/user ?????
If so an explanation will help.........

(3) Also need to change the comment of the last rule in the forward chain for accuracy to.......
add action=drop chain=forward comment="drop all else'


(4) However I see now an error, you do have a port forwarding rule on the CHR.......... and thus you need the last two rules on the CHR to look like this.....
add action=accept chain=forward comment="allow port forwarding" connection-nat-state=dstnat
add action=drop chain=forward comment="drop all else"


(5) What is the purpose of your raw rule for port 53. It is not necessary as you have the drop rule in the input chain, remove it.

(6) Why is the CHR peer (the second one have a keep alive, the need is on the linux server to have keep alive set.. not required on the CHR.

(7) The DST NAT RULE you have is incorrect, you are not port forwarding to the servers WG address you are forwarding to the Servers local IP address. THUS
add action=dst-nat chain=dstnat dst-port=8080 in-interface=ether1 protocol=\
tcp to-addresses=1192.168.1.XX to-ports=8080



(8) The routing is incorrect................
Change to................ So that when users are attempting to reach the server, the router will allow them via firewall rules to hit the LAN or in this case the wireguard tunnel.
/ip route
add dst-address=0.0.0.0/0 gateway=xxxxx
add dst-address=192.168.1.0/24 gwy=WG-CHR table=main



+++++++++++++++++++++++++++++++++++++

I am not familiar with linux usage and thus cannot assist at the other end, my preference would be to use the Chateau as a client and keep the linux out of wireguard loop.

Who is online

Users browsing this forum: svh79, youngster2002 and 92 guests