Community discussions

MUM Europe 2020
 
User avatar
mag
Member
Member
Topic Author
Posts: 378
Joined: Thu Jul 01, 2004 12:32 pm
Location: Cologne, NRW, Germany
Contact:

IPSec-VPN with dynamic IP

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.
 
User avatar
andrewluck
Forum Veteran
Forum Veteran
Posts: 702
Joined: Fri May 28, 2004 9:05 pm
Location: Norfolk, UK

Fri Feb 24, 2006 8:36 pm

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

Regards

Andrew
 
User avatar
mag
Member
Member
Topic Author
Posts: 378
Joined: Thu Jul 01, 2004 12:32 pm
Location: Cologne, NRW, Germany
Contact:

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
 
User avatar
mag
Member
Member
Topic Author
Posts: 378
Joined: Thu Jul 01, 2004 12:32 pm
Location: Cologne, NRW, Germany
Contact:

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.
 
User avatar
andrewluck
Forum Veteran
Forum Veteran
Posts: 702
Joined: Fri May 28, 2004 9:05 pm
Location: Norfolk, UK

Sun Feb 26, 2006 10:29 pm

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

Regards

Andrew
 
User avatar
mag
Member
Member
Topic Author
Posts: 378
Joined: Thu Jul 01, 2004 12:32 pm
Location: Cologne, NRW, Germany
Contact:

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.
 
User avatar
andrewluck
Forum Veteran
Forum Veteran
Posts: 702
Joined: Fri May 28, 2004 9:05 pm
Location: Norfolk, UK

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
 
User avatar
mag
Member
Member
Topic Author
Posts: 378
Joined: Thu Jul 01, 2004 12:32 pm
Location: Cologne, NRW, Germany
Contact:

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.
 
User avatar
andrewluck
Forum Veteran
Forum Veteran
Posts: 702
Joined: Fri May 28, 2004 9:05 pm
Location: Norfolk, UK

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
 
User avatar
mag
Member
Member
Topic Author
Posts: 378
Joined: Thu Jul 01, 2004 12:32 pm
Location: Cologne, NRW, Germany
Contact:

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.
 
viceft
just joined
Posts: 8
Joined: Wed Feb 02, 2005 2:18 am

IPsec 2.9.14

Mon Mar 06, 2006 1:00 am

Hello Mag i have the same problem.

How did you resolve this problem?

Thankyou
 
User avatar
mag
Member
Member
Topic Author
Posts: 378
Joined: Thu Jul 01, 2004 12:32 pm
Location: Cologne, NRW, Germany
Contact:

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.

Who is online

Users browsing this forum: faxxe, MSN [Bot] and 89 guests