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ğ
Not yet.
Le 08/04/2019 à 11:17, Gökdağ
Göktepe a écrit :
Hi Brent did you find any solution?
Gökdağ