Hello,

I'm asking someone for a kick in the following problem..

I have CCR1009 as my main router with two WANs - 1 optical (ether2), 2 backup via SIM (ether3). I have SIM in RB912R-2nD. The WAN1 connection works fine, I don't address that.

Connection via SIM (ether3) from CCR does not work for me. The LTE RB itself has no problem connecting to the internet via SIM, but if I try to connect from ether3 on CCR to the internet via RB, I get a timeout. Routes set up, devices ping into each other with no problem, it even translates to IPv4 when I ping the domain name, but still timeout.

I am attaching the configuration files, any questions I will be happy to answer

Thanks

The LtAP (RB912R-2nD) needs a NAT rule. Otherwise the forwarded traffic from CCR won't get NATed and thus dropped by the LTE side since it be a private address. So you'd be able to ping from the LtAP, since it use the lte1 address – but traffic from CCR LANs wouldn't...

A masquerade rule for src-interface=lte1 is what's missing on the LTE/LtAP side.

Also, you don't need LTE settings on the CCR, but that's harmless.

So I set up a NAT rule on the firewall in LtAP for out. interface=lte1 with a masquearade action?

I don't have any LTE settings in CCR, probably some kind of bug.

So I set up a NAT rule on the firewall in LtAP for out. interface=lte1 with a masquearade action?

Yup.

I don't have any LTE settings in CCR, probably some kind of bug.

Your CCR likely has a USB port, so it just exports the default LTE Profile since it's possible to connect a hotspot to the CCR via USB. Whether it should be included in export if unused default, dunno. But it's explainable...

I stopped by the client today and set up the masquerade. On another forum they still advised that the operator discards packets that have a large TTL, so there is an applied mangle to change the TTL. Nothing helped, still timeout. I am attaching the configuration files again.

Nothing jumps out in config**.

Just want to confirm on the LtAP itself, if you do something like ":ping [:resolve www.mikrotik.com]" works, and/or "/tool/fetch url=http://www.google.com output=none" returns "status: finished"? If not... you might want to add the APN for the LTE provider on the LtAP in the LTE Profile settings under /interface/lte. By default, it uses "internet" as APN (or, in some version APN is read from SIM card, which isn't always correct nor always present). And right now, you don't have any APN set on the LtAP...

** You could avoid a double-nat by adding static routing 192.168.150.0/24 -> 192.168.151.1 on the LtAP and remove the masquerade on CCR to ether3 – but that isn't going to fix your immediate problem.

Yes, ping to www.mikrotik.com directly from LtAP is correct. See attachment.

Yes, adding static route is the correct way, I had masquerade to see which way the data flows.

Is it possible that the LAN connector on the LtAP is not designed for sharing LTE connections to the LAN? Only for receiving internet to LtAP?

Not really. Your config on both are pretty straightforward, and doesn't looks wrong to me.

ether1 on RB/LtAPmini is setup to be a router. Now it doesn't have any DHCP enabled, which is correct for your setup – since it has directly-connect route to 192.168.151.1.

But perhaps test the LtAP directly using forwarded packets is from a laptop/desktop – so we can figure out what side is wrong. If you can...plug a computer into ether1 on LtAP, and set computer's IP manually to 192.168.151.99/24 with gateway of 192.168.151.2 and your favorite DNS set... On the laptop/desktop directly connected to LtAP, browser/etc should work to internet. If that indeed works, then it is something in the CCR... If computer's internet via ether1/LtAP does NOT work... then it's something TBD on the LtAP, likely something related to the LTE provider's side.

I connected the NTB directly to ether1 LtAP, manually assigned an IP address from the subnet 192.168.151.0/24 with the gateway 192.168.151.2 DNS 8.8.8.8 and the internet is working. So there must be something wrong in the CCR ...

You have BFD enabled on the CCR. That's pretty new and unclear if you're actively using. Perhaps disable it? But doubtful it has anything to do with your LTE backup problems.

How are you testing the backup route to LTE from the CCR and/or LAN side? Since it seem like this should work based on your configuration...

Yes, but BFD is enabled by default, it has no profile and cannot be turned off completely. At least the system tells me that I don't have the privileges to do so.

Testing is done via tools/ping. First the whole LAN route, i.e. CCR > LtAP and LtAP > CCR. It passes. Then I send a ping to a public address on the Internet through the CCR port to LtAP, the ping goes through to LtAP and no further.

I also believe that it should pass on my current configuration.

You tried passthrough LTE interface on LtAP?

With this you should get ISP address directly on your CCR.

Regards.

I take it you have NOT disabled your main WAN, and tested from a client in your 192.168.150.0/24 subnet? e.g. Perhaps the ping using interface test is give a false-negative & it actually works...

In other words, setting the interface in ping just causes the selected interface's ip to be use (e.g. the "source interface"), not the route it will select... so some 8.8.8.8 ping is going out the main route, but with a 192.168.151.1.

You can avoid taking out your WAN to test this by adding a new routing table for the LTE, and then assign some test computer in 192.168.150.0/24 to use that routing table via a routing rule or firewall mangle.

You tried passthrough LTE interface on LtAP?
With this you should get ISP address directly on your CCR.

Passthrough might be better/different way... But it may be the test method is faulty, see above. And passthrough has its own complexity too .

In the end I solved the problem via LTE passthrough, I studied it and it seemed like a better and more elegant solution. Especially because of the firewall. Unfortunately I didn't figure out why the solution I queried didn't work. Maybe there was a problem with the routes. I'm writing up today because I wanted to make sure it would work. Today I got it to work for the client with failover via LTE LtAP. Thanks to everyone involved for their cooperation and help.