[Lilux-info] Cisco Meraki

Mon Apr 8 16:46:29 CEST 2019

Let's say the firewall outside interface is 192.168.1.254/24. The 
general Internet access (vDSL modem) is 192.168.1.1/24, connected to the 
firewall by Ethernet. It NATs all outgoing IP traffic to the Internet by 
replacing the source IP address by its own public IP address 
(masquerading) to make it routable on the World Wild Internet.

A new secondary Internet access is added. It is implemented by a Meraki, 
operated by POST. I have NO ACCESS to its configuration, not even the 
pppoe credentials, so no ways to circumvent it.

The Meraki LAN interface is, let's say, 192.168.1.100/24. It has a fixed 
public IPv4 WAN address. All incoming traffic (limited to IPv4, with a 
limited MTU and only ICMP, UDP or TCP because of POST limitations) is 
forwarded to the firewall outside IP address, 192.168.1.254/24, by POST 
configuration.

This way, the general traffic works as usually and previously: through 
the general Internet access, the default gateway, the vDSL modem. There 
is so in the firewall a "default route" with 192.168.1.1 as default gateway.
Some selected traffic can be routed to the POST Internet access, 
depending on its destination IP address or because of flagged traffic 
(iproute with marks and multiples routing tables to select the 
appropriate gateway).
As example, all the traffic to youporn (216.18.168.116) could be routed 
through the POST Internet access by adding a static route on the firewall:

# route add -host 216.18.168.116 gw 192.168.1.100

This traffic takes so the POST Internet access to reach its destination, 
and is NATed by the Meraki (source IP address NAT), so the return 
traffic reaches back the POST Internet access, and is reverse-NATed back 
to the firewall...

The problem is to try to _use the POST Internet access for INCOMING 
traffic_.

If a connection attempt comes from the Internet (let's say 1.1.1.1) 
through this POST Internet access, the IP packet is forwarded to the 
firewall ("exposed host") by the Meraki, because of POST configuration, 
and it is what is expected. But as this packet has still 1.1.1.1 as 
source IP address, the answer to this request is routed back to the 
Internet by the general Internet access, so will be NATed (masqueraded) 
from a different public IP address.
The host 1.1.1.1 will then receive answer to it's connection attempt 
from a completely different IP address, and so will not link it to the 
request, so it won't work.

The solution would be to masquerade the source IP address of the 
incoming traffic crossing the Meraki, so that the firewall would see it 
as coming from the Meraki internal IP address, in this example 
192.168.1.100/24.
The firewall will then answer the request apparently coming from 
192.168.1.100, and the Meraki should reverse-NAT it back to it's actual 
destination, in this example 1.1.1.1. The connection will establish.

For sure, I know that in this case, the firewall will not be able to 
filter incoming traffic based on it's source IP address, but it's just 
about making it possible, not (yet) clever or appropriate.

So I ask POST technical service to set-up this internal NAT, and they 
answer that it's NOT SUPPORTED by the Meraki. I can't believe Cisco has 
became so bad that they are not able to do this simple masquerading, 
especially as I suspect they use Linux as underlying technology...

So I looked at Meraki documentation, but I didn't found anything else 
than a very basic web-based configuration interface manual. That's why I 
ask if:

  * Somebody knows Meraki
  * Is Meraki based on Linux kernel ?
  * Is there a way to access the Meraki CLI ?
  * Is there a way to configure this very basic traffic masquerading rule ?

So that I could find a solution (at least limited so far) and learn POST 
help-desk again something they didn't know...

Note: changing the default route IS NOT an acceptable solution, as 
changing the default Internet access would have lots of other 
consequences, due to historical reasons.
The incoming traffic through the POST Internet access comes potentially 
from /any/ public IPv4 routable address. It should be answered by the 
two Internet accesses.

Actually, the real situation is more complex: the firewall is exposed to 
incoming traffic from already three Internet accesses, provided by 
various ISPs and technologies. And it works, as I have control over 
those Internet accesses.
The problem occurs just because of this fourth "Internet access" by 
POST, which is out of my control and apparently unable to provide this 
basic feature: masquerading the incoming traffic.

By the way, I'm not even sure this "Internet access service" can be 
qualified of "Internet access" as anybody knows (or should know) that 
what is common on the Internet is... the IP protocol. However, this 
"Internet access" service is strictly limited to IPv4, and to only the 
TCP, UDP and ICMP protocols. This is so a very limited Internet access, 
somehow as you might have received from some hotels in old times: a 
"Internet access" that was limited to web browsing, and blocked any 
"unknown" service, such as SSH, telnet, IMAP, and so on. This also 
happened in the very old days (about 15 years ago) when some ISPs 
blocked SIP traffic or added intentionally jitter to the VoIP audio 
streams...

Those limitations have been ruled as illegal already, but here in 
Luxembourg, there is a delinquent company called POST that still apply 
such restrictions, apparently...

Practically, those restrictions prevents customers to access to:

  * IPSec VPNs, as some implementations requires ESP and AH protocols
    (not TCP or UDP)
  * GRE
  * IPinIP
  * PIM, IGMP (for multicast)
  * various routing protocols
  * IPv6
  * RDP
  * and so on...

which are _part of the Internet protocols_, even if unknown by POST 
commercial management, apparently.

I notice that some other ISPs (LOL, MixVoIP, ...) do provide genuine 
Internet accesses, with full 1500 MTU and all the services above IP, as 
expected...

Any help would be appreciated.

Le 08/04/2019 à 12:17, Gökdağ Göktepe a écrit :
> I am trying to figure out your problem but French is a bit complicated 
> for me. As an instance I think it has sth to do with administrative 
> distance . But I don’t know if you have static routes defined for your 
> secondary internet access and how
>
> Gökdağ
>
> On 8 Apr 2019, at 11:56, Brent Frère <Brent.Frere at abilit.eu 
> <mailto:Brent.Frere at abilit.eu>> wrote:
>
>> Not yet.
>>
>> Le 08/04/2019 à 11:17, Gökdağ Göktepe a écrit :
>>> Hi Brent did you find any solution?
>>>
>>> Gökdağ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lilux.lu/pipermail/lilux-info/attachments/20190408/5cadf7c6/attachment.html>