Testing UDP works over a VPN via console?

[whiteford]

From my Cisco 877 and 1841 with ADSL consoles, how can I test that a UDP port is able to reach a remote server over the VPN?

Is there a commadni can run?

[Richard Burts]

Andy

I am not clear whether you are asking to verify if UDP ports in general are able to reach the remote server or if you are interested in a specific port? If you are interested in UDP in general the easy way to test is to do traceroute on the router. The traceroute process on IOS routers sends UDP packets to the destination.

If you are interested in checking a particular UDP port then I am not sure that there is a good way to do that on the router. Are you asking in general or is there a particular connectivity problem that you are working with?

HTH

Rick

[whiteford]

Hi,

yeah I can't workout whether a server on the remote site (This is a VPN) can receive UDP 9996 for Netflow. i need this UDP port to go from this Cisco router over the VPN to a server.

I have an access-list 101 permit ip 172.19.10.0 0.0.0.0 any

and access-list 101 permit udp 172.19.10.0 0.0.0.0 any

the match address is 101 and put on the crypto map.

From this site I can access all our servers form my laptop and everything.

[Danilo Dy]

Hi,

Edited my earlier post: What service in remote server running in UDP port? Syslog, DNS, what OS running in the server?

Regards,

Dandy

[Richard Burts]

Dandy

From other posts from Andy I am pretty sure that this is a Netflow collector and analysis service. Andy can you confirm that?

Andy

From the access list that you show part of I am pretty sure that UDP 9996 is going through the VPN tunnel. It might be helpful if you would post the config (or at least all of the parts that have to do with crypto and VPN.

HTH

Rick

[whiteford]

Here is some of it:

crypto isakmp policy 1

encr 3des

hash md5

authentication pre-share

group 2

crypto isakmp key ******* address 1.2.3.4

!

!

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

!

crypto map vo_t_set 10 ipsec-isakmp

set peer 1.2.3.4

set transform-set vo_t_set

match address 101

interface Dialer1

ip address negotiated

ip access-group inbound_acl in

no ip unreachables

encapsulation ppp

dialer pool 1

dialer-group 1

ppp authentication chap pap callin

ppp chap hostname *****@hg57.btclick.com

ppp chap password 0 *****

ppp pap sent-username ******hg57.btclick.com password 0 *****

crypto map vo_t_set

ip route 0.0.0.0 0.0.0.0 Dialer1

ip access-list extended inbound_acl

permit udp any any eq isakmp

permit esp any any

deny icmp any any timestamp-request

deny icmp any any timestamp-reply

permit icmp any any

permit udp any any eq ntp

permit tcp 81.171.156.1 0.0.0.31 any eq telnet

permit tcp 81.*.*.* 0.0.0.31 any eq 22

permit tcp 81.*.*.* 0.0.0.31 any eq ftp-data

permit tcp 81.*.*.* 0.0.0.31 any eq ftp

permit tcp 81.*.*.* 0.0.0.31 any eq www

permit tcp 81.*.*.* 0.0.0.31 any eq 443

permit ip 192.168.21.0 0.0.0.255 172.19.10.0 0.0.0.255

access-list 101 permit ip 172.19.10.0 0.0.0.255 any

dialer-list 1 protocol ip permit

[Richard Burts]

Andy

As long as the Netflow packet has a source address in subnet 172.19.10.0/24 then it sure looks like it would go through the VPN tunnel.

Does the server need configuration of its remote sources or does it just accept and process any traffic that it receives on UDP 9996?

HTH

Rick

[whiteford]

Netflow tell me any UDP traffic from 9996 will be processed upon arrival.

this is what i have added:

router#enable

Password:*****

router#configure terminal

router(config)#interface Ethernet 0

router(config-if)#ip route-cache flow

router(config-if)#exit

router(config)#ip flow-export destination 192.168.21.19 9996

router(config)#ip flow-export source Ethernet 0

routerconfig)#ip flow-export version 5

router(config)#ip flow-cache timeout active 1

router(config)#ip flow-cache timeout inactive 15

router(config)#snmp-server ifindex persist

router(config)#^Z

router#write

router#show ip flow export

router#show ip cache flow

this looks good too:

sh ip flow export

Flow export v5 is enabled for main cache

Exporting flows to 192.168.21.19 (9996)

Exporting using source interface Ethernet0

Version 5 flow records

353 flows exported in 69 udp datagrams

0 flows failed due to lack of export packet

3 export packets were sent up to process level

0 export packets were dropped due to no fib

0 export packets were dropped due to adjacency issues

0 export packets were dropped due to fragmentation failures

0 export packets were dropped due to encapsulation fixup failures

[Richard Burts]

Andy

Just to verify something: is the interface Ethernet 0 in subnet 172.19.10.0/24?

Would I be correct in assuming that other traffic is going through the VPN ok?

And would I be correct in assuming that a traceroute (or tracert) from a device connected on interface Ethernet 0 shows that it does go through the VPN and that the response from the device after the router is from the peer at 1.2.3.4?

HTH

Rick

[whiteford]

Ethernet 0 is 172.19.10.1

All users and traffic are working fine.

the last part I'm 99% sure your are correct, I'd have to test, but I route all traffic through the VPN.

I'm wondering if it's the router. I might test on an 1841 ADSl tomorrow.

[Richard Burts]

Andy

I would be surprised if it were the router - but it would not hurt to test with 1841 and see if it makes a difference.

I am wondering if it might be a packet size issue. Since you are sending the Netflow over the VPN tunnel the VPN will add extra header information to the packet. If the Netflow was already as large as the MTU adding the extra header info would make it too large. Do you know or can you find out what size the Netflow packets are that are sent from your router?

HTH

Rick

[whiteford]

I will try and find out, this the first time I've tried NetFlow. I just what a way to see how are networks are being used especially when a user is slowing a VPN link down.

I actually thought the router cached the data then sent it to the NetFlow server.

[Richard Burts]

Andy

It is true that the router does cache the NetFlow data for a bit and then sends it to the NetFlow server. If you want to see it you can use the command show ip cache flow. You will find that the flows on the router expire fairly quickly so you can not go very far back on the router. That is one of the advantages of the NetFlow server is that is maintains historical data. And you may find that interpreting the information about source and destination port is difficult since that information is presented in hex not decimal. But if you are mostly interested in understanding source addresses then looking on the router may be quite satisfactory.

I have done some searching and it looks like there are a couple of bugs that have been filed about problems sending NetFlow through VPN tunnels. You can take a look at these (assuming that you have the right privileges on CCO) CSCsk25481 and CSCef28662

HTH

Rick

[whiteford]

I wonder if anyone has got Netflow working over a VPN then? Are they saying is a bug or that it can't be done as it says no workaround?

At first I thought could the cache get cleared before it's sent?

Should I repost to see if anyone is using it over a VPN?

I'd love to get this working, unless there are other web tools I could use to see this data?

[whiteford]

Spooky! Just look at the Netflow website and there it is the router showing up. However not much data and the alert is saying it has only received one flow from the router in the last 10 minutes. Seems like something somehow is getting there, shame I am a novice to work out why.