Community discussions

MikroTik App
 
atakacs
Member Candidate
Member Candidate
Topic Author
Posts: 121
Joined: Mon Mar 07, 2016 5:39 pm

A routing conundrum

Sat Sep 26, 2020 2:26 pm

I am having the following setup
Image
A is a windows workstation connected to a linux box (B) via a L2TP VPN tunnel
C is a Mikrotik router connect to the same linux box (B) via a L2TP VPN tunnel
D is a server connected the the LAN side of C
The IP are assigned as indicated

I can, from A, ping C
I can, from C, ping D

I have the following routes on A (added a static route to get to the 192.168.0.0/24 subnet via 10.2.0.3). Yet I can not reach 192.168.0.7 or 192.168.0.2 from A
C:\Windows\system32>route print
===========================================================================
Interface List
 31...........................Syno IM
 12...00 ff 96 f4 15 17 ......TAP-Windows Adapter V9 for OpenVPN Connect
 16...00 15 5d 65 f9 06 ......Microsoft Hyper-V Network Adapter
 17...00 50 56 c0 00 01 ......VMware Virtual Ethernet Adapter for VMnet1
 18...00 50 56 c0 00 08 ......VMware Virtual Ethernet Adapter for VMnet8
  1...........................Software Loopback Interface 1
===========================================================================

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0   172.16.101.254   172.16.101.240   4506
          0.0.0.0          0.0.0.0         On-link          10.2.0.3     26
         10.2.0.3  255.255.255.255         On-link          10.2.0.3    281
       83.166.*.*   255.255.255.255   172.16.101.254   172.16.101.240   4251
        127.0.0.0        255.0.0.0         On-link         127.0.0.1   4556
        127.0.0.1  255.255.255.255         On-link         127.0.0.1   4556
  127.255.255.255  255.255.255.255         On-link         127.0.0.1   4556
     172.16.101.0    255.255.255.0         On-link    172.16.101.240   4506
   172.16.101.240  255.255.255.255         On-link    172.16.101.240   4506
   172.16.101.255  255.255.255.255         On-link    172.16.101.240   4506
      192.168.0.0    255.255.255.0         10.2.0.2         10.2.0.3     26
    192.168.102.0    255.255.255.0         On-link     192.168.102.1   4516
    192.168.102.1  255.255.255.255         On-link     192.168.102.1   4516
  192.168.102.255  255.255.255.255         On-link     192.168.102.1   4516
    192.168.109.0    255.255.255.0         On-link     192.168.109.1   4516
    192.168.109.1  255.255.255.255         On-link     192.168.109.1   4516
  192.168.109.255  255.255.255.255         On-link     192.168.109.1   4516
        224.0.0.0        240.0.0.0         On-link         127.0.0.1   4556
        224.0.0.0        240.0.0.0         On-link     192.168.102.1   4516
        224.0.0.0        240.0.0.0         On-link     192.168.109.1   4516
        224.0.0.0        240.0.0.0         On-link    172.16.101.240   4506
        224.0.0.0        240.0.0.0         On-link          10.2.0.3     26
  255.255.255.255  255.255.255.255         On-link         127.0.0.1   4556
  255.255.255.255  255.255.255.255         On-link     192.168.102.1   4516
  255.255.255.255  255.255.255.255         On-link     192.168.109.1   4516
  255.255.255.255  255.255.255.255         On-link    172.16.101.240   4506
  255.255.255.255  255.255.255.255         On-link          10.2.0.3    281
===========================================================================
Persistent Routes:
  Network Address          Netmask  Gateway Address  Metric
          0.0.0.0          0.0.0.0   172.16.101.254  Default
===========================================================================

Interestingly while I can reach C from A I can not reach A from C - so there is clearly something missing on the Mikrotik, but I can't seem to be able to figure it out...

My routing table on the router
[xxadmin@mikrotik] /ip route> print
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 ADS  0.0.0.0/0                          10.81.91.33               1
 1  DS  0.0.0.0/0                          l2tp-out1                 1
 2 ADC  10.2.0.0/32        10.2.0.2        l2tp-out1                 0
 3 ADC  10.81.91.32/28     10.81.91.39     lte1                      0
 4 ADS  *.*.*.73/32                        10.81.91.33               0
 5 ADC  192.168.0.0/24     192.168.0.2     bridge1                   0
Many thanks in advance for your help !
Last edited by atakacs on Thu Oct 01, 2020 6:50 pm, edited 1 time in total.
 
aesmith
Member
Member
Posts: 313
Joined: Wed Mar 27, 2019 6:43 pm

Re: A routing conundrum

Sat Sep 26, 2020 2:49 pm

If A can ping C then it looks like you have two way routing in place. Check it's not Windows firewall on A blocking inbound.
 
atakacs
Member Candidate
Member Candidate
Topic Author
Posts: 121
Joined: Mon Mar 07, 2016 5:39 pm

Re: A routing conundrum

Sat Sep 26, 2020 2:54 pm

Disabled firewall - not working
 
Sob
Forum Guru
Forum Guru
Posts: 9188
Joined: Mon Apr 20, 2009 9:11 pm

Re: A routing conundrum

Sat Sep 26, 2020 7:04 pm

Few things:

- clients' 10.2.0.x are only point to point /32 addresses, so other 10.2.0.y are not automatically reachable as part of same subnet, they are routed via B
- client A has default route via VPN and it's ok
- client C has it too, but it's not active, everything uses 10.81.91.33 as gateway
- pinging C from A should not really work, unless there's srcnat/masquerade on B applied to ping requests

So:

- client C needs active route to other 10.2.0.y, either a new one only for this, or default one via tunnel (#1) must win over current one (#0)
- VPN server B needs route to 192.168.0.0/24
- client A doesn't need route to 192.168.0.0/24 via 10.2.0.2, it's already covered by default route via tunnel
 
atakacs
Member Candidate
Member Candidate
Topic Author
Posts: 121
Joined: Mon Mar 07, 2016 5:39 pm

Re: A routing conundrum

Sat Sep 26, 2020 8:54 pm

Thanks for your detailed answer - let me try to understand (as there is an obvious educational opportunity here :) )

- clients' 10.2.0.x are only point to point /32 addresses, so other 10.2.0.y are not automatically reachable as part of same subnet, they are routed via B
Ok - understood

- client A has default route via VPN and it's ok
Hmm did was not by design but ok :) - Assuming I don't set it to default I then have to add a static route ?

- client C has it too, but it's not active, everything uses 10.81.91.33 as gateway
Aha ! Good catch

- pinging C from A should not really work, unless there's srcnat/masquerade on B applied to ping requests
Yet it does...

So:
- client C needs active route to other 10.2.0.y, either a new one only for this, or default one via tunnel (#1) must win over current one (#0)
Ok but not exactly sure how to do it (here I guess) ?
Image
- VPN server B needs route to 192.168.0.0/24
Via 10.2.0.3 presumably ?

I have added it
admin@vpnbox:/$ ip route list
default via 83.166.*.* dev eth0  src 83.166.*.* 
10.0.0.1 dev ppp201  proto kernel  scope link  src 10.0.0.0 
10.2.0.2 dev ppp302  proto kernel  scope link  src 10.2.0.0 
10.2.0.3 dev ppp301  proto kernel  scope link  src 10.2.0.0 
83.166.*.*/24 dev eth0  proto kernel  scope link  src 83.166.131.73 
192.168.0.0/24 via 10.2.0.3 dev ppp301 
- client A doesn't need route to 192.168.0.0/24 via 10.2.0.2, it's already covered by default route via tunnel
Ok (unless VPN is not set as default route)
 
Sob
Forum Guru
Forum Guru
Posts: 9188
Joined: Mon Apr 20, 2009 9:11 pm

Re: A routing conundrum

Sat Sep 26, 2020 9:36 pm

Decide if you want to:

a) route everything from client to vpn server (use it as default gateway)
- for RouterOS change primary default route's distance to 2, then when vpn adds new one with distance 1, it will be active instead
- you already have that on Windows

b) use vpn to only access selected remote subnet(s)
- for RouterOS add route(s) (/ip route add dst-address=<subnet> gateway=<vpn interface>)
- on Windows it's a little more complicated, you have to disable two options to use vpn as gateway and to add "class-based" route (find list of network adapters, select this vpn client, open properties and it's hidden deep in its IPv4 config), and then you need powershell command Add-VpnConnectionRoute to add route(s) to subnet(s) you want to use; Microsoft clearly forgot how to make things user friendly
 
atakacs
Member Candidate
Member Candidate
Topic Author
Posts: 121
Joined: Mon Mar 07, 2016 5:39 pm

Re: A routing conundrum

Sun Sep 27, 2020 11:55 am

I'll probably go with a) as it seems to be the easiest way to get things working (in any case this is only a short term project).

Next question is how do I achieve it ? Those automatic routes don't seem to be "editable", at least not from Winbox...
 
atakacs
Member Candidate
Member Candidate
Topic Author
Posts: 121
Joined: Mon Mar 07, 2016 5:39 pm

Re: A routing conundrum

Tue Sep 29, 2020 11:36 am

Next question is how do I achieve it ? Those automatic routes don't seem to be "editable", at least not from Winbox...
Anyone ... ?
 
User avatar
CZFan
Forum Guru
Forum Guru
Posts: 2098
Joined: Sun Oct 09, 2016 8:25 pm
Location: South Africa, Krugersdorp (Home town of Brad Binder)
Contact:

Re: A routing conundrum

Tue Sep 29, 2020 12:09 pm

...
Next question is how do I achieve it ? Those automatic routes don't seem to be "editable", at least not from Winbox...
Some things you should try to do yourself atleast, below is where you can change the default route distance on a DHCP client
distance.JPG
You do not have the required permissions to view the files attached to this post.
 
atakacs
Member Candidate
Member Candidate
Topic Author
Posts: 121
Joined: Mon Mar 07, 2016 5:39 pm

Re: A routing conundrum

Wed Sep 30, 2020 12:36 am

Some things you should try to do yourself atleast, below is where you can change the default route distance on a DHCP client
More than happy to do so and to learn but quite frankly had no idea how to change the default route distance on a DHCP client... Thanks for your help there !
 
User avatar
CZFan
Forum Guru
Forum Guru
Posts: 2098
Joined: Sun Oct 09, 2016 8:25 pm
Location: South Africa, Krugersdorp (Home town of Brad Binder)
Contact:

Re: A routing conundrum

Wed Sep 30, 2020 3:10 pm

Some things you should try to do yourself atleast, below is where you can change the default route distance on a DHCP client
More than happy to do so and to learn but quite frankly had no idea how to change the default route distance on a DHCP client... Thanks for your help there !
Pleasure, glad you got sorted, see below for future:
dhcpclient.JPG
You do not have the required permissions to view the files attached to this post.

Who is online

Users browsing this forum: Semrush [Bot], sindy and 35 guests