Home / server / Questions / 540967
Accepted
dorian
Asked: 2013-09-24 04:26:36 +0800 CST

How do I configure routing for an IPSEC tunnel between Openswan and RouterOS

  • 772

I am trying to create a site-to-site VPN between a Linux router that runs openswan and shorewall (host A, serving subnet 10.10.0.0/16) and a MikroTek RouterBoard running RouterOS 6.3 (host B, serving 192.168.88.0/24).

The IPSEC tunnel itself seems to be up, host A says:

# service ipsec status
IPsec running  - pluto pid: 4292
pluto pid 4292
1 tunnels up
some eroutes exist

and:

#ipsec auto --status
<SNIP>
000 #2: "office-connect":500 STATE_QUICK_I2 (sent QI2, IPsec SA established); EVENT_SA_REPLACE in 27422s; newest IPSEC; eroute owner; isakmp#1; idle; import:admin initiate
000 #2: "office-connect" esp.65bcd1d@<REDACTED> esp.c8d18ebd@<REDACTED> tun.0@<REDACTED> tun.0@<REDACTED> ref=0 refhim=4294901761
000 #1: "office-connect":500 STATE_MAIN_I4 (ISAKMP SA established); EVENT_SA_REPLACE in 2348s; newest ISAKMP; lastdpd=72s(seq in:0 out:0); idle; import:admin initiate

while on host B:

/ip ipsec remote-peers print
 0 local-address=<REDACTED> remote-address=<REDACTED> state=established side=responder established=11m26s

and:

/ip ipsec policy print
Flags: T - template, X - disabled, D - dynamic, I - inactive 
 0    src-address=192.168.88.0/24 src-port=any dst-address=10.10.0.0/16 dst-port=any protocol=all action=encrypt level=require ipsec-protocols=esp tunnel=yes 
      sa-src-address=<REDACTED> sa-dst-address=<REDACTED> proposal=Office-Connect priority=0

I followed the instrutions on http://www.shorewall.net/IPSEC-2.6.html to configure shorewall and http://wiki.mikrotik.com/wiki/Manual:IP/IPsec to setup a NAT Bypass rule.

However, I can't actually get any packets through the tunnel, on A:

# ping -c4 192.168.88.1
PING 192.168.88.1 (192.168.88.1) 56(84) bytes of data.

--- 192.168.88.1 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3016ms

on B:

/ping count=4 10.10.0.1
HOST                                     SIZE TTL TIME  STATUS                                                                                               
10.10.0.1                                               timeout                                                                                              
10.10.0.1                                               timeout                                                                                              
10.10.0.1                                               timeout                                                                                              
10.10.0.1                                               timeout                                                                                              
    sent=4 received=0 packet-loss=100%

I am at a bit of a loss how to proceed, my experience in networking is not too great. So I'd be helpful for any hints, even just how to debug this problem. I'll gladly provide additional configuration samples or log output if required. Many thanks!

vpn

1 Answers

  1. Best Answer

    Here's the solution if anyone else has the same problem... The problem was that I have another VPN setup on the shorewall box, which is a L2TP road warrior setup called vpn (the site-to-site VPN is named ovpn) So my /etc/shorewall/zones file looked like this:

    #ZONE           TYPE            OPTIONS         IN                      OUT
#                                               OPTIONS                 OPTIONS
<SNIP>
vpn             ipsec
l2tp            ipv4
ovpn            ipv4

    and my /etc/shorewall/hosts like this:

    #ZONE   HOST(S)                                 OPTIONS
vpn     eth0:0.0.0.0/0
ovpn    eth0:192.168.88.0/24,<REDACTED> ipsec

    It turns out that the order of zone declarations in the zones file is important (but not inside the hosts file)—for every connection shorewall chooses the first zone that matches. As the vpn zone has a hosts entry that matches every remote host, all ovpn connections would be matched by the vpn zone and then routed to xl2tpd, which of course didn't work.

    So I reversed the zone entries for vpn and ovpn, and everything worked just fine.

    • 4