openvpn and packet sniffing

[Bill Fassler]

I'm working development of a VoIP project which is using openvpn on the server side. Debugging is very tricky because I can't see the RTP packets. Is there any mechanism or plugin for wireshark or ethereal that would allow me to see the RTP packets?

@Bill


---------------------------------
Have a burning question? Go to Yahoo! Answers and get answers from real people who know.

[Guy Harris]

Post by Bill Fassler
I'm working development of a VoIP project which is using openvpn on the
server side. Debugging is very tricky because I can't see the RTP
packets.

"Can't see" in what sense?

Post by Bill Fassler
Is there any mechanism or plugin for wireshark or ethereal
that would allow me to see the RTP packets?

If "can't see" means that the packets aren't in the capture, that's
probably an issue with whatever capture mechanism you're using, so it
can't be fixed at the Wireshark level.

If "can't see" means that the packets *are* in the capture but aren't
recognized by Wireshark as RTP packets, then try either

1) try turning the "try to decode RTP outside of conversations"
preference for RTP on (that causes RTP to try to guess what packets are
RTP packets - the problem is that there's no fixed port number used by
RTP, and no reliable signature to identify RTP packets, so it has to
guess, and it might guess wrong)

or

2) use the "Decode As" option to force the RTP packets to be decoded as
such.

[Bill Fassler]

Sorry I should have provided a better info. Anyway I do get a capture and I see only UDP traffic. I am sure the RTP and SIP traffic is within those packets. I thought of a perl script to possibly parse out what I want to see or writing another plugin, that gets to the RTP and then passes it off to the appropriate dissector. In any event, I don't want to reinvent the wheel and I'm sure someone has already jumped this hurdle. I will try your "decode as" suggestion. I think this might let me more easily see what I want although it soudns a little cumbersome.

@Bill

Post by Bill Fassler
I'm working development of a VoIP project which is using openvpn on the
server side. Debugging is very tricky because I can't see the RTP
packets.

"Can't see" in what sense?

Post by Bill Fassler
Is there any mechanism or plugin for wireshark or ethereal
that would allow me to see the RTP packets?

If "can't see" means that the packets aren't in the capture, that's
probably an issue with whatever capture mechanism you're using, so it
can't be fixed at the Wireshark level.

If "can't see" means that the packets *are* in the capture but aren't
recognized by Wireshark as RTP packets, then try either

1) try turning the "try to decode RTP outside of conversations"
preference for RTP on (that causes RTP to try to guess what packets are
RTP packets - the problem is that there's no fixed port number used by
RTP, and no reliable signature to identify RTP packets, so it has to
guess, and it might guess wrong)

or

2) use the "Decode As" option to force the RTP packets to be decoded as
such.
_______________________________________________
Wireshark-users mailing list
Wireshark-users-IZ8446WsY0/***@public.gmane.org
http://www.wireshark.org/mailman/listinfo/wireshark-users



---------------------------------
Need a quick answer? Get one in minutes from people who know. Ask your question on Yahoo! Answers.

[Guy Harris]

Post by Bill Fassler
Sorry I should have provided a better info. Anyway I do get a capture
and I see only UDP traffic. I am sure the RTP and SIP traffic is within
those packets.

I.e., this is "the packets *are* in the capture but aren't recognized by
Wireshark as RTP packets" case.

Post by Bill Fassler
I thought of a perl script to possibly parse out what I
want to see or writing another plugin, that gets to the RTP and then
passes it off to the appropriate dissector.

All such a plugin would do is detect RTP traffic and cause it to be
dissected as RTP; the way to do *that* is to have the RTP dissector do
that - which is what the "try turning the 'try to decode RTP outside of
conversations preference for RTP on" suggestion was for. If a plugin
could do a better job of detecting RTP traffic than the current RTP
dissector's heuristic, it shouldn't be done as a plugin dissector, it
should be done as a change to the RTP dissector. (If the heuristics are
strong enough - i.e., they won't identify a lot of non-RTP traffic as
being RTP - they could be turned on by default.)

Post by Bill Fassler
In any event, I don't want
to reinvent the wheel and I'm sure someone has already jumped this
hurdle. I will try your "decode as" suggestion. I think this might let
me more easily see what I want although it soudns a little cumbersome.

Why not try the other suggestion?

[Kukosa, Tomas]

I am affraid those UDP packets are OpenVPN packet, are not?
I.e. it would be necessary to implement OpenVPN (as I know it is not
implemented) and its decryption.


-----Original Message-----
From: wireshark-users-***@wireshark.org
[mailto:wireshark-users-***@wireshark.org] On Behalf Of Guy Harris
Sent: Tuesday, December 05, 2006 9:33 PM
To: Community support list for Wireshark
Subject: Re: [Wireshark-users] openvpn and packet sniffing

Post by Bill Fassler
Sorry I should have provided a better info. Anyway I do get a capture
and I see only UDP traffic. I am sure the RTP and SIP traffic is within
those packets.

I.e., this is "the packets *are* in the capture but aren't recognized by

Wireshark as RTP packets" case.

Post by Bill Fassler
I thought of a perl script to possibly parse out what I
want to see or writing another plugin, that gets to the RTP and then
passes it off to the appropriate dissector.

All such a plugin would do is detect RTP traffic and cause it to be
dissected as RTP; the way to do *that* is to have the RTP dissector do
that - which is what the "try turning the 'try to decode RTP outside of
conversations preference for RTP on" suggestion was for. If a plugin
could do a better job of detecting RTP traffic than the current RTP
dissector's heuristic, it shouldn't be done as a plugin dissector, it
should be done as a change to the RTP dissector. (If the heuristics are

strong enough - i.e., they won't identify a lot of non-RTP traffic as
being RTP - they could be turned on by default.)

Post by Bill Fassler
In any event, I don't want
to reinvent the wheel and I'm sure someone has already jumped this
hurdle. I will try your "decode as" suggestion. I think this might let
me more easily see what I want although it soudns a little cumbersome.

Why not try the other suggestion?
_______________________________________________
Wireshark-users mailing list
Wireshark-***@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-users

[Bill Fassler]

Yes the UDP packets are presumably OpenVPN packets which contain the RTP/SIP/SDP information embedded within. Decryption on the OpenVPN is currently not enabled to aid in debug. I understand that OpenVPN is suppose to provide additional privacy and security and that me trying to view the packets as the actual RTP/SIP and SDP traffic defeats part of the whole purpose of OpenVPN, however there are issues with our software that seem only to occur within the VPN tunnel or are more pronounced through OpenVPN so it is a necessary evil to try to tear OpenVPN packets apart for debug purposes.

I will be trying Guy Harris' suggestion later on today and hopefully that will be of help.

Bill

"Kukosa, Tomas" <tomas.kukosa-***@public.gmane.org> wrote:
I am affraid those UDP packets are OpenVPN packet, are not?
I.e. it would be necessary to implement OpenVPN (as I know it is not
implemented) and its decryption.


-----Original Message-----
From: wireshark-users-bounces-IZ8446WsY0/***@public.gmane.org
[mailto:wireshark-users-bounces-IZ8446WsY0/***@public.gmane.org] On Behalf Of Guy Harris
Sent: Tuesday, December 05, 2006 9:33 PM
To: Community support list for Wireshark
Subject: Re: [Wireshark-users] openvpn and packet sniffing

Sorry I should have provided a better info. Anyway I do get a capture
and I see only UDP traffic. I am sure the RTP and SIP traffic is

within

those packets.

I.e., this is "the packets *are* in the capture but aren't recognized by

Wireshark as RTP packets" case.

I thought of a perl script to possibly parse out what I
want to see or writing another plugin, that gets to the RTP and then
passes it off to the appropriate dissector.

All such a plugin would do is detect RTP traffic and cause it to be
dissected as RTP; the way to do *that* is to have the RTP dissector do
that - which is what the "try turning the 'try to decode RTP outside of
conversations preference for RTP on" suggestion was for. If a plugin
could do a better job of detecting RTP traffic than the current RTP
dissector's heuristic, it shouldn't be done as a plugin dissector, it
should be done as a change to the RTP dissector. (If the heuristics are

strong enough - i.e., they won't identify a lot of non-RTP traffic as
being RTP - they could be turned on by default.)

In any event, I don't want
to reinvent the wheel and I'm sure someone has already jumped this
hurdle. I will try your "decode as" suggestion. I think this might

let

me more easily see what I want although it soudns a little cumbersome.

Why not try the other suggestion?
_______________________________________________
Wireshark-users mailing list
Wireshark-users-IZ8446WsY0/***@public.gmane.org
http://www.wireshark.org/mailman/listinfo/wireshark-users
_______________________________________________
Wireshark-users mailing list
Wireshark-users-IZ8446WsY0/***@public.gmane.org
http://www.wireshark.org/mailman/listinfo/wireshark-users



---------------------------------
Want to start your own business? Learn how on Yahoo! Small Business.

[Anders Broman (AL/EAB)]

Hi,
If you find the SIP packages and do decode as SIP probably wireshark will be able to find and
decode the RTP packages if the setup information in the SIP messages are found and decoded.
BR
Anders

________________________________

Från: wireshark-users-bounces-IZ8446WsY0/***@public.gmane.org genom Bill Fassler
Skickat: on 2006-12-06 17:05
Till: Community support list for Wireshark
Ämne: Re: [Wireshark-users] openvpn and packet sniffing


Yes the UDP packets are presumably OpenVPN packets which contain the RTP/SIP/SDP information embedded within. Decryption on the OpenVPN is currently not enabled to aid in debug. I understand that OpenVPN is suppose to provide additional privacy and security and that me trying to view the packets as the actual RTP/SIP and SDP traffic defeats part of the whole purpose of OpenVPN, however there are issues with our software that seem only to occur within the VPN tunnel or are more pronounced through OpenVPN so it is a necessary evil to try to tear OpenVPN packets apart for debug purposes.

I will be trying Guy Harris' suggestion later on today and hopefully that will be of help.

Bill

"Kukosa, Tomas" <tomas.kukosa-***@public.gmane.org> wrote:

I am affraid those UDP packets are OpenVPN packet, are not?
I.e. it would be necessary to implement OpenVPN (as I know it is not
implemented) and its decryption.


-----Original Message-----
From: wireshark-users-bounces-IZ8446WsY0/***@public.gmane.org
[mailto:wireshark-users-bounces-IZ8446WsY0/***@public.gmane.org] On Behalf Of Guy Harris
Sent: Tuesday, December 05, 2006 9:33 PM
To: Community support list for Wireshark
Subject: Re: [Wireshark-users] openvpn and packet sniffing

Sorry I should have provided a better info. Anyway I do get a capture
and I see only UDP traffic. I am sure the RTP and SIP traffic is

within

those packets.

I.e., this is "the packets *are* in the capture but aren't recognized by

Wireshark as RTP packets" case.

I thought of a perl script to possibly parse out what I
want to see or writing another plugin, that gets to the RTP and then
passes it off to the appropriate dissector.

All such a plugin would do is detect RTP traffic and cause it to be
dissected as RTP; the way to do *that* is to have the RTP dissector do
that - which is what the "try turning the 'try to decode RTP outside of
conversations preference for RTP on" suggestion was for. If a plugin
could do a better job of detecting RTP traffic than the current RTP
dissector's heuristic, it shouldn't be done as a plugin dissector, it
should be done as a change to the RTP dissector. (If the heuristics are

strong enough - i.e., they won't identify a lot of non-RTP traffic as
being RTP - they could be turned on by default.)

In any event, I don't want
to reinvent the wheel and I'm sure someone has already jumped this
hurdle. I will try your "decode as" suggestion. I think this might

let

me more easily see what I want although it soudns a little cumbersome.

Why not try the other suggestion?
_______________________________________________
Wireshark-users mailing list
Wireshark-users-IZ8446WsY0/***@public.gmane.org
http://www.wireshark.org/mailman/listinfo/wireshark-users
_______________________________________________
Wireshark-users mailing list
Wireshark-users-IZ8446WsY0/***@public.gmane.org
http://www.wireshark.org/mailman/listinfo/wireshark-users



________________________________

Want to start your own business? Learn how on Yahoo! Small Business. <http://us.rd.yahoo.com/evt=41244/*http://smallbusiness.yahoo.com/r-index>

[Bill Fassler]

I have tried both suggestions for me to view the RTP/SIP/SDP traffic contained in the UDP packets travelling through an OpenVPN tunnel. Neither worked for this reason: The payload of the UDP packets do indeed contain such traffic as RTP SIP etc as appropriate, but they are all preceeded by a tunneling protocol. In my case it appears to be PPP. I can not use "Decode as" because in the transport options PPP is not listed. This is unfortunate because obviously there are dissectors or plugins in the Wireshark software that will do the trick but I don't seem to have them available to dissect the protocol when it is in the payload instead of the link layer. I am trying to confirm that the protocol is indeed PPP. In the mean time is there anyway to add more options to the decode as within the transport layer?

Bill


---------------------------------
Check out the all-new Yahoo! Mail beta - Fire up a more powerful email and get things done faster.

[Bill Fassler]

Guy suggested I try turning this preference on (see below), but I couldn't easily find how to do this. Can someone tell me? I am using WireShark 0.99.3 (svn Rev 19011)

Thanks,
Bill

Sorry I should have provided a better info. Anyway I do get a capture
and I see only UDP traffic. I am sure the RTP and SIP traffic is within
those packets.

I.e., this is "the packets *are* in the capture but aren't recognized by
Wireshark as RTP packets" case.

I thought of a perl script to possibly parse out what I
want to see or writing another plugin, that gets to the RTP and then
passes it off to the appropriate dissector.

All such a plugin would do is detect RTP traffic and cause it to be
dissected as RTP; the way to do *that* is to have the RTP dissector do
that - which is what the "try turning the 'try to decode RTP outside of
conversations preference for RTP on" suggestion was for. If a plugin
could do a better job of detecting RTP traffic than the current RTP
dissector's heuristic, it shouldn't be done as a plugin dissector, it
should be done as a change to the RTP dissector. (If the heuristics are
strong enough - i.e., they won't identify a lot of non-RTP traffic as
being RTP - they could be turned on by default.)

In any event, I don't want
to reinvent the wheel and I'm sure someone has already jumped this
hurdle. I will try your "decode as" suggestion. I think this might let
me more easily see what I want although it soudns a little cumbersome.

Why not try the other suggestion?
_______________________________________________
Wireshark-users mailing list
Wireshark-users-IZ8446WsY0/***@public.gmane.org
http://www.wireshark.org/mailman/listinfo/wireshark-users



---------------------------------
Access over 1 million songs - Yahoo! Music Unlimited.

[Stephen Fisher]

Post by Bill Fassler
Guy suggested I try turning this preference on (see below), but I
couldn't easily find how to do this. Can someone tell me? I am using
WireShark 0.99.3 (svn Rev 19011)

Try going to Edit -> Preferences, then expand the Protocols list and go
to RTP. Check the option "Try to decode RTP outside of conversations"
and hit OK.


Steve

[Douglas Pratley]

I'm looking at a similar thing at the moment with a view to adding some
UI features allowing a more arbitrary selection of protocol in "decode
as", but anything I do will be a few weeks away.

If you're running 0.99.4 and you're happy to look at the code to work
out how the particular dissectors are working, and to write Lua macros,
then you might be able to do something by manipulating the dissector
tables using Lua.

Look at
http://wiki.wireshark.org/Lua
http://wiki.wireshark.org/Lua/Dissector

_If_ you can identify the protocol you want to direct the packets to
(PPP?), _and_ the one that you are directing from (UDP?) you might be
able to set UDP port <x> to dissect as PPP.

Failing that, if you can just add the PPP dissector to the underlying
protocol's heuristics table (if it has one), I think it will appear in
the "decode as" list.

This is all a bit vague because I have just started looking at this; it
may or may not work, and I don't know if it's the sort of hackery you're
looking for.


________________________________

From: wireshark-users-bounces-IZ8446WsY0/***@public.gmane.org
[mailto:wireshark-users-bounces-IZ8446WsY0/***@public.gmane.org] On Behalf Of Bill Fassler
Sent: 08 December 2006 22:58
To: Community support list for Wireshark
Subject: [Wireshark-users] openvpn and packet sniffing


I have tried both suggestions for me to view the RTP/SIP/SDP traffic
contained in the UDP packets travelling through an OpenVPN tunnel.
Neither worked for this reason: The payload of the UDP packets do indeed
contain such traffic as RTP SIP etc as appropriate, but they are all
preceeded by a tunneling protocol. In my case it appears to be PPP. I
can not use "Decode as" because in the transport options PPP is not
listed. This is unfortunate because obviously there are dissectors or
plugins in the Wireshark software that will do the trick but I don't
seem to have them available to dissect the protocol when it is in the
payload instead of the link layer. I am trying to confirm that the
protocol is indeed PPP. In the mean time is there anyway to add more
options to the decode as within the transport layer?

Bill


________________________________

Check out the all-new Yahoo! Mail beta
<http://us.rd.yahoo.com/evt=43257/*http://advision.webevents.yahoo.com/m
ailbeta> - Fire up a more powerful email and get things done faster.



This message should be regarded as confidential. If you have received this email in error please notify the sender and destroy it immediately.
Statements of intent shall only become binding when confirmed in hard copy by an authorised signatory. The contents of this email may relate to dealings with other companies within the Detica Group plc group of companies.

Detica Limited is registered in England under No: 1337451.

Registered offices: Surrey Research Park, Guildford, Surrey, GU2 7YP, England.

[Bill Fassler]

Thanks this may prove helpful. I am using 0.99.3 though, are the differences so profound that I should upgrade? (I would also have to build it myself since I've already written a plugin that I also use for another purpose).

I did notice upon further inspection that the traffic is "encapsulated" in other words after the initial UDP packet headers I have approximately 5 bytes of data and then it appears it may be IP and UDP header stuff again. I am still trying to figure it out but being "encapsulated" makes sense since it is a VPN tunnel. I thought it was PPP but now I am a not so sure.

I think I need a little further analysis before I can determine the appropriate approach, but thanks a lot for your input. I'm sure it will come in handy.

Regards,
Bill

Douglas Pratley <Douglas.pratley-3etTQGT7qQvQT0dZR+***@public.gmane.org> wrote: I'm looking at a similar thing at the moment with a view to adding some UI features allowing a more arbitrary selection of protocol in "decode as", but anything I do will be a few weeks away.

If you're running 0.99.4 and you're happy to look at the code to work out how the particular dissectors are working, and to write Lua macros, then you might be able to do something by manipulating the dissector tables using Lua.

Look at
http://wiki.wireshark.org/Lua
http://wiki.wireshark.org/Lua/Dissector

_If_ you can identify the protocol you want to direct the packets to (PPP?), _and_ the one that you are directing from (UDP?) you might be able to set UDP port <x> to dissect as PPP.

Failing that, if you can just add the PPP dissector to the underlying protocol's heuristics table (if it has one), I think it will appear in the "decode as" list.

This is all a bit vague because I have just started looking at this; it may or may not work, and I don't know if it's the sort of hackery you're looking for.



---------------------------------
From: wireshark-users-bounces-IZ8446WsY0/***@public.gmane.org [mailto:wireshark-users-bounces-IZ8446WsY0/***@public.gmane.org] On Behalf Of Bill Fassler
Sent: 08 December 2006 22:58
To: Community support list for Wireshark
Subject: [Wireshark-users] openvpn and packet sniffing



I have tried both suggestions for me to view the RTP/SIP/SDP traffic contained in the UDP packets travelling through an OpenVPN tunnel. Neither worked for this reason: The payload of the UDP packets do indeed contain such traffic as RTP SIP etc as appropriate, but they are all preceeded by a tunneling protocol. In my case it appears to be PPP. I can not use "Decode as" because in the transport options PPP is not listed. This is unfortunate because obviously there are dissectors or plugins in the Wireshark software that will do the trick but I don't seem to have them available to dissect the protocol when it is in the payload instead of the link layer. I am trying to confirm that the protocol is indeed PPP. In the mean time is there anyway to add more options to the decode as within the transport layer?

Bill


---------------------------------
Check out the all-new Yahoo! Mail beta - Fire up a more powerful email and get things done faster.


This message should be regarded as confidential. If you have received this email in error please notify the sender and destroy it immediately.
Statements of intent shall only become binding when confirmed in hard copy by an authorised signatory. The contents of this email may relate to dealings with other companies within the Detica Group plc group of companies.

Detica Limited is registered in England under No: 1337451.

Registered offices: Surrey Research Park, Guildford, Surrey, GU2 7YP, England.

_______________________________________________
Wireshark-users mailing list
Wireshark-users-IZ8446WsY0/***@public.gmane.org
http://www.wireshark.org/mailman/listinfo/wireshark-users



---------------------------------
Need a quick answer? Get one in minutes from people who know. Ask your question on Yahoo! Answers.