Hi Tim,

I had planned to do GRE/IPsec tunnels just from the standpoint of long term planning. As you are probably aware, just a vanilla IPsec tunnel will only support unicast traffic and I can foresee that there might be future requirements to pass routing updates and/or non-unicast traffic across the tunnels. For the time being though, 2 IPsec tunnels will be sufficient for current our requirements and I'd be satisfied with just getting 2 of those tunnels nailed up.

I would definitely be interested in seeing some examples of a 2811 to a PIX running(6.3)and a Pix running 7.2(1) if your willing to share. Most of my experience with VPNs is with MPLS VPNs in a carrier environment and not using PIXes and IPsec tunnels so your examples are very much appreciated since I have not touched too many PIXes in my day.

Thank you very much for your assistance.

-Jeff

Hi Jeff, i've attached the basic requirements to build a VPN on a router (between platforms its not really different).

The below builds a 3des vpn from a router to some other device (not overly important).

I sometimes use a nat inside statement to allow hosts to connect out to the net. Its not overly important unless u require this. That said the acl (111 in this case) defined for this should always deny the traffic you expect to run over the tunnel.

basically a similar acl permiting (110 in this case) the traffic be tunnel.

Study the below and ask any questions i think is the best way to go.

!

crypto isakmp policy 1

encr 3des

hash md5

authentication pre-share

group 2

crypto isakmp key youkeyhere address ip.of.remote.pix

!

!

crypto ipsec transform-set transform-set-name esp-3des esp-md5-hmac

!

crypto map crypto-map-name 10 ipsec-isakmp

set peer ip.of.remote.pix

set security-association lifetime kilobytes 460800

set transform-set transform-set-name

match address 110

!

!

!

!

interface FastEthernet1

ip nat outside

crypto map crypto-map-name

!

!

interface Vlan1

ip nat inside

!

ip nat inside source static list 111 interface Fastethernet1 overload

!

ip route 0.0.0.0 0.0.0.0 some.internet.gateway.address

!

!

access-list 110 permit ip source subnet destination subnet

access-list 110 permit ip source subnet destination subnet

access-list 111 deny ip source subnet destination subnet

access-list 111 deny ip source subnet destination subnet

access-list 111 permit ip source subnet

cheers

Jeff,

attached is working pix configuration.

My asa stuff is very fresh (i'll send a workinig copy through).

Have a look below and ask questions.

The pix and the router should be enough to get a working vpn going.

Your should simply only need to make sure the acls are exactly the same but reversed. otherwise the tunnel won't come up.

PIX Version 6.3(5)

interface ethernet0 100full

interface ethernet1 100full

nameif ethernet0 outside security0

nameif ethernet1 inside security100

access-list acl-nonat permit ip 192.168.10.0 255.255.255.0 192.168.20.0 255.255.255.0

access-list acl-nonat permit ip 192.168.10.0 255.255.255.0 192.168.25.0 255.255.255.0

access-list acl-nonat permit ip 192.168.10.0 255.255.255.0 192.168.30.0 255.255.255.0

access-list acl-inside permit ip 192.168.10.0 255.255.255.0 192.168.20.0 255.255.255.0

access-list acl-inside permit ip 192.168.10.0 255.255.255.0 192.168.25.0 255.255.255.0

access-list acl-inside permit ip 192.168.10.0 255.255.255.0 192.168.30.0 255.255.255.0

access-list acl-remote-vpn permit ip 192.168.10.0 255.255.255.0 192.168.25.0 255.255.255.0

access-list acl-remote-vpn permit ip 192.168.10.0 255.255.255.0 192.168.20.0 255.255.255.0

access-list acl-remote-vpn permit ip 192.168.10.0 255.255.255.0 192.168.30.0 255.255.255.0

ip address outside x.x.x.x 255.255.255.0

ip address inside 192.168.10.5 255.255.255.0

global (outside) 1 interface

nat (inside) 0 access-list acl-nonat

nat (inside) 1 0.0.0.0 0.0.0.0 0 0

access-group acl-inside in interface inside

route outside 0.0.0.0 0.0.0.0 x.x.x.x 1

route inside 192.168.11.0 255.255.255.0 192.168.10.1 1

sysopt connection permit-ipsec

sysopt connection permit-pptp

sysopt connection permit-l2tp

crypto ipsec transform-set transform-set-name esp-3des esp-md5-hmac

crypto ipsec security-association lifetime seconds 3600

crypto map any-name 1 ipsec-isakmp

crypto map any-name 1 match address acl-remote-vpn

crypto map any-name 1 set peer ip.of.remote.peer

crypto map any-name 1 set transform-set transform-set-name

crypto map any-name 1 set security-association lifetime seconds 28800 kilobytes 4608000

crypto map any-name interface outside

isakmp enable outside

isakmp key you-key-here address ip.of.remote.peer netmask 255.255.255.255

isakmp identity address

isakmp policy 10 authentication pre-share

isakmp policy 10 encryption 3des

isakmp policy 10 hash md5

isakmp policy 10 group 2

isakmp policy 10 lifetime 86400

Hi Jeff.

As stated earlier, the ASA's or PIX version 7 (they appear the same) i've had limited experiece with.

That said a quick glance appears to indicate the the bulk of the configuration for the vpn is the same.

The isakmp key myk3y! address x.x.x.x netmask x.x.x.x is replaced with

tunnel-group x.x.x.x type ipsec-l2l

tunnel-group x.x.x.x ipsec-attributes

pre-shared-key *

That appears to be all.

there are policy groups and so forth which can be configured independantly but these are irrelevant to the configuration supplied (overall anyway)

T

Not having much luck with getting a working tunnel to my 515e running 7.x.

Let me know if I've buggered the 2811 router side and I am missing something, but what I really need to know is what the PIX side should look like in its entirety. Every example I have used or tried doesn't work and/or the PIX side says something about the crypto not being complete.

! ROUTER SIDE OF TUNNEL

!

crypto isakmp policy 1

encr 3des

hash md5

authentication pre-share

group 2

crypto isakmp key MYsecret address x.x.x.x

!

crypto ipsec transform-set MY-transform-set esp-3des esp-md5-hmac

!

crypto map MY-tunnel-515e 10 ipsec-isakmp

set peer x.x.x.x

set transform-set MY-transform-set

match address 115

!

interface Dialer1

crypto map MY-tunnel-515e

! (address y.y.y.y/32 assigned at PPP authentication, NOT DHCP, far as I know its not changing)

!

!

access-list 115 permit ip x.x.x.x 0.0.0.31 host y.y.y.y

access-list 115 permit ip host y.y.y.y x.x.x.x 0.0.0.31

!

! Should my above ACL perhaps just be host to host? On the PIX side the outside interface is using a .224 netmask.

Thanks for any and all help.

PS - on another note, does anyone know how the routes are getting set by the PIX when PPTP client connects? I have another issue where I get a Class A route injected into the client table and I'd like it to be a Class B route. Can't figure out how to fix it and this.

Can you please show us your pix configuration.

Tim,

Thanks again for the eyes. Here is the last combo I've tried, but getting close to going and investing in a PIX book. I'd think a static to static VPN should be pretty easy but perhaps I've beat this to a pulp so much I am overlooking the obvious in terms of errors.

PIX

####

access-list 110 remark CRYPTO-list for VPN-office-tunnel-Serial

access-list 110 extended permit ip host OUTSIDE-PIX-ADDRESS host SERIAL-ADDRESS-2811

access-list 110 extended permit ip host SERIAL-ADDRESS-2811 host OUTSIDE-PIX-ADDRESS

crypto ipsec transform-set MY-transform-set esp-3des esp-md5-hmac

crypto map MY-tunnel-2811 10 match address 110

crypto map MY-tunnel-2811 10 set peer SERIAL-ADDRESS-2811

crypto map MY-tunnel-2811 10 set transform-set MY-transform-set

crypto isakmp enable OUTSIDE

crypto map MY-tunnel-2811 interface OUTSIDE

crypto isakmp policy 1

authentication pre-share

encryption 3des

hash md5

group 2

lifetime 86400

tunnel-group SERIAL-ADDRESS-2811 type ipsec-l2l

tunnel-group SERIAL-ADDRESS-2811 ipsec-attributes

pre-shared-key *

ROUTER

#######

access-list 110 remark CRYPTO-list for VPN-office-tunnel-Serial

access-list 110 extended permit ip host SERIAL-ADDRESS-2811 host OUTSIDE-PIX-ADDRESS

access-list 110 extended permit ip host OUTSIDE-PIX-ADDRESS host SERIAL-ADDRESS-2811

crypto isakmp policy 1

encr 3des

hash md5

authentication pre-share

group 2

crypto isakmp key * address OUTSIDE-PIX-ADDRESS

!

crypto ipsec transform-set MY-transform-set esp-3des esp-md5-hmac

!

!

crypto map MY-tunnel-515e 10 ipsec-isakmp

set peer OUTSIDE-PIX-ADDRESS

set transform-set MY-transform-set

match address 110

interface Serial0/0/0:0

crypto map MY-tunnel-515e

How and where are you initiating traffic to bring up the tunnel? The only thing you have defined as interesting traffic in acl 110 is between the outside interfaces of the two endpoints. Don't you want the internal networks to be able to cross the tunnel?

Also, there is no need for this on the pix and the mirrored statement on the router.

access-list 110 extended permit ip host SERIAL-ADDRESS-2811 host OUTSIDE-PIX-ADDRESS

This traffic would never match coming from the pix.

Can you tell I have zero experience with PIX/VPN tunnels, hence the oversight? I was thinking -- key's match and form the tunnel. Evidently not the way it works. :-)

I'm willing to bet as soon as I add some more things to that tunnel ACL it will come up.

So that would be my next question so I don't beat my head against a rock any further....

If I have 10.11.10.0/24 and 10.12.10.0/24 on the router side, and 10.10.0.0/16 on the PIX side and I don't want to do any nat'ing over the tunnel and get it to form, what should that look like in an ACL.... something like this or will I also need to include the private net to private net stanzas as well?

Tad confusing for me since I am very green on VPN tunnel technology so appreciate all the help thus far.

access-list 110 remark CRYPTO-list for VPN-office-tunnel-Serial

access-list 110 extended permit ip host OUTSIDE-PIX-ADDRESS host SERIAL-ADDRESS-2811

access-list 110 extended permit ip host SERIAL-ADDRESS-2811 host OUTSIDE-PIX-ADDRESS

access-list 110 extended permit ip 10.10.0.0 0.0.255.255 host SERIAL-ADDRESS-2811

access-list 110 extended permit ip host SERIAL-ADDRESS-2811 10.10.0.0 0.0.255.255

access-list 110 extended permit ip 10.10.0.0 0.0.255.255 host OUTSIDE-PIX-ADDRESS

access-list 110 extended permit ip host OUTSIDE-PIX-ADDRESS 10.10.0.0 0.0.255.255

Actually you don't need any of those. The traffic traversing the tunnel will be between the inside networks. You do not need to define the peer addresses as interesting traffic. Notice the acl's are mirrors of eachother, this is very important.

PIX

access-list 110 extended permit ip 10.10.0.0 255.255.0.0 10.11.10.0 255.255.255.0

access-list 110 extended permit ip 10.10.0.0 255.255.0.0 10.12.10.0 255.255.255.0

ROUTER

access-list 110 extended permit 10.11.10.0 255.255.255.0 10.10.0.0 255.255.0.0

access-list 110 extended permit 10.12.10.0 255.255.255.0 10.10.0.0 255.255.0.0

You also have to add nat exemption on the pix and router.

PIX

access-list nonat extended permit ip 10.10.0.0 255.255.0.0 10.11.10.0 255.255.255.0

access-list nonat extended permit ip 10.10.0.0 255.255.0.0 10.12.10.0 255.255.255.0

nat (inside) 0 access-list nonat

ROUTER

I'm not much of a router guy I would have to go look it up.

edit: Check tim's post above. Look at access-list 111 and the ip nat inside command.

Please rate helpful posts.

let us know how you go.

Willing to give it a once over again if you wish.

tim

Didn't work. Syntax was wrong in the router statements acomsky (I believe) provided. There is not an ability to use 'extended' and the masks are reverse masks.

To make a long story short, everyone seems to have an idea but none thus far have been working ones.

I managed to pass a few IKE SA accepts in/out when I had my public interfaces in the ACL, jut never got a tunnel. With the latest info provided now I am not even doing that

No offense and appreciate the help, but I'm buying a book since we don't have TAC support on product. I'm already behind with this little project so I think I will humble myself with a decent book on the topic.

I ended up getting this working fine about 2.5 weeks ago. The following things seem to have been a bulk of the issue.

1- order of stanzas: you'd better have them in the same order for both the PIX and router, and follow a logical progression based on how a tunnel is negotiated. This is especially important for isakmp policy. Also, if a parameter defaults and shows up in the config on one side you'd better have it set to the same value on the other side. The PIX seemed to like to set its own default lifetime value.

2- ACLs for NATing/CRYPTO: Many examples I saw during the course of trying to get this to work were in fact 80-90% correct, but not entirely correct.

NAT- deny source_lan_subnet remote_vpn_lan_subnet (don't nat me), permit source_lan_subnet to_anything_else (nat me)

CRYPTO- source_tunnel_int remote_tunnel_int, and source_lan_subnet remote_vpn_lan_subnet should both be in it. In short, encrypt the tunnel and encrypt the traffic in the tunnel.

In the end, looking at ACL matches is what ended up helping me get the job done, along with reading snips from this board, and reading a few snips from some books.

On CCO, there could stand to be a few better examples of router to PIX setups that don't skimp on details in any given area. All of the white papers weren't quite there for a static pix to static router setup.... which because a little more difficult when you're already dealing with a PIX with config on it you can't erase.

Thanks one and all for the assistance.