my topology is simple.

lan range 192.168.88.0/24 for the phones - on VRF.
WAN link via L2tp.

problem is :
im not able to get access to the phones (by using web-proxy) as they are on VRF.

on v6 i was solving this by using /ip route rule - doest work that on v7.15.2

config:

good catch.That was due to the editing as i'm using long name for the interfaces

doesn't really matter ,my goal is to get access to the phones.

@sindy - jer imas neka ideja brate?

im able to ping the phones from the main table

on v6 that works perfectly fine , by using /ip route rule from above ^

just switched over to v6, works perfectly fine when i ad the rules in ip route.

Raised the support ticket

@sindy - jer imas neka ideja brate?

I do, but you will have to test it - the behavior of RouterOS 6 regarding VRF was quite relaxed in terms that local processes could use addresses in any VRF, so your approach of using a routing rule to tell the router to use a "wrong" routing table to access the phone subnet worked. With ROS 7, the behavior is much more strict, each local process is bound to exactly one VRF and cannot "escape". But what you can do is to follow the Traffic leaking between VRFs section just a few lines above the Supported features one, installing a route to 192.168.88.0/24 via the bridge interface into the routing table for vrf1. The http proxy is not listed in the table of services but I figure it just means that it cannot be bound to any other VRF than main.

Depending on the constraints of your overall environment, the other way round might be to make the phones use the L2TP "uplink" using routing marks without using VRF.

@sindy


completely agree in v7 VRF is more strict. Be honest i'm running out of ideas, if u have anything particular please advice.

I have raised a ticket with them, probably they have some solutions, at the end of the day that option should available.

in v7 between 2 VRFs i found that is very simple to ping, unlike from the main to vrf

Samo zato se boime da prefrlim se na v7. Hvala puno, ti si iz Hrvacke?

if u have anything particular please advice.

I did suggest an idea in my previous post, instead of using a routing rule, to add a route dst-address=192.168.88.0/24 routing-table=main gateway=bridge, have you tried it?

ti si iz Hrvacke?

Nisam, ali imam neke veze

it has to be like:

dst-address=192.168.88.0/24 routing-table=main gateway=bridge@vrf

otherwise is getting unreachable, but ye even if i add that still i cant get access

If so, sniffing on the bridge should be the next step, to see whether the http proxy does attempt to set up a connection to the web interface of the phone, whether the phone responds etc.

this is all i can get.

fyi: i can see request on web-proxy , is something is hitting there

this is if the br is in the MAIN table

OK... if you put the bridge back to vrf1 and ping 192.168.88.100 from the router itself not specifying any table (hence using main), can you see the pings in the sniff? I'm trying to understand whether the http proxy uses the routing in some specific way or the whole idea of inter-vrf leaking does not work (in that ROS version?).

What should always work would be to use a loopback tunnel between main and vrf:

• add another local address like 127.0.0.2/32 to interface lo (or to an empty bridge like we used to do before lo became visible)
• create two /interface/ipip:
  add name=ipip-to-vrf1 local-address=127.0.0.1 remote-address=127.0.0.2
  add name=ipip-to-main local-address=127.0.0.2 remote-address=127.0.0.1
• attach an address that is non-conflicting in both main and vrf1 address spaces, like 10.20.30.40/32, to ipip-to-vrf to be used as a source one for outgoing traffic from the http proxy towards the phone subnet.
• add ipip-to-main to the list of vrf1 interfaces.
• add a route to 10.20.30.40 with gateway=ipip-to-main to routing table vrf1.
• add a route to 192.168.88.0/24 with gateway=ipip-to-vrf1 to routing table main

If it does not work, sniff on both ipip interfaces and the bridge one to see what next.

1- Yes, i can ping from the main table.
if i add:
dst-address=192.168.88.0/24 gateway=bridge1@vrf1 routing-table=main ,===> i can ping the phone, but no access to the phone
dst-address=192.168.88.0/24 gateway=vrf1@vrf1 routing-table=main ,======>i can ping the router itslef


2. Your second magic works - but i need to add static route from the PPPoE server to make Web-Proxy works , as im able to ping the public ip-add and mngm -VPN from my PC.

We got something better then nothing

I will let u know once i hear back from the support

because the phone working if they are in VRF as they have link to the 3cx-Cloud, and if i bring it on to the MAIN table they are losing provisioning

Then it sounds like you have some other malfunctioning going on in your config.

??? To me it seems legit - the phones need their own network environment to work properly, so why not put them into a VRF and let them have what they need there, without risking interference with the rest of the configuration. And then you need a way to manage them without having to put the management device to the same VRF, which is when the controlled leak comes into play.

Until it came out that it was 3CX, I was expecting it to be some extension of telecom's xDSL, where it is quite common that the address space in the telephony VLAN is unrelated to, and potentially overlapping with, the address space in the internet VLAN and in the customer's home network.

Of course you could use mangle rules to assign the routing marks rather than VRF, but since it was working in ROS 6, I can understand well why @nichky has taken the easier path (easier back then, that is).

That's why I've mentioned a controlled leak

I actually find the initial idea to use a HTTP proxy as a portal to the phone subnet for hosts in the defaut VRF quite clever, as the same subnet stays in the normal routing space for those hosts for direct access. It's just that with the more correct implementation of VRF in ROS7 it has lost its purpose, as you have to leak the subnet for everyone, not just for the Mikrotik itself. So my workaround with a tunnel should be completed with mangle or routing rules to regain that advantage (phones being only accessible from the default VRF via the HTTP proxy rather than directly).

@sindy,

i things we should stop there.

from the support:

v6 does not have purely VRFs and they are never really isolated. v7 has completely different implementation which is not a simple extension of policy routing. So most of the hacks of v6 is not going to work.

If you want to access resources between vrfs then you need to set route leaking, a lot of detailed examples are provided here:
https://help.mikrotik.com/docs/pages/vi ... )-Examples

If you want to access local address in the main table from other vrfs then that currently is not possible directly.


fyi: pitao sam dali ima neki planovi da se to realizira u buduchnost.

@mrz

i was more wory about accessing from the main to vrf, but Maris already explained.

@sindy

also one more thing i've noticed.

If the public ip-add (server) is in the VRF, the clients wouldn't be able to establish VPN.

On v6 that is working perfectly fine, with one simple rule.

Probably that will be fixed in the next versions

bash volim tvoja slika na profil

@mrz

i've noticed something.

Let say my lan is in vrf1 and i want to get access to another lan (ping works fine) in vrf2.
I can login by using telnet/ssh, however im not able to log in by using Web-Proxy.

Are you aware of that?