Netflow + Ipsec

[drobel]

Hello!

I have 2 routers with pre shered key encryption between them - if the packet matches an extended acl.

One of the routers (2621XM) sends netflow packet to a server behind the other router (7206). These packets have source and destination Ip addresses which are permitted the mentioned acl.

Unfortunately the netflow packet are not encrypted! Other packets from clients (PCs) and even syslog messages from the router with the same source address get encrypted.

The IOS in the 2621XM:

c2600-advipservicesk9-mz.123-14.T2.bin

Do anyone know how can I encrypt the netflow data?

Kind regers,

[Richard Burts]

Perhaps if you post the configs we can find the issue.

HTH

Rick

[drobel]

crypto isakmp policy 1

encr aes

authentication pre-share

group 2

lifetime 43200

crypto isakmp key ****** address 10.102.0.0 255.255.0.0

!

!

crypto ipsec transform-set set1 esp-aes esp-sha-hmac

!

crypto map toKozpont 1 ipsec-isakmp

set peer Peer1_address

set peer Peer2_address

set transform-set set1

set pfs group2

match address Fiok2Kozp

qos pre-classify

interface Loopback0

description ---== Admin Interface ==---

ip address 10.102.255.98 255.255.255.255

interface Multilink1

bandwidth 512

ip address 10.102.3.121 255.255.255.248

ip route-cache flow

ip tcp header-compression iphc-format

no ip mroute-cache

load-interval 30

ppp multilink

ppp multilink fragment delay 20

ppp multilink interleave

ppp multilink group 1

crypto map toKozpont

service-policy output WAN512_QoS

ip rtp header-compression iphc-format

interface Serial0/0

bandwidth 512

no ip address

encapsulation ppp

no ip mroute-cache

load-interval 30

no fair-queue

ppp multilink

ppp multilink group 1

ip flow-export source Loopback0

ip flow-export version 5 peer-as

ip flow-export destination 10.222.242.70 555

ip access-list extended Fiok2Kozp

permit ip 10.102.0.0 0.0.255.255 10.222.240.0 0.0.7.255

permit ip 10.102.0.0 0.0.255.255 10.222.248.0 0.0.3.255

permit ip 10.102.0.0 0.0.255.255 10.222.8.0 0.0.3.255

logging source-interface Loopback0

logging 10.222.244.124

The other side uses the same crypto settings.

Thanks,

Bela

[Richard Burts]

Bela

Thanks for posting the config information. I have looked at it and do not yet see a problem. If you do an extended ping in which you specify the destination of 10.222.242.70 (the NetFlow destination) and specify the source of 10.102.255.98 (the loopback of the router) does that traffic get encrypted?

It might also be helpful if you would post the output of extended trace in which you specify the destination of 10.222.242.70 (the NetFlow destination) and specify the source of 10.102.255.98 (the loopback of the router). This will verify whether the data is using the expected path.

HTH

Rick

[drobel]

I tried the extended ping. Yes it gets encrypted, just like syslog messages.

deb ip packet 150 detail said that, the packet is using the correct output interface (Multilink1).

The netflow destination runs jffnms, and can communicate with the router with snmp, icmp also. Only the netflow packets can "dodge" the crypto.

Kind regards,

Bela

[Richard Burts]

Bela

I do not understand how the extended ping does get encrypted but the NetFlow does not. Based on the crypto map and the access list used to select traffic it seems to me that NetFlow should be encrypted. One thought that occurs to me is to ask you to do the extended ping again specifying destination as the NetFlow destination, specifying the source as the NetFlow source, and specifying packet size as maximum size.

I also wonder about the QOS. I see this on the multilink interface:

service-policy output WAN512_QoS

and wonder what that is doing. Perhaps you can post that part of the config.

HTH

Rick

[drobel]

Hello!

Extended ping success - I tried first time with these settings. It works.

QoS is very simlpe. A tipical voice qos. 8 kbit priority for signaling, 64 kbit for voice data, the rest have fai-queue and random detect. The class match is based on dscp ef and cs3.

Regards,

Bela