Community discussions

MikroTik App
 
ErkDog
just joined
Topic Author
Posts: 23
Joined: Thu Dec 02, 2021 5:51 pm

Wireguard site to site with full tunnel.

Thu Aug 11, 2022 5:30 pm

I've tried and tried to get site to site Wireguard working with a full tunnel but can not get it to work.

I have Mikrotik: WAMT (This is the device all the tunneled traffic should go through)
I have Mikrotik: KMT (This is the device connecting with WAMT and that is trying to tunnel through WAMT).

I've gotten -real- close and UDP traffic appears to work, but TCP traffic will not. I've tried all the suggestions and changes that other people have suggested and said work but no joy.

Two configs are attached. (Please note I'm not concerned with Public IPs being listed, I took out Wireguard Keys & software and serial info.)
WAMT.rsc
KMT.rsc
You do not have the required permissions to view the files attached to this post.
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 19125
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: Wireguard site to site with full tunnel.

Thu Aug 11, 2022 6:04 pm

Before I look at the configs,
a. do both devices have publically accessible IPs, aka attached to WAN?
b. is your expectation that either side can initiate the tunnel or do you have one device that will initiate the tunnel and after two way traffic is expected.
c. will you be accessing subnets - users from KMT accessing subnets or devices on WAMT,
d. will you be accessing subnets - users from WAMT accessing subnets or devices on KMT,
e. will you be accessing the internet of KMT from WAMT (and if so is this for all subnets on WAMT)
f. will you be accessing the internet of WAM from KMT (and if so is this for all subnets on KMT)
g. Will the admin be accessing either device remotely for config purposes.......... (from lets say iphone etc.......)
 
ErkDog
just joined
Topic Author
Posts: 23
Joined: Thu Dec 02, 2021 5:51 pm

Re: Wireguard site to site with full tunnel.

Thu Aug 11, 2022 7:01 pm

Hey anav,

Currently the LAN Subnets of KMT and WAMT can communicate with each other.

They both have their own WAN transport with publically accessible IPs. Right now I have WAMT establishing a connection to KMT but once everything is working I will have far endpoints configured on both ends to each other.

The goal is for KMT to tunnel 100% of traffic out through WAMT's WAN connection.

I've setup the LAN of KMT to routing mark "via-wg" to avoid the problem of the 0.0.0.0/0 route causing the MT itself not to be able to route out to the internet.

So F is the setup that I'm aiming for.

Thanks,
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 19125
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: Wireguard site to site with full tunnel.

Thu Aug 11, 2022 9:44 pm

KMT
(1) since you have 0.0.0.0/0 entered as an allowed IP, there is no need to enter any others, they are all included. :-)

(2) Wireguard is a UDP protocol and thus one of your input rules is not required (should be removed).
add action=accept chain=input dst-port=13231 protocol=tcp
add action=accept chain=input dst-port=13231 protocol=udp

(3) Firewall rules and organization are lacking, the defaults are excellent with minor tweaking.
/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 dst-port=13231 protocol=udp
add action=accept chain=input in-interface-list=LAN
add action=drop chain=input comment="drop all else
{forward chain}
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="allow port forwarding" connection-nat-state=dstnat
add action=accept chain=forward comment="allow local subnet to enter wg tunnel \
      src-address=10.7.7.0/24  out-interface=wireguard1
add action=accept chain=forward  comment="allow remote subnet to exit tunnel \
     in-interface=wireguard1 dst-address=10.7.7.0/24 src-address=10.8.8.0/24
add action=drop chain=forward

NOTE: I tend to use the firewall rules to allow subnets to enter the tunnel and use firewall rules (at the other end, the receiving end) to be more explicit on where traffic exiting the tunnel is allowed to go! Hence the difference in the two rules above. The first one basically says yeah traffic from the subnet is allowed to enter the tunnel, especially practical if going out the remote site for internet. However if traffic is coming out of the tunnel, I want to ensure I configure at least the destination and the source is essential if you have multiple subnets possible..........

(5) Mangling is not required and remove (and thus fastrack is now part of forward chain rules)

(6) Missing but not totally necessary is interface and interface lists........ they are very handy to work with subnets. I prefer them over firewall address lists. One reason to use firewall address lists is if you have less than a subnet, like a single or group of IPs or a mix of subnets and a single, or group of IPs. The IPs could be from different subnets for example.
It may not be 100 percent necessary now but could be really useful down the line.

Thus suggesting add in
/interface list
add name=WAN
add name=LAN
/interface list members
add interface=ether1 list=WAN
add interface=LAN-Right-Half list=LAN

PS, this will work in the firewall chain as the LAN will have access to the router for DNS and NTP services.
If you want to maintain the separate rules for dns and ntp you can always do this.
add action=accept chain=input in-interface-list=LAN src-address-list=Admin dst-port=xxxxxx,yyyyyy protocol=tcp {winbox port
add action=accept chain=input comment="Allow LAN DNS queries-UDP" \ {and NTP *** services if required etc}
dst-port=53,123 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"
where src-address-list is a firewall address list of admin device or EVEN external IPs coming in from the internet.
For example on my own source address list, I have the wireguard IP I set to my iphone, so that I can wireguard into my router and then access the config.

(7) In terms of routing your LAN traffic, you do realize that we are moving all your subnet traffic out the wireguard tunnel and thus the routing would look like in basic terms.

add dst-address=0.0.0.0/0 gateway=ISPgateway table=main
add dst-address=0.0.0.0/0 gateway=wireguard1 table=via-wg

You already have the table built, now for the routing rule which will ensure all users go into the wireguard tunnel.
/routing rule add src-address=10.7.7.0/24 action=lookup-only-in-table table=via-wg

note: if you still wanted the users to be able to access the local WANIP if the wireguard tunnel was not working, then simpy change the action to: action=lookup

+++++++++++++++++++++++++++++
Where this gets tricky is later you have another local subnet and you want users to be able to access the other subnets.
In this case we add additional route rules prior to the internet one and there are multiple ways to achieve these sort of goals but the easiest is (and order counts)
/routing rule add dst-address=subnetB table=main
/routing rule add src-address=10.7.7.0/24 action=lookup-only-in-table table=via-wg

Here, the router will ensure that traffic from the subnet using internet (subnetA) to subnet B will take precedence.

(8) Looking at your routes, a bit of tweaking required, ..........
Get rid of distance between the routes you need they should all be set to default of 1.
The first wireguard one, ensures that any incoming remote subnet traffic has a path back to the tunnel after interacting with the local subnets.
The second wireguard route creates a route for all traffic originating on the local router to go out the tunnel and puts it in the via-wg table.
(the route rule then 'forces' the local subnet to that table and thus route).
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 19125
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: Wireguard site to site with full tunnel.  [SOLVED]

Thu Aug 11, 2022 11:09 pm

WAMT

(1) Same comment create both WAN and LAN interface list. I see that you have a WANS already assuming its a dual wan router setup.

(2) Recommend set to none as this function has caused issues in the past and its function is not well understood or used.
/interface detect-internet
set internet-interface-list=WANS wan-interface-list=WANS

(3) The wireguard peer settings are a tad more interesting...................
I see many peers on a single wireguard interface. The single addresses seem fine,
but more explanation is required for a third router in the mix.............ctrl creek router ???

Can you clarify before I go, if all the peers connect to the WAMT?
If so are there any of these where the reverse is true, the WAMT connects to another Wireguard device?

Ran out of time will look at fw rules and routes later.
 
ErkDog
just joined
Topic Author
Posts: 23
Joined: Thu Dec 02, 2021 5:51 pm

Re: Wireguard site to site with full tunnel.

Fri Aug 12, 2022 1:19 am

Yes WAMT has multiple other peers. I have an employee that uses a client WireGuard to get in to do QuickBooks.

Critter Creek is my parent's house so it allows me to access their security cameras without going across the open internet.

Then there's my phone so I can get to things from my phone if I'm out of the house, etc.

WAMT does in fact have two WAN connections on it right now. The consultant I hired from here had me setup a "WANIPs" List for rule targeting but not interfaces.
 
ErkDog
just joined
Topic Author
Posts: 23
Joined: Thu Dec 02, 2021 5:51 pm

[SOLVED] Re: Wireguard site to site with full tunnel.

Tue Aug 23, 2022 6:34 pm

With anav's direct assistance this was resolved.

It mostly involved him taking the time to explain in more detail how to do the things he had already suggested in this thread.

So if your smarter than me and can wrap your head around his suggestions, you'd be good to go :-D

Who is online

Users browsing this forum: No registered users and 41 guests