help with C831 to C831 vpn

"A pre-shared key for address mask ###.###.###.### 255.255.255.255 already exists!"

the error repeats several times. I get this after configuring a simple server/remote vpn starrting from a default configuration.

Any help GREATLY appreciated.

--matt

Reply to
matt
Loading thread data ...

Hello Matt,

If you like I can assist you in setting up VPN links as long as you agree to switch to the CLI. I do VPN setup forwards and backward all day long. Below you can find an example:

### Apply the cryptomap to your Dialer (Outside) Interface: interface Dialer0 crypto map CRYPTOMAP

### Parameter definition for Phase 1: ### Due to the fact that 3DES and SHA are the default settings, ### there are not shown here after appling it to the router

crypto isakmp policy 1 encr 3des hash sha authentication pre-share group 2 lifetime 86400

### Definition of the pre-shared key and the remote VPN GW crypto isakmp key address

### Definition of the encryption for Phase 2 crypto ipsec transform-set 3DES-SHA esp-3des esp-sha-hmac

### Definition which traffic has to be encrypted ### ip access-list extended VPN-2-Boston permit ip host host permit ip host host

### Definition of the VPN Tunnel incl. transform set and ACL crypto map CRYPTOMAP 10 ipsec-isakmp set peer set transform-set 3DES-SHA match address VPN-2-Boston

Just remove the comments starting with ### and replace the Variables in < > with your own IP addresses before you apply the settings as shown above.

Should you have any questions, or require further information, please do not hesitate to ask.

Cheers,

Robert

Reply to
Robert Langdon

configured two psk's for one remote peer, like

crypto isakmp key ABCD address crypto isakmp key DEFG address

remove one. following the guide posted by robert it should work without any problems. of course, the configuration has to be done on both routers, with the acl's configured vice versa. i personally prefer configuring over cli, not graphical pseudo-automatism-interfaces.

you'll get this error each time, the isakmp-process starts. again, try typing via cli, then - after sucessfull configuraion - verify the commands easy-vpn sends to the router.

greetings \cd

Reply to
Draschl Clemens

Thanks Robert.. I'll give this a try now. I began testing with CLI before, was able to get a GRE tunnel up in my little test lab here, no encryption, and then got stuck with a routing problem. I thought the latest SDM would help, but i guess not, cause it seems to have introduced this key problem. looking at the running-config, there were not two defined. My 'going in' concern is that i don't know enough about IOS to deal with NAT properly. I understand that crypto happens in a particular order, so i need to except the traffic that i want to VPN .. but i'll have to dig up my notes on that.

If you do this stuff all day, then you might just be the answer to my prayers getting the crazy setup i'm looking for, or my ultimate end goal.

PC at home -- [Cisco831] bridged[DSL] ---- Internet ---- || work firewall || --work network --- [Cisco831] -- PC in the office.

I want NAT on both work and home, to keep some test machines protected at work, but the tricky part is that i'd like to route all work traffic into the work 831, and then turn it around back out into the work network. does that make sense?

But, I have to walk before i run, right!? ;)

I enjoy learning/challenging myself like this, but fully admit I'm in over my head and need help.

THANKS so much...

Reply to
matt

ok, you didn't mention NAt in you initial post. nat is a problem for ipsec. you got it, you have to exclude the ipsec-traffic from getting nat'ed.

e.g.

ip nat inside source list 110 interface overload

ip access-list 110 deny ip

ip access-list 110 permit ip any

regarding roberts post, you may replace the networks with host entries. of course, @home the is @work, and the other way round. if you don't exclude traffic from getting nat'ed, the packet flow inside the router would become somehow crappy. cisco's got some slides explaining the packet-flow. the packet's get nat'ed first, and - logically - the concerning access-list responsible for triggering on packets destined for encryption does not recognize them, 'cause the source-address is already the nat-address. what a pity...

yes, it make's sense. just one thing: is the work firewall a nat-device too? in any case make sure communication to c831 is allowed for: udp/500 and ip protocol 50 (not port 50, esp is protocol number 50)

maybe

formatting link
is the solution :-)

greetings \cd

Reply to
Draschl Clemens

funny you should point me to that article at cisco.. cause that is EXACTLY the one that i just implemented.. by hand with the CLI. it's virutually the same as what robert sent, except as you point out, it includes the nat stuff.

so.. here's where i am now.. basically exactly where i've been when using sdm....

the tunnel appears to be up.. takes a sec for it to set up once all the commands are in, and i trigger it i guess with a ping.

i am able to ping both ways.. from a PC to the other router... and home PC to work PC. (btw, right now these are both sitting on my desk. ;) in a little mini-test-lab.) BUT. the router's cannot ping. odd. but ping from home address space to work address space works. i cannot, however do much else. mstsc begins, but fails. i can net use a drive share, authenticate.. but cannot dir the network drive. thoughts?

in regards to your comment about the work firewall 500/UDP and IP50, these are already allowed for my _real_ ip's. i'm _TRYING_ to replace a Symantec FW/VPN hardware-to-hardware solution. i'm sorta wishing i didn't start this! ;)

THANKS for your help!

Reply to
matt

matt schrieb:

The routers can ping each other.

You'll want to try: "ping tag internal-ip-target-router source Ethernet 0"

ip tcp path-mtu-discovery

Your PC sends ip packets fitting for a MTU of 1492 byte. Only 1418 byte are fitting in 1492 after transforming into IPsec. If you block ICMP messages as often recommended, the connection seems to hang.

Reply to
Uli Link

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.