This filter put a little twist into my powers of reasoning but I finally figured it out.
In our example, a Cisco ASA 5510 is serving as a VPN concentrator to which we have built a LAN to LAN IPSEC Tunnel from a customer peer (192.168.103.41). Basically, a host on the customer end (192.168.48.130) transfers files over the NDM protocol (tcp/1364) to our server (10.122.52.12) and sometimes our server (10.122.52.12) has to do the same to their server.
Summary of traffic over the tunnel:
192.168.48.130 --> 10.122.52.12 (tcp/1364)
10.122.52.12 --> 192.168.48.130(tcp/1364)
Our aim is to build the VPN tunnel when traffic between the two servers is present but limit the traffic to just the NDM protocol.
Configuration Steps
1. First you want the VPN traffic to bypass the filter you have on the interface that the tunnel terminates because we don't want another filter for this traffic. In our case this is the 'untrust' interface. Use this command:
sysopt connection permit-vpn
2. Now define the encryption domain for the tunnel and the Phase 1 (ISAKMP) and Phase 2 (IPSEC) parameters. Whenever, the ASA 'sees' this traffic, it will start the process of bringing up the VPN tunnel.
access-list kis1-vpn-traffic line 1 extended permit ip host 10.122.52.12 host 192.168.48.130
crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac
crypto map untrust_map 10 match address kis1-vpn-traffic
crypto map untrust_map 10 set peer 192.168.103.41
crypto map untrust_map 10 set transform-set ESP-3DES-SHA
crypto map untrust_map 10 set security-association lifetime seconds 28800
crypto map untrust_map 10 set security-association lifetime kilobytes 4608000
crypto map untrust_map interface untrust
crypto isakmp identity address
crypto isakmp enable untrust
crypto isakmp policy 10
authentication pre-share
encryption 3des
hash sha
group 2
lifetime 86400
3. With code 7.x on, you need to define tunnel group parameters first before the IPSEC tunnel will establish. This is where you define the pre-shared key and the filter that acts on the traffic within this tunnel
access-list kis1-vpn-filter line 1 extended permit tcp host 192.168.48.130 eq 1364 host 10.122.52.12
access-list kis1-vpn-filter line 2 extended permit tcp host 192.168.48.130 host 10.122.52.12 eq 1364
group-policy kis1-group-policy internal
group-policy kis1-group-policy attributes
vpn-filter value kis1-vpn-filter
tunnel-group 192.168.103.41 type ipsec-l2l
tunnel-group 192.168.103.41 general-attributes
default-group-policy kis1-group-policy
tunnel-group 192.168.103.41 ipsec-attributes
pre-shared-key *
4. Now let's take a closer look at the filter 'kis1-vpn-filter'. It has the familiar format where in this case, the source address is the far end address (customer host), while the destination address is the local host (10.122.52.12). Line 2 is very logical - it is allowing their host (192.168.48.130) to send traffic to our host (10.122.52.12) on tcp/1364. Nothing wrong here.
The confusion arrives in Line 1. This line permits the local host to send traffic to their host on tcp/1364! So it appears that the filter does not act on the traffic leaving the local host to the remote host, but acts on the return traffic only. Without this you will not make a connection from your local host to the remote host. Seems easy now... :o)
Thursday, March 26, 2009
How to Configure RSPAN on Catalyst 6500 IOS Switches
In our example we have two Cat switches (SWa and SWb). We have a packet sniffer connected to SWa interface F5/15 and want to monitor all the traffic going in and out of interface F3/1 of SWb.
Steps
1. Both switches must be trunked together.
2. Create an RSPAN VLAN. Preferably on the switch with VTP in server mode. Pick a VLAN ID that it is not being used currently. eg 999. If you do not have VTP, just create the VLAN on both switches.
Router(config)# vlan 999
Router(config-vlan)#remote-span
3. Create an RSPAN source session on SWb. This is the traffic you want to capture. The session number can be any integer that's not being used for other sessions. All traffic (tx and rx by default) from F3/1 now gets copied onto VLAN 999
Router(config)# monitor session 2 source interface f3/1
Router(config)# monitor session 2 destination remote vlan 999
4. Create the RSPAN destination session on SWa.This session need not have the same session ID as the one on SWb.
Router(config)#monitor session 8 source remote vlan 999
Router(config)#monitor session 8 destination interface f5/15
5. And that's it! You can obviously expand to monitor source VLANs, multiple interfaces etc. The source session describe in step 3 works even if it is configured on the same switch as the destination session - but then it's technically not RSPAN!
6. Here's a network management tip. Have your packet sniffer connected permanently to an interface on the switch and set up that interface as the destination session. So whenever the need arises to monitor packets on any interface, vlan etc., all you've got to do is configure the source session. This way you will save loads of unnecessary time trying to figure out which interface your sniffer was plugged into! And, always remember to label the interfaces with the description command.
Steps
1. Both switches must be trunked together.
2. Create an RSPAN VLAN. Preferably on the switch with VTP in server mode. Pick a VLAN ID that it is not being used currently. eg 999. If you do not have VTP, just create the VLAN on both switches.
Router(config)# vlan 999
Router(config-vlan)#remote-span
3. Create an RSPAN source session on SWb. This is the traffic you want to capture. The session number can be any integer that's not being used for other sessions. All traffic (tx and rx by default) from F3/1 now gets copied onto VLAN 999
Router(config)# monitor session 2 source interface f3/1
Router(config)# monitor session 2 destination remote vlan 999
4. Create the RSPAN destination session on SWa.This session need not have the same session ID as the one on SWb.
Router(config)#monitor session 8 source remote vlan 999
Router(config)#monitor session 8 destination interface f5/15
5. And that's it! You can obviously expand to monitor source VLANs, multiple interfaces etc. The source session describe in step 3 works even if it is configured on the same switch as the destination session - but then it's technically not RSPAN!
6. Here's a network management tip. Have your packet sniffer connected permanently to an interface on the switch and set up that interface as the destination session. So whenever the need arises to monitor packets on any interface, vlan etc., all you've got to do is configure the source session. This way you will save loads of unnecessary time trying to figure out which interface your sniffer was plugged into! And, always remember to label the interfaces with the description command.
Subscribe to:
Posts (Atom)