Another thread that evolved into using EoIP+IPSec with RoMON to enable out-of-band management across a secure WAN.

@anav asked

Id be interested in your only one side needs public IP teaser. Please elaborate!!!

and I tried but got:

Y:ou have to be more clear than that sir,
I have no idea what you mean by this .....
But still need use the CGNAT'ed remote address on the "static IP" side

Take as many sentences as you need so the layperson (me) understands what you mean.

So this post in response to his prompting. Essentially trying to answer the question:

How to use EoIP+IPSec when one side is behind something like a CGNAT?

To be clear ONE side likely needs a fixed/static IP. And this approach obviously only work between two Mikrotik since EoIP is not a standard. Also, let's assume firewall is close to the default on most home routers. I tested this on an RB1100AHx4 with normal public IP to a wAPacR with an AT&T LTE connection, so it worked in one case at least. To provide an example, let assume two generic routers:
"HUB" with a unrestricted public IP of 203.0.113.1
"REMOTE" with a LTE connection that's providing a private/CGNAT address of 10.1.2.3

EoIP+IPSec Setup:
Let's assuming using winbox/webfig. The following steps should be done on EACH router ("HUB" and "REMOTE" but the steps are same regardless if WAN type):

1. Check "DDNS Enabled" in IP > Cloud dialog. We'll use the DNS name later. So do on both routers now.

2. Create (+) new EoIP interface in Interface > EoIP tab. In EoIP settings that appear, set the following (and leave others like "MTU" or "Local Address" blank/defaults):
a. Set name as desired (e.g. "eoip-romon").
b. For "Remote Address", use the IP Cloud DDNS name from the OTHER router (e.g. on HUB router, use REMOTE's DDNS name & vise versa)
c. Set "Tunnel ID" to match both routers (say "5" since RoMON has five letters – but both side just need to match)
d. Importantly, set "IPSec Secret" to something complex/long, again both side need to match exactly.
e. Uncheck "Allow Fast Path"
f. Hit OK

3. Go to IP > Firewall > Address Lists
a. Hit (+) to add new address list
b. Set "Address" to the OTHER route's DDNS name (e.g. same as used as Remote Address in EoIP setting)
c. Choice a name (say "allowed-eoip-remotes") and set that as the "List"
d. Hit OK

4. Go to IP > Firewall > Filter
a. Hit (+) to add new rule, and on first tab set
b. Set "Chain" to "input"
c. Set "Src. Address List" to be same as step 3.c above (e.g. "allowed-eoip-remotes")
d. Set "Protocol" to GRE
e. Check on Action tab to make sure it's "accept".
e. Hit OK

5. Go to IP > Addresses, to add an IP address for EoIP interface
a. Hit (+) to add new IP address
b. For "Address", use a unique subnet (say 172.19.5.1/24 for HUB and 172.19.5.2/24 for REMOTE – both side just need to be part SAME subnet, which one you use does not matter)
c. For "Interface", use the name of the EoIP interface created in STEP 2
d. Hit OK
(NOTE: An IP address is technically OPTIONAL if EoIP only used for RoMON)

6. Go to Interface > Address List to add EoIP to LAN to allow winbox through firewall
a. Hit (+) to add new list mapping
b. In dialog, set "Interface" to the EoIP interface name ("eoip-romon")
c. Select "LAN" as the "List"
d. Hit OK
(NOTE: This is also technically OPTIONAL if EoIP only used for RoMON)

7. Enable EoIP interface (if not already) and STEPS 1-5 have been done on BOTH routers......check if "running" marked with "R" next to EoIP in Interfaces > EoIP list. And if about to ping the OTHER router's IP set in STEP 5.

8. Enable RoMON in Tools > RoMON. You can set a "Secret" if you'd like, it just have to match on both sides. Also in "Ports", you set the default "all" to "Forbid" and add new port with just the EoIP interface to allow if you want. Although some of the benefits of RoMON is it can do path discovery BEYOND just the EoIP interface.

8. In new winbox login window, using the HUB router IP/user/passwd, then click "Connect to RoMON", you should see the remote router (via winbox protocol to first router, then internally RoMON protocol is used over the EoIP+IPSec tunnel to far end).


Background on EoIP + IPSec

EoIP enables a Ethernet-like Layer2 point to point connection using GRE protocol. BUT...one feature in EoIP is that can be made secure by using IPSec simply by setting the "IPSec Secret" on both ends of an EoIP tunnel. Internally, Mikrotik adds some need dynamic config to /ip/ipsec to make this happen & can look there to see the actually tunnel connections.

Importantly, the Layer2 traffic is wrapped in GRE, then IPSec... you got two tunnels going on from a firewall/security POV.

There are a lot of VPN choices on Mikrotik, most be better than EoIP+IPSec for "normal" traffic. But for enable a "secure, wide-area RoMON" network, this approach has some value. Probably other use cases too. But for efficient and high performance needs might look elsewhere. So more as what if the "main" VPN failed kinda cases.


IPIP (and GRE) using IPSec Secret Should Work Same

@anav also asked:

Also any reason why I should not be able to do same in IPIP which in my mind is superior having less overhead !!

IPIP won't work for RoMON as IP-only / Layer 3 . And you kinda need some very specific case for it be useful over WG or anything. But all the steps above be identical, since both EoIP and IPIP are just a layer above GRE. And all of them support setting an "IPSec Secret" which is what deals with the some restricted NAT.


Example Config

I've left out some parts, but all firewall stuff is show as-is

Okay got it thanks.......... I specifically want to avoid the extra overhead of GRE, if possble, but will acquiesce if not possible.

Also one can go into the default ipsec config and improve the security settings, for example would
change the DEFAULT PROFILE SETTINGS TO
a. HASH proposal (from SHA1) to SHA256
b. encryption algorithm uncheck 3des and aes-128 and use aes-192
c. modp know nothing about so left to auto ( no change )

Finally why allow fast path=no ??

Not sound like you, but what's use case for IPIP?

It won't work for RoMON. RoMON uses a different Layer2 ether-type, so it's not even IP – which kinda why it safe since it's impossible to go via the internet without GRE (or Layer2 VPN like ZeroTier). That is if you trust all the routers connected to RoMON.

The IPSec part should be pretty much the same. You likely don't need the GRE rule, but the IPIP interface need to be otherwise allowed in firewall rules.

Also one can go into the default ipsec config and improve the security settings, for example would
change the DEFAULT PROFILE SETTINGS TO
a. HASH proposal (from SHA1) to SHA256

Tip: The IPSec proposals do have match on BOTH sides. If they don't, you'll see errors in log.

Why I know? I'd forgot one of my TVs is bridged via EoIP+IPSec to my mom's house* to geolocate elsewhere. And the TV complained about no internet this AM. Turns out I needed to change IPSec Proposal to use SHA256, since both were using defaults before. But took a second to realize that it was the proposal...

*uses a single V6 cAPac as AP+router without complaint for years, but no ZT or WG in V6, which is how you end up at EoIP

Ahh so fast path may be fine for IPIP then.
All I want to do is a poor mans version of wireguard to access the router for config purposes as the other end, with least amount of fuss.
assuming I can do that by lets say 172.16.0.1/30 is IPIP of main device with public IP and 172.16.0.2/30 is ip address of remote device.

Stating only need, that I put a firewall rule on remote device with CGNAT or some other non public WANIP.
add chain=input action=accept in-interface=IPIP-name src-address=172.16.0.1/32 comment="accessing local (client) MT from main (server) MT"

Now what about on the main server MT device with public IP what do I put on its input chain so that the tunnel can be established. anything ????

Now what about on the main server MT device with public IP what do I put on its input chain so that the tunnel can be established. anything ????

You need the address-list with remote end's IP address via DDNS to be allowed in filter. See Step 3. The DDNS of remote will be the public IP detected from a CGNAT and that's what IPSec will see.

You'd see ALSO need the interface=ipip-tunnel1 or src-address=172.16.0.x where is X is the far end – since that's what need AFTER IPSec decapsulates the packets. Basically similar to WG – the WG port needs to be allowed, but also the WG interface too.

IPSec essentially makes two trips through the firewall. First for the tunnel, then for the traffic. But you may need some of the firewall rules related to IPSec to be in-place. The default firewall handles the various IPSec policy stuff.

yes, but in your example the input chain rule (traffic from the other public IP), limits by protocol GRE..........
In the case of IPIP, are you saying simply let a public IP address access the input chain, without port or protocol limitation ?????

yes, but in your example the input chain rule (traffic from the other public IP), limits by protocol GRE..........

You can try "protocol=ip-encap" as matcher instead of GRE. I'm not 100% sure that "IPIP" since docs don't say what it is. But worth a try as IPIP is encapsulated IP on the first pass through with IPSec. So in-interface=<WAN interface> with src-address being what CGNAT was using on the internet-side (and detected by DDNS on remote end)

On the 2nd pass through the firewall, it be the /ip/address assigned, as protocol=tcp/udp/etc....so match as desired there. And it's in-interface=ipip-tunnelX at this point.

FWIW, I call it "'two passes' through the firewall" ..... but it really just transitions from a physical interface to a logical interface (via the DECAPSULATE? and ENCAPSULATE? boxes) in the Packet Flow diagrams :

Hi Ammo, I was able to establish an IPIP with ipsec secret with one fixed WANIP and one dynamic Wanip ( and gain access to config via winbox ).
Dont have any cgnat to test however.

Hi Ammo, I was able to establish an IPIP with ipsec secret with one fixed WANIP and one dynamic Wanip ( and gain access to config via winbox ).
Dont have any cgnat to test however.

The DDNS trick here makes the dynamic WAN IP possible, irrespective of a CGNAT. The nice thing about either EoIP or IPIP, is it pretty simple to setup.

How well it works with a "CGNAT", depends on what the ISP is doing.... I kinda use "CGNAT" generically when the ISP does port mapping and/or doesn't allow inbound ports. e.g. "CGNAT" == cases opening a port on a Mikrotik isn't going to work to allow access from internet.

But most CGNATs (at least one AT&T LTE) work with IPSec's NAT transversal schemes. Even through it's EoIP or IPIP (or raw GRE), the CGNAT only see is IPSec using IKEv2. And if a CGNAT didn't allow IPSec, it break a lot of VPNs beyond just more esoteric EoIP.

@anav, did you lose fast-path with IPIP? On the TILE or one of ARM things?

READER NOTE:
- RoMON needs EoIP to function at Layer 2 — IPIP (at layer 3) will not work for RoMON. @anav is experimenting with IPIP as a "poor-mans WireGuard" for a Layer3 VPN between two Mikrotiks.
- All EoIP, GRE, or IPIP ifaces using the "IPSec Secret" should work same with a dynamic WAN IP (e.g. from LTE or DHCP). i.e. Likely solved by, essentially, using /ip/cloud's DDNS name as the "remote-address=" & right firewall stuff.
- If the dynamic IP changes often, it's unclear how quickly a re-connection happen. Presumable at least as long as the DNS cache time for the DDNS record. But I dunno.

Yes, I unchecked it for both. Not sure what that does but seeing as I am using it as backup config access to wireguard, maybe not so critical?? I mean its only for the connection not other traffic.
More straightforward than SSTP actually. I like it.