Hi all,

I've come a long way since my last question in this forum. While I'm still on the beginning of the learning curve, I start linking MT more and more.

However, I am stuck in what I believe is a configuration or even misconception of how some things are done in the MT world. I read several other threads referring to GRE tunnels or NAT-ing issues, but I believe my issue is somewhat different here as you will see.

I have a MT router (replacement of an old Cisco) that allows a local LAN to access the Internet (let's say, "normal home use" to keep things simple), while it also has a VPN to another site. The endpoint there is still a Cisco router. So up until now, we had a cisco-cisco GRE/IPSEC tunnel, now we have a MT-Cisco GRE/IPSEC established over the Internet.

the MT LAN is 172.20.0.0/16, and the Cisco-side LAN is 172.16.0.0/16.
On the MT, IPsec is configured correctly, Phase 1 and 2 come up properly, SA's are created, all good. Same results on the Cisco side, I see the phases 1 and 2 coming up as they should.

Next, the GRE tunnel needs to be established. I created a "gre-tunnel"-type interface on the MT, specified the WAN address as source and the Cisco's WAN address as destination. Then, I created an L3 interface linked to the gre-tunnel, and gave it 172.30.1.2/24 (the remote end has 172.30.1.1/24). (Yeah I know, it is silly to use a /24 for P2P connections, but there was a plan to do a meshed VPN a couple years ago, but it never came...)

Anyway, the gre-tunnel interface comes UP on the MT, and on the Cisco I also see the interface TUNNEL to come up (status UP/UP). So definitely, the GRE is up, both sides confirm that.

Now, the strange thing is that I can't ping the the remote address of that GRE tunnel from either side while the local interface responds:
- from MT, I can ping my own address 172.30.2.2 but cannot ping the Cisco side 172.30.1.1
- from Cisco, I can ping my own address 172.30.1.1 but cannot ping the MT side 172.30.1.2

The plan is of course to put some fancy routing over that link, but I need to fix this before going anywhere else.

The fact that the GRE tunnel is UP but I can't ping the other side of the tunnel rules out any possible routing problem, since this is seen a directly attached link with a distance of 1.
I can also rule out any config issue on the remote Cisco, since no changes have been done there since the local cisco was replaced by the MT. (and of course it worked perfectly before)

I make an educated guess that the issue might be related to NAT on the MT side as it is done quite differently than on cisco IOS.
For the moment, I have a simple mascarade rule so that LAN clients can access the Internet.
I think what I need to do is to add a rule that bypasses NAT for any packet with DST_IP=172.30.1.0/24. Is that correct? However, in that case I don't understand why I can ping the LOCAL side of the tunnel, though. And it doesn't make sense as routing decisions are done before srcnat according to the doc I read.

Do you have some tips or background information that could help me?

thanks!

Denis

So....based on what you posted

You create a ipsec tunnel

then created a gre tunnel


MT ---------------ipsec tunnel -------------- CISCO
\-------------GRE Tunnel -----------------/


I don't think that's what you meant to do. Usually the GRE tunnel is encapsulated with IPSEC so your data is secure. What your doing is not secure.


Between your insecure setup above and Your subnet's all unnecessarily overlapping, I would have a professional look over your current network, as I would venture to say there is some major security concerns.

What you want:

MT IPSEC (------GRE tunnel------) IPSEC CISCO

Hi,

what I wrote was probably misleading.

Of course what I have configured is like your 2nd drawing:
MT IPSEC (------GRE tunnel------) IPSEC CISCO

I agree with you, the first drawing makes no sense and is not secure as data sent over the GRE wouldn't be encrypted in that case (Good thing to point it out though, in case someone was planning to do so!) and of course the routing issues due to overlaps. I even doubt MT would let me do it since you can't have 2 L3 interfaces on the same subnet. Cisco for sure rejects it.

So to clear things up, In the interface menu, I only have a GRE tunnel interface, NOT an IP tunnel interface. I was referring to IPSec in regards of the IPsec configuration menu, where the policies, phase 1 and 2 parameters, pfs groups and finally the encryption key are defined. And this is all fine.

Cheers
Denis

Disable the GRE "keepalive" feature on both sides, it may be incompatible (there is no standard for this, although I think MikroTik followed the Cisco method).
Of course your IPsec policies should only be for a transport (not tunnel) between the two external GRE tunnel addresses, NOT for the traffic transported
through the GRE tunnel (neither the /16 subnets nor the /24 you use on the endpoints).
Therefore you also need no NAT exceptions. That is only for plain IPsec tunnels, not for GRE over IPsec transport.
Show your config export for the GRE and IPsec parts (without the keys).

This is my config, at least the relevant part. 1.1.1.1 and 2.2.2.2 are the public IP addresses on each site (MT=2.2.2.2, HQ=1.1.1.1)

===== STARTS HERE =====
# apr/12/2022 19:52:55 by RouterOS 7.1.1
# software id = GTSP-YUM6
#
# model = RB3011UiAS
# serial number = xx

/interface gre
add allow-fast-path=no mtu=1300 name=gre-tunnel1 remote-address=1.1.1.1

/ip ipsec profile
add dh-group=modp1536 dpd-interval=30s dpd-maximum-failures=100 enc-algorithm=aes-256 lifetime=1h name=Profile_Cisco nat-traversal=no
/ip ipsec peer
add address=1.1.1.1/32 comment="VPN to HQ" local-address=2.2.2.2 name=Peer_Cisco profile=Profile_Cisco
/ip ipsec proposal
set [ find default=yes ] disabled=yes
add enc-algorithms=aes-256-cbc lifetime=1h name=proposal_to_cisco pfs-group=modp1536

/ip firewall connection tracking
set enabled=yes

/ip settings
set max-neighbor-entries=8192 rp-filter=strict

/ip address
[...]
add address=172.30.1.2/24 comment="GRE Tunnel1 - HQ" interface=gre-tunnel1 network=172.30.1.0

/ip firewall address-list
add address=172.20.20.0/24 list=NAT
add address=172.20.60.0/24 list=NAT

/ip firewall filter
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related hw-offload=yes
[...]
#These are my attempts fo debug the tunnel connectivity...
add action=accept chain=input dst-address=2.2.2.2 src-address=1.1.1.1
add action=accept chain=output dst-address=1.1.1.1 src-address=2.2.2.2
add action=accept chain=input dst-address=172.30.1.0/24
add action=accept chain=forward dst-address=172.30.1.0/24
[...]
add action=accept chain=forward comment="OUTBOUND INTERNET TRAFFIC" connection-nat-state=srcnat in-interface="LAN" src-address=172.20.0.0/16
[...]
add action=accept chain=forward comment="defconf: accept established,related, untracked" connection-state=established,related,untracked
add action=drop chain=forward comment="defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new in-interface-list=WAN

/ip firewall nat
add action=masquerade chain=srcnat log=yes out-interface=pppoe-WAN src-address=172.20.0.0/16 to-addresses=<WAN_GW>

/ip ipsec identity
add comment=HQ peer=Peer_Cisco

/ip ipsec policy
set 0 disabled=yes proposal=proposal_to_cisco
add dst-address=172.16.0.0/16 peer=Peer_Cisco proposal=proposal_to_cisco src-address=172.20.0.0/16 tunnel=yes

===== ENDS HERE =====

I tried disabling the keepalives, it didn't change anything.
Your point regarding the IPSec Tunnel vs. transport mode is interesting, you might be on to something.

I indeed have it on Tunnel mode, and if I put it in transport mode (which I tried), then phase2 doesn't establish at all.

Thanks!
Denis

Your policy creates plain IPSec tunnel and it overrides any routing. You want policy only for GRE packets between routers:

Interestingly, it turns out that the protocol=gre option is only available through CLI. From the WebGui, you can only choose among all, egp, ggp, icmp, igmp, ip-encap, ipsec, tcp, udp.

I modified the entry according to your suggestion (via CLI - and the config is properly reflected on the GUI too), but phase 2 does not come up. the logs show ipsec error Message "1.1.1.1 failed to pre-process ph2 packet". (even after clearing the SA's on both sides)

GUI accepts protocol number for unlisted protocols.

Try to post config from Cisco (either what the other side has, or what old Cisco had on this side). I don't know much about that myself, but maybe I'll see something in it anyway, or someone else will.

Yes, the protocol number for GRE is 47 and when you enter that it will later be shown as gre.
But in many cases you do not need to do this yourself, when you enter an IPsec secret in your GRE tunnel config all this IPsec setup is done automatically.
It will, however, use the default IPsec settings so you may need to change those for the enc-algorithm and pfs-group you want, and this might have effect on any other IPsec connections you use on the same router so be careful with that.
As Sob wrote, we need the Cisco settings to know what is going wrong. It could be that the Cisco was configured incorrectly all the time (i.e. its "access list" for the policy was wrong and/or its IPsec mode was set to tunnel instead of transport).
Also, I think you should remove the "rp-filter=strict" setting, at least while debugging. You can enable it later and see if it remains working.

Hi Guys,

yes I saw that once entered via CLI, the GUI shows the protocol you entered, I just find it very weird that you have a limited choice from the GUI and that you can't even enter a protocol or protocol number from there as it is a drop-down list to choose from. That feels like a bug to me.

btw, don't judge me regarding the PFS and encryption algo... I know it has been deprecated, but these are the best settings the cisco @HQ is supporting. Replacement is also planned, probably Q1 next year.

I had left the rp-filter to strict as per RFC3704, but of course, let's remove it at least for debug. Do you know if the rp-filter applied also to virtual interfaces such as GRE tunnels, or only to physical interfaces? If only physical interfaces are concerned, then it should not change anything as there is on ly 1 WAN interface on that site.

Gimme a couple minutes so that I can grab and format the Cisco config
cheers
Denis

Here's the config of the Cisco that is the other endpoint:


!
crypto isakmp policy 10
encr aes 256
authentication pre-share
group 5
lifetime 3600
crypto isakmp key <same key as on the Mikrotik> address 2.2.2.2
crypto isakmp keepalive 10 periodic // I also removed this for the test yesterday
!
crypto ipsec transform-set TSET_MIKROTIK esp-aes 256 esp-sha-hmac
crypto ipsec df-bit clear
!
crypto ipsec profile MIKROTIK
set transform-set TSET_MIKROTIK
set pfs group5
!
interface Tunnel1
description TUNNEL TO MIKROTIK
ip address 172.30.1.1 255.255.255.0
ip mtu 1300
qos pre-classify
tunnel source 1.1.1.1
tunnel destination 2.2.2.2
tunnel mode ipsec ipv4
tunnel protection ipsec profile MIKROTIK
!
ip route 0.0.0.0 0.0.0.0 <ISP_GW> // This is the WAN interface
[...]
ip route 172.20.0.0 255.255.0.0 Tunnel1


#the access-lists on the WAN interface are ip any any from/to the public interfaces 1.1.1.1 and 2.2.2.2 in both directions:
ip access-list extended INBOUND
permit ip host 2.2.2.2 host 1.1.1.1
[...]
ip access-list extended OUTBOUND
permit ip host 1.1.1.1 host 2.2.2.2
[...]

#The access-list for NAT-ing from LAN to the WAN interface. It does NOT contain any of the GRE tunnel IP's in the subnet 172.30.0.0/16:
access-list 2 permit 172.16.0.0 0.0.255.255

Cheers
D.

You can type in the drop-down list in the GUI! That is a feature in many places in the MikroTik GUI, the dropdown list shows you existing values or often used new values, but still you can enter your own. "gre" should probably have been part of the hints list, but maybe it was omitted because you do not need to go that route to define a GRE/IPsec tunnel. It can be done from the GRE tunnel config.
The problem with IPsec is that all those detailed settings need to match, or it won't work. Without telling you what is wrong. That is not a MikroTik issue, it is a property of IPsec. That is why it is usually so difficult to get it working cross-manufacturer: you need to know and understand how the other side has set things, and apply the same settings to your new device, which may use other names for the same thing (e.g. others may call pfs-group modp1536 by the name "group 5").
rp-filter applies to all routing. Unfortunately MikroTik still not has the firewall module (which is standard in Linux) where you can match incoming packets by the rp-filter status. When you enable rp-filter it will silently drop all nonmatching traffic, without even keeping a counter. So you will never know what went wrong when this is enabled and it somehow doesn't match.

Here's the config of the Cisco that is the other endpoint:

#the access-lists on the WAN interface are ip any any from/to the public interfaces 1.1.1.1 and 2.2.2.2 in both directions:
ip access-list extended INBOUND
permit ip host 2.2.2.2 host 1.1.1.1
[...]
ip access-list extended OUTBOUND
permit ip host 1.1.1.1 host 2.2.2.2
[...]

It should also include the protocol 47 when you specified that on the MikroTik side.
These access-lists are used as policy generators on Cisco IOS so they should always match exactly or it won't work.

Here I have some old cisco config that I used way in the past:

crypto isakmp policy 10
encr 3des
authentication pre-share
group 5
lifetime 28800
!
crypto isakmp key (thekey) address aa.bb.cc.dd
crypto isakmp keepalive 30 10
!
!
crypto ipsec transform-set aes-sha-transp esp-aes esp-sha-hmac
mode transport
!
crypto ipsec profile vpn-profile
set transform-set aes-sha-transp
set pfs group5
!

(these are not exactly what you need as this was using nhrp and a vpn-profile, but note the "mode transport" that you do not have)

You can type in the drop-down list in the GUI

Definitely not! I cannot enter anything else then what is already in the list. Neither the name of the protocol, not the corresponding protocol number. It could be linked to the browser I was using, I tried with Safari yesterday, but I'll check with Chrome and Firefox tonight.

Thanks for the clarification about rp-filter!

I know from experience that IPsec debug is a pain in the *** when you're working with different manufacturers. I have dealt with such issues quite a bit in the past in my previous job. We've even had cases where we had to involve both manufacturers to solve the issue and it tool months to solve (in the end it turned out to be an undocumented bug at one of them).

naming discrepancies like pfs group 5 vs modp1536 is one of the easiest to solve. Far worse: the Cisco encryption parameter "esp-256-aes" doesn't give you any information about the cypher mode used, whereas MT does does it very well (ie aes-256-cbc, aes-256-gcm,...)

It should also include the protocol 47 when you specified that on the MikroTik side.

Indeed, good point, I will try that tonight! Even though I wouldn't expect the GRE tunnel to come up at all if there is a difference in the ACL's between both sites... But I agree, thes sometimes behave in a very strange way.

Regarding your example, "aes-sha-transp" is just the name you gave the transform set, not a built-in cisco parameter!
This calls the ipsec transform set "crypto ipsec transform-set aes-sha-transp esp-aes esp-sha-hmac" from the ipsec profile "vpn-profile"

It is 100% equivalent to my "TSET_MIKROTIK" name in my config.

(Tip: to avoid such confusions between system parameters and user-defined names, I always put user-defined names in uppercase, like TSET_MIKROTIK")

this is what I mean:

crypto ipsec transform-set TSET_MIKROTIK esp-aes 256 esp-sha-hmac
crypto ipsec df-bit clear
!
crypto ipsec profile MIKROTIK
set transform-set TSET_MIKROTIK
set pfs group5
!

versus:

crypto ipsec transform-set aes-sha-transp esp-aes esp-sha-hmac
mode transport
!
crypto ipsec profile vpn-profile
set transform-set aes-sha-transp
set pfs group5
!

Your "crypto ipsec transform-set" does not have "mode transport". You are right, the aes-sha-transp was just a name I assigned to that to keep it separate from the transform-set that does not have mode transport. But the mode transport is a parameter that determines the way the data is packaged.

About the GUI: when we in the MikroTik world discuss the GUI, we normally mean the winbox program. (which can easily run on Linux and Mac under "wine")
But I just tried it in the Firefox browser and I could type "47" in that Protocol field without problem (just backspace an existing entry and type over it).

Thanks for the hint about Winbox. Indeed I was using the webGUI instead. I will check with Firefox tonight and see if I can type in a different protocol.

I have access to the Cisco router from here, so let me try to change the transform-set to transport mode right away...

I've added the transport mode, the GRE tunnel comes up, and I have a route in the routing table, seen as "directly connected" as it should:

172.30.0.0/24 is subnetted, 1 subnets
C 172.30.1.0 is directly connected, Tunnel1

However I can still only ping my local interface (.1), not the remote MT (.2)

I will try to modify the ACL...

I made rthe following modifications on the Cisco side:

crypto ipsec transform-set TSET_MIKROTIK esp-aes 256 esp-sha-hmac
mode transport

# ACL's on the WAN interface:
ip access-list extended INBOUND
permit gre host 2.2.2.2 host 1.1.1.1
[...]
ip access-list extended OUTBOUND
permit gre host 1.1.1.1 host 2.2.2.2
[...]


but now the GRE tunnel doesn't even come up.

No luck so far, The only way to get the GRE tunnel UP/UP is to put it in tunnel mode, not transport.

Regarding the ACL's on the WAN interface, I don't get any matches on the GRE-specific ones.

On the Cisco side, I see the GRE tunnel flapping regularly, and also on the MT side I see the IPsec SA's being deleted and recreated regularly.

I will run some debugs on the Cisco side too.

(I checked the Policy menu, in both Firefox and Chrome I was able to enter different values then those from the drop-down list, but still not from Safari. I suspect a issue with my browser).

One more thing you can try is to keep original Cisco config (if it's what worked before you added MT), enable IPSec logging on MT (in System->Logging), and check if you see anything interesting there. It's not as friendly as the rest of RouterOS, but not too bad (as long as there aren't multiple tunnels that turn it into one big mess with messages from all mixed together).

The confusing thing for me is how could IPSec on both sides agree on your original config, when you had policy only for 172.16.0.0/16 <-> 172.20.0.0/16, but if Cisco had the same, it could never cover GRE between 1.1.1.1 and 2.2.2.2.

On the cisco side(ipsec debug), I see packets from MT => Cisco coming in:

#pkts decaps: 16, #pkts decrypt: 16, #pkts verify: 16
no errors listed....

@Sob: yeah, good idea, indeed as the original config was 100% fine, it might be a good idea to keep it as it is and to check on the MT side. Is there a way to display the logs on CLI?

I looked into the config again, and maybe I have a hint:

Here's the config of the Cisco that is the other endpoint:


!
crypto isakmp policy 10
encr aes 256
authentication pre-share
group 5
lifetime 3600
crypto isakmp key <same key as on the Mikrotik> address 2.2.2.2
crypto isakmp keepalive 10 periodic // I also removed this for the test yesterday
!
crypto ipsec transform-set TSET_MIKROTIK esp-aes 256 esp-sha-hmac
crypto ipsec df-bit clear
!
crypto ipsec profile MIKROTIK
set transform-set TSET_MIKROTIK
set pfs group5
!
interface Tunnel1
description TUNNEL TO MIKROTIK
ip address 172.30.1.1 255.255.255.0
ip mtu 1300
qos pre-classify
tunnel source 1.1.1.1
tunnel destination 2.2.2.2
tunnel mode ipsec ipv4
tunnel protection ipsec profile MIKROTIK


maybe I should play with that bold line and change it to tunnel mode gre ip instead...

I'm not familiar with Cisco config, and I can say that it seems less intuitive than RouterOS. But if I ask Google about "tunnel mode ipsec ipv4", I see "VTI" all around, which is something that RouterOS doesn't have.

Maybe it is time to first take a step back and remove the IPsec from the equation and see if you can get a plain GRE tunnel working correctly.
Once that works you are sure you have no routing or filtering issues and you can try adding an IPsec variant that works at both ends.
However, I'm sure that I had plain "GRE over IPsec transport" working (no tunnel) in Cisco, only it seems I did not keep any of those configs.
(at some point we had more than two sites and used the Cisco "nhrp" thing that makes that easier to configure)

There is a lot of whining to get VTI implemented in RouterOS. I'm sure that when that finally happens, the whining about "nhrp" will start. After all, those that want inter-operability with other manufacturer's equipment will not rest before it basically is a clone of that.

@Sob: well, that depends of where you come from! Im my case it's the opposite, I am quite comfortable with cisco IOS as I've been working with it for 15+ years, and it's the MT RouterOS that I find less intuitive. The good thing is that the more you work with different vendors, the more comfortable you get with everything.I's just a metter of time!

@pe1chl: I will review the complete config one more time, I'm thinking more and more that my "tunnel mode ipsec ipv4" command might have something to do with the problem. If it doesn't solve it, then I guess you're right, I should remove IPsec completely, establish a GRE tunnel and validate connectivity, and then implement IPsec again...

I'll keep you posted of course, I'm sure this will help others in the future as well.
cheer

Denis

SOLVED!

Alright, I found the problem: It was indeed an issue between the generic GRE implementation used by MT and the based-on-GRE-ish VTI implementation by Cisco.

this works:

interface Tunnel1
description TUNNEL TO MIKROTIK
ip address 172.30.1.1 255.255.255.0
ip mtu 1300
qos pre-classify
tunnel source 1.1.1.1
tunnel destination 2.2.2.2
tunnel mode gre ip
tunnel protection ipsec profile MIKROTIK


I still need to figure out some details which of course I will share here.
What gave me the hint was that it could not be the IPSEC posing problems, as the SA's were OK in both directions. that also ruled out ACL-related issues. As a consequence, the issue must have been on the tunnel itself, and the constant flapping was a good indicator.

I will review my config and play with different settings before sharing the final results.

Ok great!
And do you now have an IPsec profile operating in transport mode? Or still tunnel mode?
Transport mode is more efficient but it will not work when NAT-T is required.

GRE is in tunnel mode for the moment. I will check tonight is I can put it in transport mode or if it fails. I don't yet know which one I end up using in production. IPsec is taking care of the encryption between the public IP's of both endpoints and I don't NAT anything on these interfaces, so it should be fine to use transport mode indeed. But on the other hand, I don't think the additional header of tunnel mode would have a significant impact on performances. The WAN links are 500MB symmetric fiber on both sites, with an average of 30-50 Mbps traffic running across it...

Make sure you have a correct MTU on the GRE tunnel and some way to promote the use of smaller packets across the tunnel so that not everything has to be fragmented.
I personally use this mangle rule: It should also work with the "Clamp TCP MSS" option in the GRE tunnel config, but I prefer to have the visible rule with counter etc. The GRE tunnel option may be a bit faster and/or better work with FastTrack enabled.

Here's a working example of a Mikrotik - Cisco IOS site-to-site VPN. I hope it will help some of you who, like me, struggled to make it work.
You have to use GRE tunnel mode, I was unable to make transport mode work!

MIKROTIK SIDE:

/interface gre
add allow-fast-path=no mtu=1300 name=gre-tunnel1 remote-address=1.1.1.1

/ip ipsec profile
add dh-group=modp1536 dpd-interval=30s dpd-maximum-failures=100 enc-algorithm=aes-256 lifetime=1h name=Profile_Cisco nat-traversal=no

/ip ipsec peer
add address=1.1.1.1/32 comment="VPN to Cisco" local-address=2.2.2.2 name=Peer_Cisco profile=Profile_Cisco

/ip ipsec proposal
add enc-algorithms=aes-256-cbc lifetime=1h name=IPsec_Proposal_Cisco pfs-group=modp1536

/ip address
add address=172.30.1.2/30 comment="GRE Tunnel to Cisco" interface=gre-tunnel1 network=172.30.1.0

/ip ipsec identity
# CHOOSE A GOOD PWD, but make sure you don't have a question mark "?" at the end, it will not be processed on the Cisco Endpoint! EXAMPLE:
add comment=CiscoPSK peer=Peer_Cisco secret="PleaseUseABetterPassword"

/ip firewall filter
add action=accept chain=input comment="Allow traffic from Cisco to Mikrotik" dst-address=2.2.2.2 src-address=1.1.1.1
add action=accept chain=output dst-address=1.1.1.1 src-address=2.2.2.2
#EXAMPLE: allow inbound traffic from the LAN behind distant Cisco Router to the local LAN behing the Mikrotik router. Also do the equivalent on your Cisco router.
add action=accept chain=input comment="Allow traffic from Cisco LAN to MT LAN" dst-address=10.0.0.0/24 log=yes src-address=192.168.0.0/24

/ip ipsec identity
add comment=Porcelette peer=Peer_Cisco

/ip ipsec policy
add dst-address=195.146.240.235/32 peer=Peer_Cisco proposal=IPsec_Proposal_Cisco protocol=gre src-address=2.2.2.2/32 tunnel=yes

/ip route
add disabled=no distance=1 dst-address=<REMOTE_NET/MASK> gateway=gre-tunnel1 pref-src="" routing-table=main suppress-hw-offload=no
#EXAMPLE:
add disabled=no distance=1 dst-address=192.168.0.0/24 gateway=gre-tunnel1 pref-src="" routing-table=main suppress-hw-offload=no



CISCO SIDE:
crypto isakmp policy 10
encr aes 256
authentication pre-share
group 5
lifetime 3600
crypto isakmp key PleaseUseABetterPassword address 2.2.2.2 // => please change this with a PSK of your own!! remember, no question mark accepted at the end of the PSK!
crypto isakmp keepalive 10 periodic
!
crypto ipsec transform-set TSET_MIKROTIK esp-aes 256 esp-sha-hmac
crypto ipsec df-bit clear
!
crypto ipsec profile MIKROTIK
set transform-set TSET_MIKROTIK
set pfs group5
!
interface Tunnel1
description TUNNEL TO MIKROTIK
ip address 172.30.1.1 255.255.255.252
ip mtu 1300 // => adapt accorting to your WAN link values
ip tcp adjust-mss 1260 // => adapt accorting to your WAN link values
qos pre-classify // => only needed if you do some QoS over the GRE Tunnel.
tunnel source 1.1.1.1
tunnel destination 2.2.2.2
tunnel mode gre ip // => this won't apprear in the config since it's the default setting.
tunnel protection ipsec profile MIKROTIK


That's it! And no, you don't need any NAT-ing exceptions if you already a have something like a masquarade NAT rule in place for allowing local (MT) clients to browse the Internet.

Special characters in the PSK indeed are "asking for trouble". I use only upper/lowercase letters and digits. Normally a 32-character random password, I have a generator for that.
NAT exceptions indeed are required only when making direct IPsec tunnels, not when using GRE over IPsec. That is one of its advantages.
Note that on the MikroTik side you can considerably simplify configuration by omitting all the IPsec config and adding the PSK in the GRE tunnel setup.
The IPsec config will be generated dynamically.
But if that autogenerated config is compatible with the other side of course remains to be seen. It works fine between two MikroTik routers and you can see what it generates and possibly adapt the Cisco config at the other side.

hi you guys! i have exactly the same problem here and i really can't figure it out! i found this thread and so did not create a new same topic. i'm gonna post my configs here, please help!
mikrotik: cisco: kind regards.

Hi, have you figured it out yet or shall we look into it?