Community discussions

MikroTik App
 
awonglk
newbie
Topic Author
Posts: 33
Joined: Sat Oct 31, 2015 3:43 pm

Routing via GRE to VLAN networks

Mon Aug 30, 2021 12:16 pm

Hopefully this is something really basic that I am missing.. wondering if anyone of you gurus could advise?

Basically i have 2 x routers with a GRE tunnel in between.
Router A has a very basic setup handling addresses in 192.168.62.X range
Router B has quite a few VLANs in place as per routing tables below..

Router A:
RouterA.JPG
Router B:
RouterB.JPG
I have all the firewall rules setup and, and would like devices on both routers to be able to reach each other. My problem is this:
- Any device from Router B can ping and reach devices on Router A (192.168.62.1)
- Router A, however, cannot ping any devices on the various VLANs (especially VLAN20 on 192.168.12.0/24 network).

I am wondering if this is a matter of VLANs does not work over GRE.. or do I need to setup something else to ensure devices from Router A can reach any of the devices on any VLANs on router B
You do not have the required permissions to view the files attached to this post.
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Routing via GRE to VLAN networks

Mon Aug 30, 2021 12:56 pm

Although it is the best practice to locate each IP subnet to a dedicated VLAN, VLAN and IP subnet are not the same thing. So ignore VLANs for a while and concentrate on the subnets alone. In order that devices in subnet a.a.a.a on router A could talk to devices in subnet b.b.b.b on router B, a route to subnet b.b.b.b via the GRE tunnel must exist at router A, and route to subnet a.a.a.a via the GRE tunnel must exist at router B. Plus the firewall must not block the traffic of course.

And yes, GRE tunnel doesn't carry L2 frames, only L3 packets, so no way to tunnel VLANs as such via GRE. But you don't need that either, as said above.
 
awonglk
newbie
Topic Author
Posts: 33
Joined: Sat Oct 31, 2015 3:43 pm

Re: Routing via GRE to VLAN networks

Tue Aug 31, 2021 4:29 am

Thanks for your reply. Based on the routes I've already established, it should work right? Route table says gateway are reachable on both routers.
But ping times out from router A to B (but not vice versa)..

Pinging 192.168.12.1 from router A (timed out)
A_To_B.JPG
Pinging 192.168.62.1 from router B (Works as expected)
B_To_A.JPG
I can't see any firewall activities either, so don't believe firewall is blocking it. Just not sure where to go from here. Any pointers where/what could be causing the time out?
You do not have the required permissions to view the files attached to this post.
 
User avatar
jprietove
Trainer
Trainer
Posts: 212
Joined: Fri Jun 03, 2016 3:00 pm
Location: Cádiz, Spain
Contact:

Re: Routing via GRE to VLAN networks  [SOLVED]

Tue Aug 31, 2021 9:58 am

Instead of using gre interfaces as gateways, try to add an IP address on each gre interface and use it as your gateway.
# Router A
ip address add interface=gre-tunnel-sg address=192.168.162.1/30
ip route add dst-address=192.168.62.0/24 gateway=192.168.162.2

# Router B
ip address add interface=gre-tunnel-us address=192.168.162.2/30
ip route add dst-address=192.168.12.0/24 gateway=192.168.162.1
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Routing via GRE to VLAN networks

Tue Aug 31, 2021 10:56 am

ping times out from router A to B (but not vice versa)..
...
I can't see any firewall activities either, so don't believe firewall is blocking it.
Sorry, the first thing I've spotted in your OP was that whilst there were four subnets, 192.168.11.0/24 to 192.168.14.0/24, at router B, there was only a route to 192.168.12.0/24 on Router A, whilst you wrote that "Router A, however, cannot ping any devices on the various VLANs". So I wasn't careful enough when reading the other details, assuming that you were testing on addresses for which no routes existed.

Now as you've stated again that the pinging works in one direction but doesn't in the opposite one, and have shown the particular IPs you are pinging between to match the existing routes, as well as the fact that you've explicitly indicated to the originator the source address to use, it means that the route to 192.168.62.0/24 at router B and the route to 192.168.12.0 at Router A are both correct, otherwise the responses in the successful ping case would not come back to the originator of the ping.

So the issue must be caused by a firewall, but not necessarily (or rather not only) on the Mikrotik routers themselves.

When pinging from an own address of the router, firewall chain output on that router handles the outgoing requests and firewall chain input handles the incoming responses; when you ping to an own address of a router, input on that router handles the incoming request and output handles the outgoing responses. When you ping to or from from some other device connected to a router, that router's firewall chain forward handles both the requests and responses, and the firewall on the device itself may also block the traffic (typically, Windows firewall by default only responds to ping requests from the own subnet of the interface to which they arrive).

All the above is valid for the ping requests and responses, i.e. the payload of the tunnel.

The transport packets of the tunnel that carry the payload, i.e. the GRE ones, are always handled by chains input and output (because they are always sent and received by the routers themselves), but also by chain forward (or in some equivalent way) of all the routers on the path between your two Mikrotiks (if they bother about filtering traffic at all). So if there are short pinhole lifetimes somewhere, the transport packets may not reach the destination in one direction, unless the pinhole has been previously open by a corresponding packet in the opposite direction.

Also a src-nat rule on Router B, or a dst-nat one on Router A, rule may cause a trouble in pinging from .12.1 to .62.1 if not selective enough - these rules always handle only the first packet of a new connection, and the resuls is then applied on all the subsequent packets of that connection. So such a rule only affects one direction of ping.

Sniffing is of great help here - you can see, while pinging, how far the request and, eventually, the response did get on each router, and whether there was some NAT manipulation on either.

/tool sniffer quick ip-address=192.168.12.1 ip-protocol=icmp at Router A, and /tool sniffer quick ip-address=192.168.62.1 ip-protocol=icmp at Router B will show you what happens with the icmp packets; /tool sniffer quick ip-address=ip.of.router.B ip-protocol=gre at Router A, and /tool sniffer quick ip-address=ip.of.router.A ip-protocol=gre at Router B will show you what happens with the transport packets.
 
awonglk
newbie
Topic Author
Posts: 33
Joined: Sat Oct 31, 2015 3:43 pm

Re: Routing via GRE to VLAN networks

Tue Aug 31, 2021 11:16 am

Instead of using gre interfaces as gateways, try to add an IP address on each gre interface and use it as your gateway.

Thanks jprietove! That did the trick! Just adding an address to the GRE tunnel on each side solved it! In fact I didn't even need to add the static route at all.

So the following did the trick:
# Router A
ip address add interface=gre-tunnel-sg address=192.168.162.1/30

# Router B
ip address add interface=gre-tunnel-us address=192.168.162.2/30

But clearly, ping works in one direction without IP addresses added before. I wonder what's the technical reason for it.
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Routing via GRE to VLAN networks

Tue Aug 31, 2021 11:25 am

That did the trick! Just adding an address to the GRE tunnel on each side solved it!
That sounds like some NAT issue. Do the sniffing as suggested above and see where the IP address assigned to the GRE interface is used instead of the one specified in the src-address parameter of the ping command.

Since GRE is a point-to-point tunnel, the name of the interface is normally sufficient as a route's gateway.
 
awonglk
newbie
Topic Author
Posts: 33
Joined: Sat Oct 31, 2015 3:43 pm

Re: Routing via GRE to VLAN networks

Tue Aug 31, 2021 12:08 pm

Sindy.. thanks for the sniffer command.. awesome tool that I didn't know existed.

When I did the sniff on Router A..
It appears when IP address is assigned on the GRE interface.. the correct SRC-ADDRESS is used as per what I specified in the ping command
CorrectSRCAddress.JPG
When I do not have the IP address assigned on the GRE interface.. the SRC-ADDRESS is actually my public Internet IP .. even though I have specified the src-address in the ping command. I believe RouterOS defaults to using ether1 when a bridge is not used?? ether1 is my "WAN" connection to Internet.. while ether2 has the 192.168.62.1 address assigned.

InCorrectSRCAddr.JPG
You do not have the required permissions to view the files attached to this post.
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Routing via GRE to VLAN networks

Tue Aug 31, 2021 12:30 pm

I would be careful with "defaulting to use ether1's address". For packets sent by the router itself, the route to the destination is found first, and only then the source address is chosen, using the properties of that route. If no pref-src parameter of the route is specified, RouterOS chooses the address associated to the interface which is set as the gateway of the route or, if gateway is an IP address, the address of the interface via which the gateway IP is accessible. A src-address eventually specified manually overrides both if it is an own address of the router, attached to any interface. And a src-nat (or masquerade, which is a src-nat with additional features) rule overrides all three. Why this hierarchy has failed in your case is not clear to me, nor it is clear to me why the public IP in particular has been chosen to overridde the one specified as src-address.

Can you add a rule chain=srcnat action=accept dst-address=192.168.12.1 as the first one in its chain in /ip firewall nat (to shadow any subsequent ones for packets towards 192.168.12.1) and see what the source address of the ping packets will be when no IP address will be assigned to the GRE interface?
 
awonglk
newbie
Topic Author
Posts: 33
Joined: Sat Oct 31, 2015 3:43 pm

Re: Routing via GRE to VLAN networks

Tue Aug 31, 2021 4:12 pm

Without IP address on GRE tunnel.. and with the srcnat added as you say..

masq_192.168.12.1.JPG
Still times out with SRC-address of my public Internet IP when pinging 192.168.12.1
You do not have the required permissions to view the files attached to this post.
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Routing via GRE to VLAN networks

Tue Aug 31, 2021 4:21 pm

Interesting... what if you set the pref-src of the route via the GRE interface to 192.168.62.1, of course still with no IP address attached o the GRE interface? What are the RouterOS releases on both machines, given that they behave differently under apparently same conditions?
 
awonglk
newbie
Topic Author
Posts: 33
Joined: Sat Oct 31, 2015 3:43 pm

Re: Routing via GRE to VLAN networks

Tue Aug 31, 2021 4:50 pm

Makes no difference.. With no IP address attached to the GRE interface.. Router A still times out, with SRC-ADDRESS showing the Internet public ip picked up by ether1.

Router A is a CHR running on x86_64
Router B is a ARM based RB450GX4

I guess it's a behavior of x86 implementation.. maybe?
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: Routing via GRE to VLAN networks

Tue Aug 31, 2021 5:04 pm

I guess it's a behavior of x86 implementation.. maybe?
Possibly... I was actually asking about the release (like e.g. 6.47.10), not so much about CPU architecture, but yes, it's true that a few things behave different depending on the CPU architecture, I just didn't expect something this essential to behave different.

Knowing that it is a CHR allows me to test on one of mine.
 
awonglk
newbie
Topic Author
Posts: 33
Joined: Sat Oct 31, 2015 3:43 pm

Re: Routing via GRE to VLAN networks

Wed Sep 01, 2021 1:52 am

Using 6.48.3 on both architectures

Who is online

Users browsing this forum: BinaryTB, Bing [Bot], Google [Bot] and 72 guests