MikroTik

Posted: **Fri Feb 24, 2006 7:27 pm**

I'm trying to get an IPSec-tunnel up between two mt-routers (ROS 2.9.13). The router at the central-site has a static public IP-address (x.91.97.147)
the other router at the remote-site has a dynamic public address. following the manual, as far is i understand, this is the configuration:

central-site (y.z.45.51):

/ ip ipsec peer 
add address=0.0.0.0/32:500 secret="******" generate-policy=yes exchange-mode=aggressive \
    send-initial-contact=no proposal-check=obey hash-algorithm=sha1 enc-algorithm=aes-256 dh-group=modp1024 \
    lifetime=1d lifebytes=0 disabled=no

remote-site (y.z.14.51/24):

/ ip ipsec policy 
add src-address=y.z.14.0/24:any dst-address=y.z.45.0/24:any protocol=all action=encrypt level=require \
    ipsec-protocols=esp tunnel=yes sa-src-address=0.0.0.0 sa-dst-address=x.91.97.147 proposal=default \
    manual-sa=none dont-fragment=clear disabled=no 

/ ip ipsec peer 
add address=x.91.97.147/32:500 secret="******" generate-policy=no exchange-mode=aggressive \
    send-initial-contact=yes proposal-check=obey hash-algorithm=sha1 enc-algorithm=aes-256 dh-group=modp1024 \
    lifetime=1d lifebytes=0 disabled=no

but packets are rejected. log file on the remote-site:

10:02:56 ipsec,ike,info queuing SA request, phase 1 with peer 217.91.97.147 will be established first        
10:02:56 ipsec,ike,info initiating phase 1, starting mode Aggressive (local 84.57.7.20:500) (remote          
    unknown)                                                                                                 
10:02:56 ipsec,info ipsec packet discarded: src=53.109.14.51 dst=53.102.45.51                                
10:02:57 ipsec,info ipsec packet discarded: src=53.109.14.51 dst=53.102.45.51                                
10:02:58 ipsec,info ipsec packet discarded: src=53.109.14.51 dst=53.102.45.51                                
10:02:59 ipsec,info ipsec packet discarded: src=53.109.14.51 dst=53.102.45.51                                
10:03:00 ipsec,info ipsec packet discarded: src=53.109.14.51 dst=53.102.45.51                                
10:03:28 ipsec,ike,info dequeuing SA request to 217.91.97.147, phase 1 wait timed out                        
10:03:57 ipsec,ike,info phase 1 negotiation timed out

and on the central site:

17:25:11 ipsec,ike,info received ISAKMP packet from 84.57.7.20:500, phase 1, Aggressive                      
17:25:11 ipsec,ike,info peer not configured                                                                  
17:25:21 ipsec,ike,info received ISAKMP packet from 84.57.7.20:500, phase 1, Aggressive                      
17:25:21 ipsec,ike,info peer not configured                                                                  
17:25:31 ipsec,ike,info received ISAKMP packet from 84.57.7.20:500, phase 1, Aggressive                      
17:25:31 ipsec,ike,info peer not configured

any hints? is it correct to use aggressive mode and have the central-site router set to "generate-policy=yes"?

tia.

Posted: **Fri Feb 24, 2006 8:36 pm**

0.0.0.0/32 is incorrect. It should be 0.0.0.0/0

Regards

Andrew

Posted: **Sat Feb 25, 2006 10:30 am**

Many thanks. This solves the first problem, but i cant find this hint anywhere mentioned in the manual, how-to, faq, etc. Maybe it should be added...
It is also not possible to set the netmask of the peer-address inside winbox, obviously a bug.

I have now the problem that no IP-traffic is passing the connection. Seems to me that no phase 2 is established. remote-peer (phase 1) is established.

I am trying to use the connection in tunnel-mode, will this work? cause there is no policy on the VPN-server i guess it uses the default transport-mode.

Any example of a running IPSec-connection in tunnel-mode with dynamic IP-address on one side would be very helpful (of course i'll post mine if got to work;-)

My Scenario looks like:

{LAN1} - (R1) - static IP - {Internet} - dyn. IP - (R2) - {LAN2}

R1, R2: MT-ROS 2.9.13 Router, R1 is VPN-server, R2 VPN-client

Posted: **Sun Feb 26, 2006 1:24 pm**

Hm... was my description to confusing;-)
or is no one using IPSec with dynamic addresses actually?

(Its easily possible with many low-cost routers, so i won't believe it couldn't be done with MT.)

TIA.

Posted: **Sun Feb 26, 2006 10:29 pm**

Post your new IKE logs now you've fixed the original problem.

Regards

Andrew

Posted: **Mon Feb 27, 2006 8:24 am**

Scenario looks like:
{10.10.1/24} - (R1) - static IP - {Internet} - dyn. IP - (R2) - {192.168.255/24}

R1, R2: MT-ROS 2.9.14 Router, R1 is VPN-server, R2 VPN-client

configuration at remote site (static IP-address)

/ ip ipsec policy 
add src-address=192.168.255.0/24:any dst-address=10.10.1.0/24:any protocol=all action=encrypt level=require \
    ipsec-protocols=esp tunnel=yes sa-src-address=0.0.0.0 sa-dst-address=x.y.8.157 proposal=standard \
    manual-sa=none dont-fragment=clear disabled=no 
/ ip ipsec peer 
add address=x.y.8.157/32:500 secret="******" generate-policy=no exchange-mode=aggressive \
    send-initial-contact=yes proposal-check=obey hash-algorithm=sha1 enc-algorithm=aes-128 dh-group=modp1024 \
    lifetime=1d lifebytes=0 disabled=no

configuration at central site (dynamic IP-address)

/ ip ipsec peer 
add address=0.0.0.0/0:500 secret="******" generate-policy=yes exchange-mode=aggressive \
    send-initial-contact=no proposal-check=obey hash-algorithm=sha1 enc-algorithm=aes-128 dh-group=modp1024 \
    lifetime=1d lifebytes=0 disabled=no

log from remote router (initiating VPN):

07:12:40 ipsec,ike,info queuing SA request, phase 1 with peer 217.91.8.157 will be established first 
07:12:40 ipsec,ike,info initiating phase 1, starting mode Aggressive (local 192.168.255.3:500) (remote 
    unknown) 
07:12:40 ipsec,info ipsec packet discarded: src=192.168.255.3 dst=10.10.1.4 
07:12:41 ipsec,ike,info received ISAKMP packet from x.y.8.157:500, phase 1, Aggressive 
07:12:41 ipsec,ike,info ISAKMP SA established (local 192.168.255.3:500) (remote x.y.8.157:500) 
07:12:41 ipsec,info ipsec packet discarded: src=192.168.255.3 dst=10.10.1.4 
07:12:42 ipsec,info ipsec packet discarded: src=192.168.255.3 dst=10.10.1.4 
07:12:43 ipsec,info ipsec packet discarded: src=192.168.255.3 dst=10.10.1.4
07:13:11 ipsec,ike,info dequeuing SA request to x.y.8.157, phase 1 wait timed out

log from central router:

07:12:40 ipsec,ike,info received ISAKMP packet from 80.131.198.24:500, phase 1, Aggressive 
07:12:40 ipsec,ike,info responding phase 1, starting mode Aggressive (local x.y.8.157:500) 
    (remote80.131.198.24:500) 
07:12:41 ipsec,ike,info received ISAKMP packet from 80.131.198.24:500, phase 1, Aggressive 
07:12:41 ipsec,ike,info ISAKMP SA established (local x.y.8.157:500) (remote 80.131.198.24:500)

remote peers are established, but no installed SA.

Posted: **Mon Feb 27, 2006 1:26 pm**

I don't think Aggressive mode is supported for this type of dial-in access. Try using Main mode instead. That's generally a safer option.

You might try changing the proposal-check from Obey to Strict. Not sure why this makes a difference but I saw LastGuru do this at the MUM with a non-functioning VPN and it burst into life.

Regards

Andrew

Posted: **Tue Feb 28, 2006 11:03 am**

thanks for the hints, but still does not work. Same log entries.
I am a bit confused by the log-line:

10:03:57 ipsec,ike,info phase 1 negotiation timed out

on the client side. it looks to me as if the client did not get the right response even for phase 1.

Posted: **Tue Feb 28, 2006 7:26 pm**

This with main or aggressive mode?

It's possible that this is an MTU type problem and you're losing some of the IKE packets.

Regards

Andrew

Posted: **Wed Mar 01, 2006 12:42 pm**

i did both changes: exchange-mode=main and proposal-check=strict.

i am going to test the MTU-thing, but never had problems with it before.

thx.

Posted: **Mon Mar 06, 2006 1:00 am**

Hello Mag i have the same problem.

How did you resolve this problem?

Thankyou

Posted: **Mon Mar 06, 2006 9:49 am**

i didn't resolve it!

get static IP-addresses (which is always the best :) or use another router-system.

MikroTik

IPSec-VPN with dynamic IP

IPSec-VPN with dynamic IP

IPsec 2.9.14