Hi Folks,

I have a LHGG deployed, with its LTE-Link on passthrough to a RB4011.
The LHGG itself gets managed via VLAN-ID 02 over the same llink.

What I want, is to have the LHGG to *only* use its "own" LTE WAN, when accessing the internet. This *includes* the use/update of its DDNS address/name (mikrotik cloud).

I have only partially succeeded, by forcing traffic from VL02 from the LHGG via a dedicated Routing Table, where I copied the Default Route, when the DHCP-Client on the RB4011 binds to an IP from the (passed through) LTE interface.

see:


The "real" problem:
When LHGG starts up, link to VLAN02 gets fired up first - before LTE can bind to a WAN IP - and hence the LHGG uses the default route available at that time, which is via WAN from the cable modem of the RB4011.

The "DDNS update Interval" although set, does not seem to work (assuming my given setup is to update DDNS automagically once, every hour).
If I manually force an update or disable/re-enable DDNS the update occurs. However, when the LTE-WAN-IP changes (on the RB4011), this goes unnoticed for the LHGG.

Any Ideas on how to keep that in sync?

There are two ways, one of them depends on what the mobile ISP tolerates, the other one is more complex to set up.

If your ISP tolerates that, you can attach two APN profiles to the same LTE interface, and you will get a separate address for each of them. So one of them can be a "normal" one used locally by the LHGG, whilst the second can be the passthrough one used by the 4011. In that case, you can let the DHCP client on the LHGG ignore the default route received from the 4011.

The other way requires policy routing at the 4011, telling the 4011 to always route any traffic coming from the LHGG's LAN IP in VLAN 2 via the WAN getting its address from the LHGG's LTE interface, regardless the availability of the primary WAN.

If the LHGG gets a public address from the ISP, you have to use the latter method (hairpin via 4011) because you won't get two public addresses, one for each APN; if it gets a private/CGNAT range one, there's little point in using the public one behind which it is NATed to update the DDNS, as eventual incoming connections to that "outer" public address won't reach the LHGG anyway.

Many thanks for your response.

If your ISP tolerates that, you can attach two APN profiles to the same LTE interface, and you will get a separate address for each of them. So one of them can be a "normal" one used locally by the LHGG, whilst the second can be the passthrough one used by the 4011. In that case, you can let the DHCP client on the LHGG ignore the default route received from the 4011.

Not sure if my telco provider would allow that, but I don*t see how I could try and configure that in the LHGG.

The other way requires policy routing at the 4011, telling the 4011 to always route any traffic coming from the LHGG's LAN IP in VLAN 2 via the WAN getting its address from the LHGG's LTE interface, regardless the availability of the primary WAN.

Hmmm, thought that I'd already do that.
I have a fixed mangle rule in pre-routing chain, that would force any traffic from in-IF VLAN02 that is towards a destination outside (not my local (V)LANs to mark for the WAN2 table.
That works fine, once the LTE IP is bound.
What is the behaviour of the RB4011 if there is no match in the WAN2 table (or table is empty)...will it fall back into main table? If so, I'd need to actively block anything in table main.

If the LHGG gets a public address from the ISP, you have to use the latter method (hairpin via 4011) because you won't get two public addresses, one for each APN; if it gets a private/CGNAT range one, there's little point in using the public one behind which it is NATed to update the DDNS, as eventual incoming connections to that "outer" public address won't reach the LHGG anyway.

As said and depicted, the telco provider will provide a (one) public IPv4, but in passthrough this is allocated to the RB4011.

I have a fixed mangle rule in pre-routing chain, that would force any traffic from in-IF VLAN02 that is towards a destination outside (not my local (V)LANs to mark for the WAN2 table.
That works fine, once the LTE IP is bound.
What is the behaviour of the RB4011 if there is no match in the WAN2 table (or table is empty)...will it fall back into main table? If so, I'd need to actively block anything in table main.

If no route whatsoever (not even the default one) is available in the routing table requested by means of a routing-mark, RouterOS normally uses routing table main to route the packet. To prevent that, you have to explicitly state the following:

/ip route rule
add routing-mark=some-mark action=lookup-only-in-table table=some-mark

Or another possibility is to add a default route with type=blackhole and distance higher than the one of the regular default route to table some-mark. Or, instead of type=blackhole, you can use a normal route whose gateway is set to some bridge interface with no ports. In any case, such a route kicks in when the normal one is not available, and makes sure that the traffic won't fail over to main.

As said and depicted, the telco provider will provide a (one) public IPv4, but in passthrough this is allocated to the RB4011.

Understood, I haven't studied the picture deeply enough. So yes, in such case, if you want to keep the passthrough mode, the above is the only way.

If no route whatsoever (not even the default one) is available in the routing table requested by means of a routing-mark, RouterOS normally uses routing table main to route the packet.
To prevent that, you have to explicitly state the following:
[...]
Or another possibility is to add a default route with type=blackhole and distance higher than the one of the regular default route to table some-mark.

...perfect, that'll do. Thanks again for your information and help!