VPN with Cisco 3550

| Thursday, April 15th, 2010 | 9 Comments »

If you have the EMI version of Cisco’s 3550 layer 3 switch, is it technically possible to use the 3550 as a VPN edge device? This post isn’t going to answer that question today, but it will show you my attempts at it, and perhaps, like the old saying goes, if you chip at a rock enough, it will eventually crack!
I’d also like to add that I have not found any documentation that shows the 3550 as supporting VPN’s. This is all for the purpose of curiosity. And for the potential to actually get something working that isn’t part of the networking status quo….

Above you see a quick diagram of this feat. Nothing special, just replacing what normally would be a VPN edge device with a L3 switch. Below are the configs for both the 1811 router and 3550 switch. Starting with the router first.

ROUTER 1811
crypto isakmp policy 10
hash md5
authentication pre-share
group 2
crypto isakmp key cisco address 10.1.0.2
!
!
crypto ipsec transform-set BRANDONVPN esp-des esp-md5-hmac
mode transport
!
crypto map S2S-VPN 10 ipsec-isakmp
set peer 10.1.0.2
set transform-set BRANDONVPN
set pfs group2
match address 101
!
!
!
interface FastEthernet0
ip address 10.1.0.1 255.255.0.0
duplex auto
speed auto
crypto map S2S-VPN
!
interface FastEthernet1
ip address 172.16.0.1 255.255.0.0
duplex auto
speed auto
!
<–LEFT OUT OTHER INTERFACES FOR BREVITY–>
!
interface Vlan1
no ip address
!
interface Async1
no ip address
encapsulation slip
!
ip forward-protocol nd
ip http server
ip http secure-server
!
!
ip route 0.0.0.0 0.0.0.0 10.1.0.2
ip route 192.168.3.0 255.255.255.0 10.1.0.2
!
access-list 101 permit ip 172.16.0.0 0.0.255.255 192.168.3.0 0.0.0.255
!
!
!

SWITCH 3550

!
no aaa new-model
ip subnet-zero
ip routing
no ip domain-lookup
ip name-server 4.2.2.2
!
!
!
vlan internal allocation policy ascending
!
!
crypto isakmp policy 10
hash md5
authentication pre-share
group 2
crypto isakmp key cisco address 10.1.0.1
!
!
crypto ipsec transform-set BRANDONVPN esp-des esp-md5-hmac
mode transport
!
crypto map S2S-VPN 10 ipsec-isakmp
set peer 10.1.0.1
set transform-set BRANDONVPN
set pfs group2
match address 101
!
!
!
interface FastEthernet0/1
no switchport
ip address 10.1.0.2 255.255.0.0
crypto map S2S-VPN
!
interface FastEthernet0/2
no switchport
ip address 192.168.3.1 255.255.255.0
!

—CUT OUT THE REST OF THE SWITCHPORTS FOR BREVITY—-

!
interface Vlan1
no ip address
!
ip default-gateway 10.1.0.1
ip classless
ip route 0.0.0.0 0.0.0.0 10.1.0.1
ip route 172.16.0.0 255.255.0.0 10.1.0.1
ip http server
ip http secure-server
!
!
access-list 101 permit ip 192.168.3.0 0.0.0.255 172.16.0.0 0.0.255.255
!

So what is the end result of these configs? Surprisingly, the IKE phase 1 tunnel does indeed come up! Here is the output from the show crypto isakmp sa command.

RTR-1811W#sh crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id status
10.1.0.2        10.1.0.1        QM_IDLE           2001 ACTIVE

What’s funny about this output is that when reading VPN documentation, they will use this output as an example of a SUCCESSFUL VPN configuration!…..NOT!

Unfortunately pings and any other kind of traffic do not traverse this VPN tunnel. The issue is not yet known as I’m still in the troubleshooting phase. No pun intended, but the phase in question at this point I believe is IKE Phase 2. The IPsec is what needs to be looked at IMO….

Below for your entertainment are some other SHOW output commands.

RTR-1811W#sh crypto map
Crypto Map “S2S-VPN” 10 ipsec-isakmp
Peer = 10.1.0.2
Extended IP access list 101
access-list 101 permit ip 172.16.0.0 0.0.255.255 192.168.3.0 0.0.0.255
Current peer: 10.1.0.2
Security association lifetime: 4608000 kilobytes/3600 seconds
Responder-Only (Y/N): N
PFS (Y/N): Y
DH group: group2
Transform sets={
BRANDONVPN: { esp-des esp-md5-hmac } ,
}
Interfaces using crypto map S2S-VPN:
FastEthernet0

SW-3550-24-B#sh crypto map
Crypto Map “S2S-VPN” 10 ipsec-isakmp
Peer = 10.1.0.1
Extended IP access list 101
access-list 101 permit ip -1062731008 255 -1408237568 65535
Current peer: 10.1.0.1
Security association lifetime: 4608000 kilobytes/3600 seconds
PFS (Y/N): Y
DH group: group2
Transform sets={
BRANDONVPN,
}
Interfaces using crypto map S2S-VPN:
FastEthernet0/1

Conclusion: This is a work in progress. If anyone has any ideas, please let me know your thoughts!

Share
  • Pingback: Tweets that mention BrandonTek » Blog Archive » VPN with Cisco 3550 -- Topsy.com()

  • http://profiles.yahoo.com/u/P4MH3SEVKCNJNT4QZYXNY3T2TM John

    What version L3 switch did you use?

  • Pingback: BrandonTek » Blog Archive » VPN with Cisco 3550 (update)()

  • zoltan

    hello!
    maybe a bit late, but did you figure out what the problem was? did you mange to get the vpn work? faceing the same problem,

  • brandontek

    Hi there,
    I was not able to get this set up properly. I believe at the end of the day, if Cisco wants you to be able to VPN to an L3 switch, they can easily make that happen, but my sense is they’ve defined what should be VPN capable, and that’s their routers.

    If you happen to get it working, please let me know!

  • zoltan

    hello! fisrt of all thanks for reply!

    i have the same topo just like you have here,wanting to setup, my question :is it not a sign that the ipsec is working as well, if under the `show crypto ipses sa` command we would be able too see encrypted and decrypted packets? in my lab i was able to reach ` to visualizes according to your totp you depicted here) till f0/0 on the c3550 from the remote side, so the inside interface of the c3550, and was able to ping from the c3550 to both the othersides pc`s ip and the inside of the 1811, so when i did on a c3550 a ping 172.16.0.1 and 172.16.0.2 souced with 192.168.3.1 it was successful, and as i mentiond saw the interested traffic got encrypted on the c3550 issuing the `show crypto ipsec sa` what i was not able is to ping form the c3550 hots to anywhere to the other side, and as i saw the traffic sourced form the pc at c 3550 the access-list did not even hit.

    again i am new to vpn`s what is your point of view?

    thanks

  • zoltan

    have no comment on may last message?
    ??? does it not have nothing to do with the access list at all?

  • brandontek

    Hi Zoltan,

    I don’t believe it’s an ACL issue. I believe Cisco purposely did not want anyone to create VPN tunnels with their 3550 switch. At the time I’ve tried many options myself with no luck. I think they’ve made sure it wouldn’t work 100%….

    =)

  • zoltan

    ok! i close the file and dump the c 3550 :)
    cheers