GRE Tunnel and NAT...

RouterOS General
1

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

2

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

3

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

4

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).

5

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

6

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

/ip ipsec policy
add peer=Peer_Cisco proposal=proposal_to_cisco src-address=2.2.2.2/32 dst-address=1.1.1.1/32 protocol=gre tunnel=no
7

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)

8

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.

9

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.

10

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

11

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 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.

12

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.

13

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)

14

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")

15

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
!

16

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).

17

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…

18

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…

19

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.

20

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).