Testing UDP works over a VPN via console?

Unanswered Question
Oct 9th, 2007

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?

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Richard Burts Tue, 10/09/2007 - 06:12


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?



whiteford Tue, 10/09/2007 - 06:24


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 any

and access-list 101 permit udp 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 Tue, 10/09/2007 - 06:16


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



Richard Burts Tue, 10/09/2007 - 06:45


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


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.



whiteford Tue, 10/09/2007 - 06:52

Here is some of it:

crypto isakmp policy 1

encr 3des

hash md5

authentication pre-share

group 2

crypto isakmp key ******* address



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


crypto map vo_t_set 10 ipsec-isakmp

set peer

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 [email protected]

ppp chap password 0 *****

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

crypto map vo_t_set

ip route 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 any eq telnet

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

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

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

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

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

permit ip

access-list 101 permit ip any

dialer-list 1 protocol ip permit

Richard Burts Tue, 10/09/2007 - 07:13


As long as the Netflow packet has a source address in subnet 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?



whiteford Tue, 10/09/2007 - 07:28

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

this is what i have added:



router#configure terminal

router(config)#interface Ethernet 0

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


router(config)#ip flow-export destination 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#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 (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 Tue, 10/09/2007 - 07:45


Just to verify something: is the interface Ethernet 0 in subnet

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



whiteford Tue, 10/09/2007 - 07:50

Ethernet 0 is

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 Tue, 10/09/2007 - 08:50


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?



whiteford Tue, 10/09/2007 - 09:05

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 Tue, 10/09/2007 - 09:19


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



whiteford Tue, 10/09/2007 - 11:06

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 Tue, 10/09/2007 - 11:12

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.

Richard Burts Tue, 10/09/2007 - 11:23


I am encouraged that some data has shown up on the NetFlow website.

I would suggest that it might not be a bad idea to start another thread on the forum asking if anyone has experience (or has suggestions) with running NetFlow over VPN.



whiteford Tue, 10/09/2007 - 11:27

Will do, I'm not sure which interface to really monitor. I have an Ethernet cable from one of the four LAN ports on the back of the Cisco 837 into a 24 port switch. I have Ethernet 0 which assume is live a VLAN across the four ports being monitored. Not sure if it should be this or ATM 0 or dialer 1?

whiteford Wed, 10/10/2007 - 01:17


I ran up an 1841 ADSL in a VPN mode, and had the same issues. So I installed the Netflow application onto a laptop on the side of the VPN, and it all instantly worked. So it must be a VPN issue.

Shame about this, are there other tools I could test. Then again I could install the free version (2 interfaces) on a PC at every site.

Richard Burts Wed, 10/10/2007 - 09:50


Thanks for confirming your additional testing and it looks like it is a bug with NetFlow over VPN. I would hope that Cisco would address this and provide a fix but I have no idea how long we will wait to see this.



whiteford Wed, 10/10/2007 - 09:57

That's true.

What a Cisco pro like you do to check who's doing what over a VPN when things go slow on the bandwidth? Just those console ip flow and cache export commands?


This Discussion