RB4011 / hEX routers upgrade & VPN connections

QuantumAalfa · Sat Feb 17, 2024 2:09 am

My first first post.. please be kind & help me:

Background:
I have two Mikrotik Routers and connected with IPsec VPN with IKEY2 certificate. Both are 12000 kms away.

Home A :
Router : RB4011iGS+
firmware : v6.49.10
Internet : Dynamic public IP - but stays same for months unless I turn off modem for 3 - 4 days
Act as IPSec VPN server
DHCP Server range : 192.168.1.1 to 192.168.1.100

Home B:
Router : hEX RB750Gr3
firmware : v6.49.10
Internet : CGNAT - public IP not available
DHCP Server range : 10.10.10.50 to 10.10.10.100
Act as IPSec VPN client. Only three computers 10.10.10.51, 52 & 53 - full tunnel go through VPN server - 100% of time - whenever they are on.

Everything works fine. No issue at all.

Now Questions:
Is it safe to keep ROS on v6.49.XX?
I'm getting this : input: in:ether1 out:(unknown 0), src-mac 00:17:10:10:c1:7c, proto TCP (SYN), 3.17.141.240:53606->XX.XXX.XX.XXX:3414, len 52 and I'm worried.
See snapshot

Capture 001.JPG

I want to take advantage of wireguard VPN & it's possible in v7 only. Should I update both routers to ROS v7.XXX?
If I upgrade both to v7 - will my existing configuration including VPN will carry forward? Full tunnel VPN from B to A is my prime requirement.

Secondary questions after v7 upgrade:
At Home A (public IP available):
if I set-up wiregurad server OR back to home VPN, will it create full tunnel so that whenever family member travelling abroad can use WG vpn when less secure WIFI like motel, restaurant, etc?

At Home B (behind CGNAT - public IP NOT available): is wireguard server or back to home VPN possible? I really want my laptop to connect to home B and use home B internet access.

Thanks in advance.

TheCat12 · Sat Feb 17, 2024 9:33 pm

The logs in question are due to turned on logging on some of the firewall rules, an input chain one. For the secondary questions, in theory there should be no disturbance of the IKEv2 connection and you could set Back to Home VPN server on the router with CGNAT and add your family members as clients + no need for Wireguard site-to-site because this VPN is so flexible that it could travel through the IPsec tunnel

QuantumAalfa · Mon Feb 19, 2024 5:07 am

Thanks @TheCat12 for the reply.

Who is 104.152.52.24 or 3.17.141.240? Why it generating traffic from in side to out?

I guess first I save my config on both routers & update to v7 and hope IPSEC will work as usual without hiccups. Is ir possible to reverse back yo V6 if any thing goes wrong?

for RB750Gr3 based on this viewtopic.php?t=202297 - BTH vpn not possible id behind CGNAT?

gabacho4 · Mon Feb 19, 2024 5:57 am

Given the distances you mentioned I would not try to upgrade remotely. If something fails, you'll have no way to recover without making a trip in person.

gabacho4 · Mon Feb 19, 2024 6:07 am

Sorry, to answer your other questions, RoS 6 is only getting security updates at this time. Staying on the most current release should be safe. However, you won't have features like Wireguard and I think it's safe to assume that Mikrotik will stop supporting RoS 6 sooner than later.

If you update to RoS 7, your configuration SHOULD carry over. I emphasize SHOULD because nothing is 100% guaranteed.

If you set up Wireguard at Site A then anyone you set a connection up for should be able to connect. As for Site B, due to CG NAT, a standard Wireguard set up will not work. You need to either request/pay for a static IP, or use something like zerotier.

As for the IPs you asked about, the IP beginning with 104 belongs to Rethem Hosting LLC ( might be a CDN for streaming services) and the other belongs to Amazon.

Again, given the distances you are dealing with, I would not upgrade the remote router unless you are physically there or if there is someone technically capable of recovering your router config should the upgrade go badly. I'd also consider replacing the Hex with another 4011 or a RB5009.

TheCat12 · Mon Feb 19, 2024 7:39 am

@QuantumAalfa You are correct about the hEX - unfortunately the architecture of the router doesn't support BTH VPN. But you could set it up on Router A and in theory you should be able to access Router B through the IPsec tunnel based on personal experience. As for the previous posts about ROS 6 vs. 7, it is true that nothing is 100% guaranteed to work out as planned, so it's up to you whether you want to upgrade one/both of the routers given the great distance between them. But it is possible to downgrade a router from ROS 7 to 6 because the factory software in your case is 6.x (lesser than 7). Lastly, the unknown IP addresses you are worrying about are from Amazon AWS and an open-source project whicj scans all servers on the internet

QuantumAalfa · Mon Feb 19, 2024 7:54 pm

Thanks gabacho4 & TheCat12 for quick replies. It's good that traffic from Amazon's project & I don't have to worry.

Thanks for caution for physical presence of someone to update hEX. I had my family member to help with remote desktop.

I finally pulled trigger and updated both routers to ROS7. Save config before upgrade. Both upgraded first to v7.12.1 & then 7.13.4. Upgraded smoothly - no hiccups. IPSEC works same as before. That's very very good. I'm relieved.

For RB4011 - BTH VPN option available. On cell phone, in back to home android app, it can not connect router on same wifi network. I tried many times - BTH app comes with error : Could not connect to 192.X.X.X. However, I scanned QR code in BTH app, it imported but can not connect. But, when I scanned on wireguard app, imported and it's working. I don't know what's wrong with BTH app. (Note: QR code on winbox, displays partial ONLY. Need to copy & paste to Notepad & scan QR code on adnroid app)

for hEX, - BTH VPN option is not available.

. What are my options or how to get VPN on this without buying new router?

TheCat12 · Mon Feb 19, 2024 8:10 pm

One option would be to buy another router which supports BTH VPN (any router with arm, arm64, tile as architecture, for instance hAP ax lite), although as I said earlier you should be able to access the hEX via the WG which you have already configured on the RB4001. Try to ping it and see if it's reachable (at least to the VPN network). Maybe from there on it's possible to add firewall rules, etc. In my case I have added a firewall rule which allows administration of the router only through IPsec (ipsec-policy=in:ipsec) which would also explain why I can't access the LAN network so easily

Mesquite · Mon Feb 19, 2024 8:55 pm

The RB has a public IP, there is no need for BTH. Or another router!
Am I missing something the OP said??

Quote:" Home A :
Router : RB4011iGS+
firmware : v6.49.10
Internet : Dynamic public IP - but stays same for months unless I turn off modem for 3 - 4 days. "unquote"

Setup the RB as a proper server for handshake wireguard router Then any client device an connect to it be it:
a. iphone
b. windows pc
c. Hex router at another location.

RB setup
wireguard IP: add address=192.168.68.1/24 interface=wireguardRB network=192.168.68.0

listening port 15445
name=wireguardRB
private key=xxxx who cares.
public key= ( this is what you use on the peer settings on all clients, on their peer setting line for the RB (aka hex and remote devices) )

Peer Setup
allowed ips= 192.168.68.2/32 interface=wireguardRB public-key=(public key issued from remote device A)
allowed ips= 192.168.68.3/32 interface=wireguardRB public-key=(public key issued from remote device B)
allowed ips= 192.168.68.3/32,HexSubnet1,HexSubnet2 etc. interface=wireguardRB public-key=(public key issued from remote HEX)

Note where a router is a client, we should add the subnets from the hex if they are involved in any traffic
a. users/admin on RB need to reach hex subnets
OR
b. users/admin on HEX needs to reach RB subnets.

TO match the hex subnet traffic the RB needs routes if applicable, as the subnets are NOT local to the RB. This allow Hex subnet users return traffic back into the tunnel.
This allows local RB users, originating traffic, a path into the tunnel to reach Hex subnets.
This allows remote users coming into the RB and needing to reach the hex subnets.

/ip route
add dst-address=HEXsubnet1 gateway=wireguardRB routing-table=main
add dst-address=HEXsubnet2 gateway=wireguardRB routing-table=main
etc.

Firewall rules.
input chain
add chain=input action=accept dst-port=15445 protocol=udp comment="wireguard handshake"
add chain=input action=accept in-interface=wireguardRB src-address-list=Authorized.

where Authorized is a list of a IPs that are allowed to access the RB for config purposes.
- think admin on iphone, or PC while away (remote devices connected via wireguard)
- think admin while at the hex router physically and using an admin local IP address ( statically set from dhcp leases ).

Forward chain
add chain=forward action=accept in-interface=wireguardRB ( place valid destinations and limitations here)
add chain=forward action=accept in-interface=wireguardRB ( place valid destinations and limitations here)
etc....
You might simply have out-interface-list=LAN and thus anyone coming in wireguard can access all RB subnets.
THen you have to consider allowing traffic into the tunnel for local users who may want to reach the HEX
add chain=forward action=accept (place valid local users here) out-interface=wireguardRB

Finally, here is the neat rule, the RELAY rule. so that any remote user (iphone, laptop etc.... ) can access the hex through the RB
Remember WG is peer to peer, so any user connects to the RB, exits the tunnel and is sitting parallel to the LAN level.
That traffic then needs to reenter the tunnel heading towards the Hex......
add chain=forward action=accept in-interface=wireguardRB out-interface-wireguardRB

Interface list........ Common is to add wireguard to interface-list=LAN.
This allows us to make use of existing rules, allow LAN to DNS services in input chain to resolve internet requests. (PLUS).
This allows us to make use of existing LAN to WAN firewall rules, permission to use local WAN......

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

THe HEX>......
wireguard IP: add address=192.168.68.3/24 interface=wireguardHEX network=192.168.68.0

listening port 13231 (doesnt matter what this is default is fine )
name=wireguardRB
private key=xxxx who cares.
public key: (This is what you use on on the RB device, when configuring the peer line for the hex )

Peer Setup
allowed ips= 192.168.68.0/24,RBsubnet1,RBsubnet2 interface=wireguardHex
endpoint-address=mynetnameIPcloud(RBRouter): endpointport:15445 public-key=(public key issued from RB)
persistent-keep-alive=35s

Note where a router is a client connecting to a router server for handshake,, we should add the subnets from the RB if they are involved in any traffic
a. if any RB subnet users are coming to the HEX or
b. if any RB subnets need to reached by local Hex Users.....

Note: Any remote devices, iphones, laptops etc, can reach the hex due:
a. the relay rule on the RB
b. the IP routes for the hex subnets
c. they have a WIREGUARD ADDRESS 192.168.68.X which if you look at the peer setup, are already included and thus filtered and accepted by the HEX.

As per the other router, need to establish IP routes for any subnets identified in allowed Ips.
Traffic coming from or Traffic headed to those subnets.
/ip route
add dst-address=RBsubnet1 gateway=wireguardHEX routing-table=main
add dst-address=RBsubnet2 gateway=wireguardHEXrouting-table=main
etc.

Firewall rules.
input chain
add chain=input action=accept in-interface=wireguardHEX src-address-list=Authorized.

where Authorized is a list of a IPs that are allowed to access the HEX for config purposes.
- think admin on iphone, or PC while away (remote devices connected via wireguard)
- think admin while at the RB router physically and using an admin local IP address ( statically set from dhcp leases ).

Forward chain
add chain=forward action=accept in-interface=wireguardHEX ( place valid destinations and limitations here)
add chain=forward action=accept in-interface=wireguardHEX ( place valid destinations and limitations here)
etc....
You might simply have out-interface-list=LAN and thus anyone coming in wireguard can access all HEX subnets.

Finally you have to consider allowing traffic into the tunnel for local users who may want to reach the RB
add chain=forward action=accept (place valid local users here) out-interface=wireguardHEX

Mesquite · Mon Feb 19, 2024 9:04 pm

https://help.mikrotik.com/docs/display/ROS/WireGuard

This covers the road warriors ( aka single devices well, windows, ubuntu.)
https://www.youtube.com/watch?v=CH10spRyGpU&t=80s

Road warrior google play store:
https://www.youtube.com/watch?v=jcNkytR ... 9uZQ%3D%3D

Road warrior smartphone
https://www.youtube.com/watch?v=vn9ky7p5ESM&t=8s

TheCat12 · Mon Feb 19, 2024 9:17 pm

When he has already setup BTH and has an active IPsec tunnel, why bother creating a new wireguard site-to-site connection? This thing is really flexible - I've got a real-life situation where I have setup a cAP ax as a BTH server and that was enough to have access to:

a. the cAP ax itself
b. A RB3011, to which the AP is connected and acts as an IKEv2/IPsec client
c. Another RB3011 that is the IKEv2 server

Note: The IKEv2 client is behind CGNAT and has a dynamic IP but that doesn't bother the BTH VPN because it can pass through it and uses relay servers. That's what this new function of MikroTik is capable of. Also, I use it as a fallback solution in case of a crash of the IKEv2 connection so that I can still access the remote side

Mesquite · Mon Feb 19, 2024 9:21 pm

The hex doesnt have BTH nor needs BTH, it can connect to the RB just fine using standard wireguard setup.
Concur, great new functionalities have been added by MT to allow this punching through non-public IP addresses, when necessary.

Telling the OP they should spend money when there is a perfectly good solution is ridonkulous.

TheCat12 · Mon Feb 19, 2024 9:26 pm

No one is saying that money should be spent - the BTH which they have already configured on the RB should be able to access the hEX without any further configuration/equipment. If that's not the case, then @Mesquite's configuration would be advisable. I was just giving an alternative if they really wanted a second BTH server but it's unnecessary, I agree

Mesquite · Mon Feb 19, 2024 9:32 pm

Easiest (and only) solution would be to buy another router which supports BTH VPN
Complete Baloney Sandwich

Own it and move on, weaseling like a politician is unbecoming.

TheCat12 · Mon Feb 19, 2024 9:52 pm

OK, OK, I didn't mean to imply that this is the only and the greatest option, it was a misexpression from my side for which I sincerely apologize. I edited my comment accordingly so it doesn't showcase the critisized option as the only one. @Mesquite is right, there is absolutely no need to buy anything

Mesquite · Mon Feb 19, 2024 10:25 pm

Hopefully the OP will respond soonest so the additional support can be provided. If I ever see a thread where BTH is the answer I know who to call, I am brain dead on that functionality.
What I find awkward is someone having to deal with weird BTH menus when trying to setup basic (normal) wireguard, and one has a parameter of client address in peer settings for example..........

QuantumAalfa · Mon Feb 19, 2024 11:18 pm

Thanks Mesquite and TheCat12 for your inputs.

I'm currently NOT planning to buy any new equipment as existing two routers were set-up by one freelancer Mikrotik certified person & now left mikrotik field and working for other company and not available for now. He did so nicely including failover, I never had any problem still today. But I'm by mine own now.

I know these routers basic networking but don't have deep knowledge.

Mesquite, Thanks for posting light of direction. It's too technical for me at this stage BUT I'm going to work on it. Let me first digest and understand.

I think, to setup WG server on RB4011 is not that complicated & I just watched one youtube video for that. With help of your above input and youtube video, I should be able to setup. Say, Part 1: RB4011 WG server - for road warriors (phone, laptop etc.) is solved.

Now, hEX to RB4011, already IPSEC vpn working fine & not touching that part. Ping from RB subnet user to hEX subnet user works. Also, share folder is accessible on both sides by both sides users.

So do we need to add hEX as WG client? if we add hEX as WG peer/client, WG act as another secondary tunnel if IPSEC fails?
Yes, hEX subnet 3 users only (10.10.10.51, 52 & 53) need to connect and access one RB subnet user (191.168.1.102). But no restriction from RB to hEX - ALL user on RB can access hEX.

I'm looking to add on-demand VPN full tunnel for couple of RB users to hEX internet. (simplified example netflix access of hEX country). I need access once a week only.

gabacho4 · Tue Feb 20, 2024 12:26 am

OP said he wanted devices to connect to a hex that is behind CGNAT for VPN purposes (i.e. Road warrior setup). There is no way to do that via a standard Wireguard config due to the CGNAT. Thus he needs a device capable or running zerotier or similar technology. At least that was one of the requirements that I understood from his initial and a subsequent posting. He wasn't just looking to replace the IPSEC site to site. He wanted remote devices to be able to connect to site A and site B.

QuantumAalfa · Tue Feb 20, 2024 12:59 am

Thanks Gabacho1,

Home B (hEX) to Home A (RB4011) - 100% works - no issue including full tunnel by IPSEC and not planning to change unless required. As soon as hEX boots, it connects to RB4011 with IPSEC and 3 computer have access to computer and internet browsing on RB4011.

Now after ROS v7 upgrade, I want from Home A (only two users) need Home B internet browsing (on-demand - as and when required - not all the time) .

gabacho4 · Tue Feb 20, 2024 1:32 am

Ah ok. That's much clearer now. I am not sure how you will do the "on demand" portion of that from A to B since B is the initiator in your setup. There's no way for A to initiate the IPSEC connection should there be interesting traffic due to the CGNAT as site B. Furthermore I don't think routed IPSEC supports what you are trying to do when access to the Internet is desired due to the way the routes work. You'd need VTI IPSEC (not supported in Mikrotik) or Wireguard or some other way to do policy based routing based in destination or source IP or list.

Mesquite · Tue Feb 20, 2024 4:47 am

All very doable, the hex connects to the RB4011 as a wireguard client and that tunnel then allows local users at the RB to reach the HEX as well as any users reaching the RB via wireguard.

QuantumAalfa · Tue Feb 20, 2024 5:13 am

Hi Mesquite,

existing IPSEC connections, both users can connect with each other without problem. And hEX users has RB4011 internet browsing.

Can you please explain how to do this? RB4011 as WG server + hEX as WG client - now how to get internet browsing from users on RB4011 pass through hEX?

gabacho4 · Tue Feb 20, 2024 6:53 am

All very doable, the hex connects to the RB4011 as a wireguard client and that tunnel then allows local users at the RB to reach the HEX as well as any users reaching the RB via wireguard.

I feel like I'm taking crazy pills. Anav I don't understand why you're being difficult. The OP has said repeatedly he wants to stick with IPSEC if possible. What he wants is not possible via routed IPSEC. So no, it isn't all very doable given the constraints the OP keeps setting. Discussion of Wireguard is fair but if outside the set-up the OP has repeatedly said he wants. I've recommended Wireguard myself multiple times.

OP - if you are flexible ( and you really should be as wireguard is much better for your use case and easier to configure) then Mesquite/Anav is your man. He'll get you set up. You need to decide what you want to do.

TheCat12 · Tue Feb 20, 2024 8:24 am

The OP could setup IPsec road warriors on the RB and use a similar configuration to the one that is described in the following topic I attached to reroute their traffic through the IPsec tunnel:

viewtopic.php?t=188935

Tue Feb 20, 2024 8:53 am

I'm not going to intervene in the rest of the discussion but ...

OP said he wanted devices to connect to a hex that is behind CGNAT for VPN purposes (i.e. Road warrior setup). There is no way to do that via a standard Wireguard config due to the CGNAT.

Why not ?
You only need ONE public IP (doesn't even have to be static, dynamic is also possible using small script to catch changes) with capable router which you can use as pivot point (Hex going out, building up the tunnel) and then you come back in via that same tunnel.
I've done it for years with SXT LTE this way.

TheCat12 · Tue Feb 20, 2024 10:09 am

@holvoetn is correct. Whatever configuration they choose, it would be possible because there is atleast one public IP that is de facto static and could be used for whatever VPN they want

Mesquite · Tue Feb 20, 2024 1:34 pm

I feel like I'm taking crazy pills.

You are LOL.

The OP stated early on........ Quote:"I want to take advantage of wireguard VPN.. " unquote.
Then cat interjected incorrectly stating the OP had to use BTH and nevermind normal wireguard VPN, further the hex cannot do BTH not being arm/arm64 etc..
Then you stated incorrectly, that the HEX would not work with a standard setup due to cgnat, missing completely the hex was to be solely a client.

Thus a comedy of errors from well intentioned people.

Mesquite · Tue Feb 20, 2024 1:37 pm

@Quantam Alfa, its time you did some work here....... I provided very clear instructions on what needed to be setup on both routers. I also provided links to good videos.
Take the configs you have now, pulled from both routers, and work on them in notepadd++ and then present here for review. I understand you cant start changing them willy nillly due to distance etc. but you can work on the configs on paper, so to speak, so that when you apply them for real, you will have a solid experience.

QuantumAalfa · Tue Feb 20, 2024 6:02 pm

Mesquite,

As suggested, I'm going to work on WG set-up. It's steep learning curve for me but with help of your and others posts/guidance, it's doable.

Time difference between A & B is 10.50 hrs. & I don't want do changes without someone presence at B. At least, I will setup road-worrier set on RB today.

Thanks again everyone. I will keep posting progress.

QuantumAalfa · Wed Feb 21, 2024 6:58 pm

@Mesquite,

I followed your guide & youtube videos but WG server setup NOT successful on RB4011. Watched all videos - non required to make changes in firewall in RB4011 for Windows 10 laptop or cell phone. I tried again and again but no connection.

See attached screen shot:

Mesquite · Wed Feb 21, 2024 9:26 pm

Post the complete config ( less public WANIP info, router serial number, any KEYS ) to see what is going on.

QuantumAalfa · Wed Feb 21, 2024 9:50 pm

Hi Mesquite,

I exported config file with command : /export file=config hide-sensitive

But has all sensitive info.... too many to edit or I may miss it

Wed Feb 21, 2024 9:52 pm

Don't use hide sensitive.
Default ROS7 is to hide most (not all) sensitive info.

Just use /export file=anynameyouwish
Edit that file. There shouldn't be too much sensitive info in there.

gabacho4 · Wed Feb 21, 2024 10:03 pm

I feel like I'm taking crazy pills.
You are LOL.

Oh holy crap! I went back and read and wow. I've got no excuse other than I'm an idiot. Clearly my guidance would have been different, and in line with yours, had I had the literacy of a 2 yr old. I'll administer a self beating that would make a Canadian like you proud Mesquite.

Mesquite · Wed Feb 21, 2024 10:39 pm

Don't use hide sensitive.
Default ROS7 is to hide most (not all) sensitive info.

Just use /export file=anynameyouwish
Edit that file. There shouldn't be too much sensitive info in there.

Concur, remove router seriaal number, any keys public private etc, any public WANIP info or WAN gateway IP info, long assed dhcp lease lists

Mesquite · Wed Feb 21, 2024 10:40 pm

You are LOL.
Oh holy crap! I went back and read and wow. I've got no excuse other than I'm an idiot. Clearly my guidance would have been different, and in line with yours, had I had the literacy of a 2 yr old. I'll administer a self beating that would make a Canadian like you proud Mesquite.

My unofficial job is to keep you in line

I get bonus pay for that!

QuantumAalfa · Wed Feb 21, 2024 10:49 pm

Hi,

please find requested config file.

Mesquite · Wed Feb 21, 2024 11:29 pm

Lets look at the facts.

1. Defining wg interface - great!
add comment="My wireguard Server on RB4011" listen-port=15445 mtu=1420 name=\
wireguardRB

2. Defining peer client device - great!
( currently only one, could be phone, could be laptop, phone is easier to check with cellular connection as the external remote in path )
/interface wireguard peers
add allowed-address=192.168.68.2/32 interface=wireguardRB public-key=\
"jl8XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXxxrRA="

3. Define IP address - great!
add address=192.168.68.1/24 comment="My wireguard Server on RB4011" \
interface=wireguardRB network=192.168.68.0

4. ( as an aside, your block DNS rules in input chain are half baked, you dont cover ISP2 - ether10 at all...................

5. ( as an aside, big no no in general to allow winbox access from external WAN..............Most would NEVER do this..
add action=accept chain=input comment="Accept Winbox From WAN" dst-port=XXXX \
in-interface-list=WAN protocol=tcp

6. ( as an aside fw rules are horrible IMHO )

7. MISSING - input chain rule to allow wireguard handshake!!!!
From:
add action=accept chain=input comment="Allow IPSec Authentication ISKAMP" \
dst-port=500 protocol=udp
add action=accept chain=input comment="Allow IPSec Nat Traversal" dst-port=\
4500 protocol=udp

TO:
add action=accept chain=input dst-port=15445 protocol=udp comment="wireguard handshake"
add action=accept chain=input comment="Allow IPSec Authentication ISKAMP" \
dst-port=500 protocol=udp
add action=accept chain=input comment="Allow IPSec Nat Traversal" dst-port=\
4500 protocol=udp

8. Whether or not the incoming user will be able to get to subnet devices, WAN, or config the router will be determined by the firewall rules and had no stomach to look through them.

QuantumAalfa · Wed Feb 21, 2024 11:52 pm

Thanks for quick reply:

Item # 4 - ISP2 - ether10 - Not in use anymore. But planning get again. Pl help me to revise it.
Item # 5 - winbox excess from WAN - I disabled it now. like this:

WG setup 2.jpg

is that OK or I need to delete that line?
Item # 6 - ??
Item # 7 - added wireguard handshake - see abobe snap
Item # 8 - ??

update:
Greetings... WG connected & working on android ph

Mesquite · Wed Feb 21, 2024 11:58 pm

Accept winbox from the LAN only and if you know which IPs, use a source address list to narrow it down.
The LAN users still need access for DNS services by the way.
Also if you need remote access add the wireguard address to the allowed source address list noted above.

QuantumAalfa · Thu Feb 22, 2024 12:29 am

WG setup 3.jpg

& action - accept

Winbox connection from cell ph Mikrotik app - does not work.

Mesquite · Thu Feb 22, 2024 3:59 am

Thats because your rule is not correct.

Lets work through the logic!

a. the input chain rule for wireguard permits the handshake and makes the tunnel happen between the android phone and the MT.
Once connected think of the phone basically parallel to the LAN............

b. to allow the phone to subnets on the router one example of many:
add action=accept chain=forward in-interface=wireguardRB dst-address=subnet

c. to allow the phone to access the router ( aka winbox it or phone APP in ).
Its like any other access.
add action=accept chain=input in-interface=wireguardRB
OR
add action=accept chain=input in-interface=wireguardRB src-address=192.168.68.2
OR
add action=accept chain=input src-address=192.168.68.2

DONE!!!
No need for ports or any other stuff....

The real trick is that to access winbox, once the tunnel is up, type the following into your phone app!! or winbox on a pc..........
192.168.68.1:winboxPort#

QuantumAalfa · Thu Feb 22, 2024 5:17 am

Thanks Mesquite,

I tried the rules but still did not worked.

Before WG winbox access I need to fix:
All the time I used Winbox with MAC address but whenever I use with IP address of 192.168.1.1, connection time out error.

Mesquite · Thu Feb 22, 2024 1:05 pm

From where?
If you mean a computer on your LAN, and you want to use ip address
then its 192.168.1.1:winboxport#

If rules dont work, then its likely due to your firewall rules.
Suggest go back to defaults and focus on needed traffic vice blocking traffic.

Something like this where all traffic not specifically allowed is dropped already, no need for extra rules.

/ip firewall filter
{Input Chain}
( default rules to keep )
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
( admin added rules, also where you add all your VPN rules )
add action=accept chain=input in-interface-list=LAN
add action=drop chain=input comment="drop all else" { put this rule in last, without the LAN rule above you will be locked out }
{forward chain}
( default rules to keep )
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related
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
( admin added rules )
add action=accept chain=forward comment="allow internet traffic" in-interface-list=LAN out-interface-list=WAN[/b]
add action=accept chain=forward comment="allow port forwarding" connection-nat-state=dstnat[/color] { disable or remove if not required }
add action=drop chain=forward comment="drop all else"

johnson73 · Thu Feb 22, 2024 3:02 pm

QuantumAalpha..
We always use the "default" rules as the basis for the firewall section. User Mesquite posted an example for you. Use it as the basis for everything.
"Good practice" shows that we always start the Input chain with "accept established, related" and not with drop DNS 53. If we want to drop dns 53 port, then it must be done in RAW chain.
The end section of the firewall always ends with - add action=drop chain=forward comment="drop all else"
Firewall rule policy is executed from top to bottom. Incorrect sequence of records affects not only security but also overall operation, stability of traffic flow, etc.

TheCat12 · Thu Feb 22, 2024 3:11 pm

As for the Winbox access, you could enable the Accept Winbox from WAN rule but change it only to LAN because as @Mesquite said, when you connect to the WG, you are at LAN level, so no need and bad practice for the router to be accessible through WAN if you don't implement some secure address list, port knocking, etc.

QuantumAalfa · Thu Feb 22, 2024 5:01 pm

Thanks Mesquite, Johnson73 & TheCat12,

This first time I'm working on firewall rules & now I understood that rules priority is from top to bottom. I had "drop all else" middle of no where... As soon I moved to that rule to bottom, MT app on cell worked - both on LAN and on WG connection.

Mesquite, from your guidance, I think my some firewall rules may not necessary or some are messy. If I post rules again, can you please help me to clean, add new as required, delete whichever not required & arrange in correct order?

Mesquite · Thu Feb 22, 2024 6:59 pm

I will see what I can do.

QuantumAalfa · Thu Feb 22, 2024 8:36 pm

Thanks Mesquite,

Please find my partial config file:

my partial config.rsc

johnson73 · Thu Feb 22, 2024 8:57 pm

The Input section is where the traffic comes in, and the Forward section is for the traffic that goes through the router.
Try to divide so that the "Input" chain ends with input=drop all and Forward ends with forward=drop all. Then it will be correct.
You are missing entries. You can also add "port scan protect" entries to the Input section.
There is also useful information here - https://help.mikrotik.com/docs/display/ROS/WireGuard
In your version, the Input section looks something like this -

/interface wireguard
add listen-port=13231 name=wireguard1
/ip address
add address=192.168.68.2/24 interface=wireguard1
/interface list member
add interface=wireguard1 list=LAN
add interface=ether1 list=WAN
add interface=bridge1 list=LAN
/ip firewall address-list
add address=192.168.88.0/24 list=Admin

/ip firewall filter
{Input Chain}
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="allow wireguard " dst-port=13231 protocol=udp place-before=1
add action=accept chain=input comment="allow wireguard traffic" src-address=192.168.68.2/24 place-before=1
add action=accept chain=input src-address-list=Admin comment="Config Access"
add action=accept chain=input comment=L2TP dst-port=500,1701,4500 \
    in-interface-list=WAN protocol=udp
add action=accept chain=input comment="IKE IPSec" in-interface-list=WAN \
    protocol=ipsec-esp
add action=accept chain=input comment="Allow LAN DNS queries-UDP" \ 
dst-port=53 in-interface-list=LAN protocol=udp
add action=accept chain=input comment="Allow LAN DNS queries - TCP" \
dst-port=53 in-interface-list=LAN protocol=tcp
add action=drop chain=input comment="drop all else"

If you want to drop DNS requests, we do it on the RAW chain.

After that, the Forward chain will follow.

{forward chain}
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
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-list=LAN out-interface-list=WAN
add action=accept chain=forward comment="WG traffic" in-interface=Wireguard1 out-interface=LAN
add action=accept chain=forward comment="allow dst-nat from both WAN and LAN (including port forwarding)" connection-nat-state=dstnat
add action=drop chain=forward comment="drop all else"

Mesquite · Thu Feb 22, 2024 9:33 pm

I would only invoke other rules like raw, if you get issues........... With drop all, you shouldnt need raw.
By the way, the router cannot really prevent flooding etc.......... that is the job of the upstream providers.......

johnson73 · Thu Feb 22, 2024 10:02 pm

Of course, mikrotik is not intended for serious dns protection. This is usually provided by your ISP provider. It is possible to prevent only minor flood attempts. But this will be offtopic.

QuantumAalfa · Fri Feb 23, 2024 5:36 pm

Addition of new peers to WG server is easy after first peer. However, many copy & paste back and forth involved.

I just wondering, why in router full peer configuration is not created? Once created, either export configuration file to use in computers or use QR code to scan in phone apps.

On create new peer, once you select WG interface, can rest of the items populated automatically OR override as required & then apply?

QuantumAalfa · Tue Feb 27, 2024 3:26 pm

I will see what I can do.

Hi Mesquite,
Can you please look into? I appreciate your help!.
Thanks

Mesquite · Tue Feb 27, 2024 10:53 pm

First you have to do the work
Use this as a basis for all your rules and get rid of any raw ones etc...
Then add the additional rules you need for traffic to occur ( all the allow rules you need )

/ip firewall filter
{Input Chain}
(default rules to keep)
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 " dst-address=127.0.0.1
(add admin rules here)
add action=accept chain=input in-interface-list=LAN
add action=drop chain=input  comment="drop all else"  
{forward chain}
(default rules to keep)
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related
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 admin rules here)
add action=accept chain=forward comment="allow internet traffic"  in-interface-list=LAN out-interface-list=WAN
add action=accept chain=forward comment="allow port forwarding" connection-nat-state=dstnat  disabled=yes { enable if required }
add action=drop chain=forward  comment="drop all else"
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" out-interface-list=WAN

QuantumAalfa · Wed Feb 28, 2024 11:11 pm

Thank you Mesquite,

I will change rules accordingly

Who is online