I have a test setup like this:

PC(172.16.0.2/30) - (172.16.0.1/30)R1(10.0.0.2/24) - (10.0.0.1/24)R2(x.x.x.x) - corporate network

And have created a ipsec tunnel between R1 and R2, defined on R1 as:
The tunnel is working as expected, the problem is only that I can't communicate with R1s IP 172.16.0.1 outside the ipsec tunnel what so ever. Not even the PC (172.16.0.2) can ping 172.16.0.1 when the tunnel is established.

I assume it's because ipsec operates even below the routing table, so when R1 is trying to reply to my pings ipsec sees an outgoing packet från 172.16.0.1 -> 172.16.0.2 which matches the ipsec SA definition so it grabs on the packet.

So, how can I solve this? Is it possible to add some special route or iptables packet mangling magic to make packets go outside the ipsec tunnel even though there are a matching ipsec tunnel?

I do want to use 0/0 as dest for the ipsec tunnel as I have a big corporate network on the other side of the tunnel that should all be routed through the ipsec tunnel.

If the final solution would have been between two mikrotiks I could have solved it with a transport mode tunnel and a IPIP tunnel above it and used normal routing tables to route whatever I wanted over the tunnel, but in my case R2 will be a Netscreen firewall in the final solution which doesn't support IPIP tunnels AFAIK.

R1 is currently a Netscreen FW as well which has this working by using a seperate vrouter for the inside network and route based ipsec tunnels so then it's no problem, but I want this box placed with a Mikrotik router but with retained functionality.

Well you will not be able to ping 172.16.0.1 from you pc because router is encrypting all outgoing traffic, but your PC is unable to encrypt them.
You should use more specific networks instead of 0.0.0.0/0 or add another ipsec policy that will not encrypt traffic with source and destination networks of 172.16.0.0/24

Yes, I understand that's the reason, I'm just wondering if there are any workarounds.

Can't ipsec be bond to a specific interface to begin with? When using openswan on Linux I have a vague memory that you explicitly defined what interface ipsec should operate on, or simplified by pointing to %defaultroute which caused it bind to the external interface.

That way ipsec should only pickup packets after it has looked in the normal routing table and decided that this packet is about to leave on the external interface, so let's check if it has a matching SA. So traffic on the local interface should not be affected by the ipsec tunnel at all.

or add another ipsec policy that will not encrypt traffic with source and destination networks of 172.16.0.0/24

How would such a policy look like? I tried adding:
But that didn't change anything. Still can't ping 172.16.0.1.

And using a smaller remote network is not an option. I want ALL internet traffic from the local network to go over tunnel.

Like others have suggested. Support for routebased IPSec VPN tunnels would have been great so one could just setup a 0/0 - 0/0 tunnel and then just use the normal routingtable tricks to route whatever you want into the ipsec tunnel. Having ipsec operate below the routing engine really makes it inflexible.

Another example of why Mikrotik should add route/interface based VPN's

A lot of people want this feature, and it would not be too difficult to implement!

Do you mean like this...?

Yes very similar, on other vendors IPSEC devices you can select "Interface Mode" when creating a IPSEC connection, or often they will have a tick box to enable Interface mode and a selector to select which "virtual interface" you want to bind to.

This basically terminates the IPSEC tunnel to a virtual interface, you can then just route to that virtual interface.

Another advantage is that you can give the tunnel interfaces IP addresses and then run OSPF and other dynamic routing protocols over them, and they will also show up in a traceroute.

It is possible to get similar functionality now with Mikrotik by running EoIP/GRE inside an IPSEC tunnel, but this is not compatible with the standard implementation used by vendors such as Fortinet, Cisco and Juniper.


We have IPSEC VPN's running from Checkpoints to Fortinets, Fortinets to Juniper SSG's, Juniper SSG's to Cisco and every other combination with those vendors and they are all compatible. If Mikrotik added this functionality we would sell a whole lot more Mikrotik RB450G's that is for sure!

Hi all !
I'm have simular problem with IPSec too. I hope you help me too, if you know how to do that.
In my case I must create a setup like this:

PC (10.9.10.11) - Subdivision of Corporation. LAN A (10.9.10.0/27) - (10.9.10.1) MR1 (195.3.4.2) - (88.21.3.4) MR2 (10.9.1.10) - LAN B (10.0.0.0/8) Corporate network - Server 10.9.1.1

I have created a ipsec tunnel between Router1 and Rrouter2, defined on Roouter1 as:

Code:

src-address=10.9.10.0/27:any dst-address=10.0.0.0/8:any protocol=all action=encrypt level=require ipsec-protocols=esp tunnel=yes \
sa-src-address=195.3.4.2 sa-dst-address=88.21.3.4 proposal=default manual-sa=none priority=0

Router2
Code:

src-address=10.0.0.0/8:any dst-address=10.9.10.0/27:any protocol=all action=encrypt level=require ipsec-protocols=esp tunnel=yes \
sa-src-address=88.21.3.4 sa-dst-address=195.3.4.2 proposal=default manual-sa=none priority=0

I have a problem too is only that I can't communicate with R1s IP 10.9.10.1 outside the ipsec tunnel what so ever. Not even the PC (10.9.10.11) can ping 10.9.10.1 when the tunnel is established.
But I must communicate with R1s IP 10.9.10.1.
On Cisco routers this scheme work perfectly.
What can I do ? Anybody from Mikrotik software developers or administrators or community people with highest experience help me ?

P.S. Sorry for my bad English ...

I see, no you run into the exact type of problem that I do, that MR1 thinks that everyting destinated for 10/8 should be handled by ipsec, even the local 10.9.10.0/27 subnet which you of course want to be able to communicate with directly.

I don't see any solution with the current ipsec implementation on Mikrotik. If you can't readdress one of the sites so the IP addresses are not overlapping I'd say go for an IPIP tunnel over a IPsec transport-mode tunnel instead.

Like: And you do the reverse on the MR2 and assign 172.16.0.2 to the IPIP interface. Then you simply route 10.0.0.0/8 -> 172.16.0.2 on MR1 and 10.9.10.0/27 -> 172.16.0.1 on MR2.

You get a little bit more overhead by running IPIP over IPsec but you get a much more flexible tunnel that you can route whatever network you want through.

I see, no you run into the exact type of problem that I do, that MR1 thinks that everyting destinated for 10/8 should be handled by ipsec, even the local 10.9.10.0/27 subnet which you of course want to be able to communicate with directly.

I don't see any solution with the current ipsec implementation on Mikrotik. If you can't readdress one of the sites so the IP addresses are not overlapping I'd say go for an IPIP tunnel over a IPsec transport-mode tunnel instead.

I understand this and I was try to create IPIP-tunnel over IPSec, that was first what I was do when I understand what happened with IPSec ...
This work, but I have problem with packet fragmentation.
My WAN link use PPPoE on both sides, and with this combination (PPPoE-IPSec-IPIP) packets with size over 1400 bytes don't transmit over IPIP tunnel.
Now I solve problem use OpenVPN instead IPSec in ip route mode.
On another network setup I use EoIP over IPSec, this work too, but that's all workarounds.
I hope in future Mikrotik fix this behaviour RouterOS with IPSec policy because I can't work with Mikrotik equipment and equipment of other vendors.

Like:

Code: Select all

/ip ipsec policy
add action=encrypt disabled=no dst-address=88.21.3.4/32:any ipsec-protocols=esp \
    level=require manual-sa=none priority=0 proposal=default protocol=all \
    sa-dst-address=88.21.3.4 sa-src-address=195.3.4.2 src-address=195.3.4.2/32:any \
    tunnel=no

/interface ipip
add comment="" disabled=no local-address=195.3.4.2 mtu=1480 name=ipip1 \
    remote-address=88.21.3.4

/ip address
add address=172.16.0.1/30 broadcast=172.16.0.3 comment="" disabled=no interface=\
    ipip1 network=172.16.0.0

And you do the reverse on the MR2 and assign 172.16.0.2 to the IPIP interface. Then you simply route 10.0.0.0/8 -> 172.16.0.2 on MR1 and 10.9.10.0/27 -> 172.16.0.1 on MR2.

You get a little bit more overhead by running IPIP over IPsec but you get a much more flexible tunnel that you can route whatever network you want through.

Thank you for good idea ! I'm will try recheck all settings and find why I have problems with fragmentation on IPIP tunnel over IPSec and PPPoE
Thank you for your help !

Thank you for good idea ! I'm will try recheck all settings and find why I have problems with fragmentation on IPIP tunnel over IPSec and PPPoE
Thank you for your help !

Have you decreased the MTU of the IPIP interface? It's default value of 1480 assumes an MTU of 1500 for the physical interface, so if you run PPPoE on the physical interface you need to decrease the IPIP MTU with the overhead of PPPoE.

Thank you for good idea ! I'm will try recheck all settings and find why I have problems with fragmentation on IPIP tunnel over IPSec and PPPoE
Thank you for your help !

Have you decreased the MTU of the IPIP interface? It's default value of 1480 assumes an MTU of 1500 for the physical interface, so if you run PPPoE on the physical interface you need to decrease the IPIP MTU with the overhead of PPPoE.

Ah, and you will also have to decrease it further to take the ipsec overhead into account. Don't have the exact numbers now but you should end at somewhere like 1430-1440. Ethernet (1500) - PPPoE(8) - ESP(32?) - IPIP(20) = 1440

I have a test setup like this:

PC(172.16.0.2/30) - (172.16.0.1/30)R1(10.0.0.2/24) - (10.0.0.1/24)R2(x.x.x.x) - corporate network

And have created a IPsec tunnel between R1 and R2, defined on R1 as:

Code: Select all

src-address=172.16.0.0/30:any dst-address=0.0.0.0/0:any protocol=all action=encrypt level=require ipsec-protocols=esp tunnel=yes \
sa-src-address=10.0.0.2 sa-dst-address=10.0.0.1 proposal=default manual-sa=none priority=0

The tunnel is working as expected, the problem is only that I can't communicate with R1s IP 172.16.0.1 outside the ipsec tunnel what so ever. Not even the PC (172.16.0.2) can ping 172.16.0.1 when the tunnel is established.

I assume it's because ipsec operates even below the routing table, so when R1 is trying to reply to my pings ipsec sees an outgoing packet från 172.16.0.1 -> 172.16.0.2 which matches the ipsec SA definition so it grabs on the packet.

So, how can I solve this? Is it possible to add some special route or iptables packet mangling magic to make packets go outside the ipsec tunnel even though there are a matching ipsec tunnel?

I do want to use 0/0 as dest for the ipsec tunnel as I have a big corporate network on the other side of the tunnel that should all be routed through the ipsec tunnel.

If the final solution would have been between two mikrotiks I could have solved it with a transport mode tunnel and a IPIP tunnel above it and used normal routing tables to route whatever I wanted over the tunnel, but in my case R2 will be a Netscreen firewall in the final solution which doesn't support IPIP tunnels AFAIK.

R1 is currently a Netscreen FW as well which has this working by using a seperate vrouter for the inside network and route based ipsec tunnels so then it's no problem, but I want this box placed with a Mikrotik router but with retained functionality.

=================================================
If you want these IpSec problems FIXED please VOTE for it!

"Implement IPSEC "Virtual Interface" VPN's, allowing easy dynamic routing across IPSEC"
http://wiki.mikrotik.com/wiki/MikroTik_ ... mplemented

Thanks for your vote!!!
=================================================

I agree with the general consensus that the RouterOS IpSec Implementation could use some work. Having used Ipsec on Mikrotik for years, I have learned some workarounds and can solve this problem for you.

The problem is that when the router goes to respond to the Pc's ping, it sees that the PC's IP address, 172.16.0.2/30 matches the IpSec policy for destination = 0.0.0.0/0, encrypts the packet and sends it out the tunnel, in the wrong direction.

To fix it, you must create a second IpSec policy exempting that subnet from encryption:

IP -> IpSec -> Policies -> new (Click the + button)

General Tab
-----
Src. Address: 172.16.0.1/32
Dst. Address: 172.16.0.0/30 (for the whole subnet)
Protocol: all

Action Tab
-----
Action: none (That's right!! Tell it to do NOTHING.)
Level: require
IPsec Protocols: esp
Tunnel: checked
SA Src. Address: 0.0.0.0
SA Dst. Address: 0.0.0.0
Proposal: default


Finally, you have to go to the Mikrotik command line and move this rule AHEAD of the offending rule using the move command:

/ip ipsec policy
print

Suppose you see 2 policies, this one on slot 1 and the offending one on slot 0. Type:

move 1 0

to fix the order. There is NO interface to this command in Winbox!

Hope it helps...

=================================================
If you want these IpSec problems FIXED please VOTE for it!

"Implement IPSEC "Virtual Interface" VPN's, allowing easy dynamic routing across IPSEC"
http://wiki.mikrotik.com/wiki/MikroTik_ ... mplemented

Thanks for your vote!!!
=================================================

I have the same problem and it looks like taylorc solution does not work.

My setup: (should be migrated from a snapgear who has become too slow for the tast).

Network with three VLAN, three routed IP Ranges and one private IP Range.
All those have to communicate to each other and are attached to the internet via an IPSEC tunnel.

VLAN1(default): 157.161.57.65/28 (Routed via IPSEC Tunnel)
VLAN1(default): 192.168.57.1/24 (NAT'ed, not routed via IPSEC)
VLAN3(pratteln, tagged): 157.161.57.1/27 (Routed via IPSEC Tunnel)
VLAN2(scoutnet, tagged): 157.161.6.1/24 (Routed via IPSEC Tunnel)

At the moment I'm still not able to exchange traffic from one VLAN to another.
From a VLAN to the Internet and vice versa is fine.
But if I connect a computer to LAN2 (VLAN1) I'm not even able to ping the local default GW on one of the addresses. It looks like the microtik is sending everything, even replies that should get on on the same ethernet interface out of the tunnel.

I'm testing in the LAB, so please ignore WAN not being connected:

[admin@MikroTik] > /interface print
Flags: D - dynamic, X - disabled, R - running, S - slave
# NAME TYPE MTU L2MTU MAX-L2MTU MAC-ADDRESS
0 R LAN2 ether 1500 1598 4074 00:0C:42:FE:F3:A3
1 LAN3 ether 1500 1598 4074 00:0C:42:FE:F3:A4
2 LAN4 ether 1500 1598 4074 00:0C:42:FE:F3:A5
3 LAN5 ether 1500 1598 4074 00:0C:42:FE:F3:A6
4 WAN1 ether 1500 1598 4074 00:0C:42:FE:F3:A2
5 R pratteln vlan 1500 1594 00:0C:42:FE:F3:A3
6 R scoutnet vlan 1500 1594 00:0C:42:FE:F3:A3

[admin@MikroTik] > /interface vlan print
Flags: X - disabled, R - running, S - slave
# NAME MTU ARP VLAN-ID INTERFACE
0 R pratteln 1500 enabled 3 LAN2
1 R scoutnet 1500 enabled 2 LAN2

[admin@MikroTik] > /ip address print
Flags: X - disabled, I - invalid, D - dynamic
# ADDRESS NETWORK INTERFACE
0 157.161.57.65/28 157.161.57.64 LAN2
1 192.168.1.1/24 192.168.1.0 LAN5
2 192.168.57.1/24 192.168.57.0 LAN2
3 157.161.57.30/27 157.161.57.0 pratteln
4 157.161.6.1/24 157.161.6.0 scoutnet
5 D 157.161.4.182/24 157.161.4.0 WAN1

[admin@MikroTik] > /ip route print
Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, B - blackhole, U - unreachable, P - prohibit
# DST-ADDRESS PREF-SRC GATEWAY DISTANCE
0 DS 0.0.0.0/0 157.161.4.1 0
1 ADC 157.161.4.0/24 157.161.4.182 WAN1 0
2 ADC 157.161.6.0/24 157.161.6.1 scoutnet 0
3 ADC 157.161.57.0/27 157.161.57.30 pratteln 0
4 ADC 157.161.57.64/28 157.161.57.65 LAN2 0
5 ADC 192.168.1.0/24 192.168.1.1 LAN5 0
6 ADC 192.168.57.0/24 192.168.57.1 LAN2 0

[admin@MikroTik] /ip ipsec policy> print
Flags: X - disabled, D - dynamic, I - inactive
0 I src-address=192.168.57.0/24 src-port=any dst-address=192.168.57.0/24 dst-port=any protocol=all action=none level=require ipsec-protocols=esp tunnel=yes sa-src-address=:: sa-dst-address=::
proposal=default priority=0

1 I src-address=157.161.57.0/27 src-port=any dst-address=157.161.57.0/27 dst-port=any protocol=all action=none level=require ipsec-protocols=esp tunnel=yes sa-src-address=:: sa-dst-address=::
proposal=default priority=0

2 I src-address=157.161.6.0/24 src-port=any dst-address=157.161.6.0/24 dst-port=any protocol=all action=none level=require ipsec-protocols=esp tunnel=yes sa-src-address=:: sa-dst-address=::
proposal=default priority=0

3 I src-address=157.161.57.64/28 src-port=any dst-address=157.161.57.64/28 dst-port=any protocol=all action=none level=require ipsec-protocols=esp tunnel=yes sa-src-address=:: sa-dst-address=::
proposal=default priority=0

4 I src-address=192.168.57.0/24 src-port=any dst-address=157.161.6.0/24 dst-port=any protocol=all action=none level=require ipsec-protocols=esp tunnel=yes sa-src-address=:: sa-dst-address=::
proposal=default priority=0

5 src-address=157.161.57.0/27 src-port=any dst-address=157.161.57.64/28 dst-port=any protocol=all action=none level=require ipsec-protocols=esp tunnel=yes sa-src-address=:: sa-dst-address=::
proposal=default priority=0

6 src-address=157.161.57.0/27 src-port=any dst-address=157.161.6.0/24 dst-port=any protocol=all action=none level=require ipsec-protocols=esp tunnel=yes sa-src-address=:: sa-dst-address=::
proposal=default priority=0

7 src-address=157.161.57.0/27 src-port=any dst-address=192.168.57.0/24 dst-port=any protocol=all action=none level=require ipsec-protocols=esp tunnel=yes sa-src-address=:: sa-dst-address=::
proposal=default priority=0

8 src-address=157.161.57.64/28 src-port=any dst-address=192.168.57.0/24 dst-port=any protocol=all action=none level=require ipsec-protocols=esp tunnel=yes sa-src-address=:: sa-dst-address=::
proposal=default priority=0

9 src-address=157.161.57.64/28 src-port=any dst-address=157.161.6.0/24 dst-port=any protocol=all action=none level=require ipsec-protocols=esp tunnel=yes sa-src-address=:: sa-dst-address=::
proposal=default priority=0

10 I src-address=157.161.57.64/28 src-port=any dst-address=157.161.57.0/27 dst-port=any protocol=all action=none level=require ipsec-protocols=esp tunnel=yes sa-src-address=:: sa-dst-address=::
proposal=default priority=0

11 I src-address=157.161.6.0/24 src-port=any dst-address=157.161.57.0/27 dst-port=any protocol=all action=none level=require ipsec-protocols=esp tunnel=yes sa-src-address=:: sa-dst-address=::
proposal=default priority=0

12 I src-address=157.161.6.0/24 src-port=any dst-address=157.161.57.64/28 dst-port=any protocol=all action=none level=require ipsec-protocols=esp tunnel=yes sa-src-address=:: sa-dst-address=::
proposal=default priority=0

13 src-address=157.161.6.0/24 src-port=any dst-address=192.168.57.0/24 dst-port=any protocol=all action=none level=require ipsec-protocols=esp tunnel=yes sa-src-address=:: sa-dst-address=::
proposal=default priority=0

14 I src-address=192.168.57.0/24 src-port=any dst-address=157.161.57.0/27 dst-port=any protocol=all action=none level=require ipsec-protocols=esp tunnel=yes sa-src-address=:: sa-dst-address=::
proposal=default priority=0

15 I src-address=192.168.57.0/24 src-port=any dst-address=157.161.57.64/28 dst-port=any protocol=all action=none level=require ipsec-protocols=esp tunnel=yes sa-src-address=:: sa-dst-address=::
proposal=default priority=0

16 src-address=157.161.57.0/27 src-port=any dst-address=0.0.0.0/32 dst-port=any protocol=all action=encrypt level=require ipsec-protocols=esp tunnel=yes sa-src-address=0.0.0.0 sa-dst-address=157.161.1.3
proposal=Neuenhof priority=0

17 src-address=157.161.57.64/28 src-port=any dst-address=0.0.0.0/32 dst-port=any protocol=all action=encrypt level=require ipsec-protocols=esp tunnel=yes sa-src-address=0.0.0.0 sa-dst-address=157.161.1.>
proposal=Neuenhof priority=0

18 src-address=157.161.6.0/24 src-port=any dst-address=0.0.0.0/32 dst-port=any protocol=all action=encrypt level=require ipsec-protocols=esp tunnel=yes sa-src-address=0.0.0.0 sa-dst-address=157.161.1.3
proposal=Neuenhof priority=0

Can anobody tell me how to get that setup working with a microtik?

-Benoit-