Community discussions

MikroTik App
 
kamicrazy
just joined
Topic Author
Posts: 1
Joined: Thu Feb 23, 2017 12:14 am

GRE Tunnels and Dual Wan on one side

Thu Feb 23, 2017 3:09 am

Hi

I'm new to the forum. I am reaching out for help with a problem I have getting a Mikrotik to function the way I hope.

The topology I am working with is simple. On the datacenter side is a single VyOS instance with a single IP address.
On the remote office side we have a Mikrotik which has two public IP's routed through different paths. So two default gateways, therefore Dual WAN setup.

So in this example lets use 103.49.151.X as the public IP for the VyOS and the Mikrotik has 103.22.19.A and 103.24.19.B.

The issue is I cannot reliably form two GRE tunnels between the Mikrotik and VyOS.
I have setup on both devices two tunnel configs.

So on Mikrotik I have configured two GRE tunnels as follows:

/interface gre add disabled=no local-address=103.22.19.A Name=Cloud3 remote-address=103.49.151.X
/interface gre add disabled=no local-address=103.24.19.B Name=Cloud4 remote-address=103.49.151.X

On the VyOS side I have two GRE tunnels defined just like above but with the endpoints changed so local-ip=103.49.151.X and remote-ip=A or B

After creating the tunnels I add IP addresses to both ends of each tunnel.

So on Mikrotik I configure:

For tunnel A /ip address add address=10.10.10.10/30 interface=Cloud3 network=10.10.10.8
For tunnel B /ip address add address=10.10.10.14/30 interface=Cloud4 network=10.10.10.12

On the VyOS side I give it IP's of 10.10.10.9 and 10.10.10.13 respectively.

What I am finding with this basic configuration is that the Mikrotik attempts to send outbound GRE packets from the interface which is currently the default route. If public IP A is the default gateway, then tunnel A will send and receive as expected over that interface but tunnel B will only receive traffic over public IP B and send traffic over public IP A.

I then tried to fix this by creating some mangle rules and route marks to mark the traffic for tunnel B so that it will send the traffic back out of public IP B once it receives traffic from the VyOS over public IP B. This only works temporarily.

If the Mikrotik is restarted then the mangle rules and route marks do not work. If I try to ping the tunnel interfaces after a reboot. One of them will be fine but the other one will just time out. In Winbox it states that only one of the tunnels is reachable in the routing table.
If I do a few pings from the VyOS side it will activate the other tunnel but traffic will still not pass. On the Mikrotik pings return "packet rejected" messages.

Strangely though I have found that opening the torch tool in winbox and pressing start makes both tunnels magically work at this point.

Can anyone please point me to either

1) Somehow bind gre tunnel B so that it will only send and receive over public IP B?
or failing that
2) show me how I can configure the mikrotik so that I can achieve the same effect?
or failing that
3) show me how I should setup the mangle rules so that it fixes the packet rejected messages after a reboot? There must be something happening here because starting the torch tool somehow fixes it.

Thanks for your responses in advance.
 
videoicu
just joined
Posts: 15
Joined: Sat Aug 07, 2010 4:11 pm

Re: GRE Tunnels and Dual Wan on one side

Mon Mar 20, 2017 7:22 pm

I want to confirm to you that I am experiencing a very similar issue. I have dual WAN on MT Router 1 and single WAN on MT Router 2. When I set up two GRE tunnels between MT A WAN 1 -> MT B WAN 1 and MT A WAN 2 -> MT B WAN 1 all traffic shows arrival on MT B on a single GRE tunnel but the traffic is clearly split on MT A going out. This swaps if you change the default route as you say.

I use IP Mangle with router marks in prerouting chain on MT A to separate the input via two subnets 192.168.10.0/25 and 192.168.10.128/25

I would hope someone might have some sense as to what in the configuration might be incorrect. All seems well except it "enters" both tunnels but arrives in a single tunnel.
 
videoicu
just joined
Posts: 15
Joined: Sat Aug 07, 2010 4:11 pm

Re: GRE Tunnels and Dual Wan on one side

Mon Mar 27, 2017 3:37 pm

It was discovered that although on single WAN routers with GRE tunnels, the GRE local address can be left blank (default), it is not the case on dual WAN routers and (as most hindsight is) the config of the dual GRE tunnels require an IP address in the local address space. Tunnels now route traffic correctly. Rookie error on my part.
 
Zoolander06
Frequent Visitor
Frequent Visitor
Posts: 86
Joined: Thu Jan 03, 2019 5:26 pm

Re: GRE Tunnels and Dual Wan on one side

Thu Feb 20, 2020 10:57 am

Hello,

I dig up this topic because I have a similar issue.
For load balancing purpose, I need to establish 2 gre tunnels between 2 routers.
On one side I have 1 wan only, with a good bandwith, and on the otherside, I have 2 wan with low bandwith.

Everything seems to go well, as both tunnels are running well, but when I looked closer, I noticed that both tunnels used the default wan for outgoing, so the load is not balanced at all.

Did you solve the problem ? And how ?

Joris
 
OlofL
Member Candidate
Member Candidate
Posts: 113
Joined: Mon Oct 12, 2015 2:37 pm

Re: GRE Tunnels and Dual Wan on one side

Thu Feb 20, 2020 2:50 pm

Hello,

I dig up this topic because I have a similar issue.
For load balancing purpose, I need to establish 2 gre tunnels between 2 routers.
On one side I have 1 wan only, with a good bandwith, and on the otherside, I have 2 wan with low bandwith.

Everything seems to go well, as both tunnels are running well, but when I looked closer, I noticed that both tunnels used the default wan for outgoing, so the load is not balanced at all.

Did you solve the problem ? And how ?

Joris
Can you check that the routes are actually pointing to the remote-gre ip address next-hop?
viewtopic.php?f=2&t=157756&p=775916#p775705
I have an issue where routes are messed up.

Example:
[olof@cpe021] /ip address> /ip route print where dst-address=172.24.1.248/29
Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, 
B - blackhole, U - unreachable, P - prohibit 
 #      DST-ADDRESS        PREF-SRC        GATEWAY            DISTANCE
 0  DC  172.24.1.248/29    172.24.1.250    gre0                    255
[olof@cpe021] /ip address> /ip route check 172.24.1.249                     
     status: ok
  interface: ether1
    nexthop: 172.16.179.1
Here, the route to 172.24.1.249 should have had next-hop as a directly connected route, and not via eth1.

Who is online

Users browsing this forum: CryptoCurrencyDyday, K0NCTANT1N and 83 guests