Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Can you help interpret this wireshark tcpdump pcap output?
37 views
Skip to first unread message
JJ
Jan 4, 2016, 8:21:26 AM1/4/16
to
Can you help interpret this wireshark tcpdump pcap output?
BACKGROUND:
In a recent thread of hideous length, we devised a dnsleak test of:
a. Cause a single dns query event
b. Use tcpdump to capture the outbound & inbound dns query events
c. Prove the dns query stayed wholly inside the VPN tunnel
My question is *how* do I interpret the results below?
Do these results actually prove the dns outbound/inbound events
stayed within the VPN tunnel?
A. Cause a single dns query event
e.g., $ ping -c1 google.com
B. Use tcpdump to capture the outbound & inbound dns query events
e.g., sudo tcpdump -A port 53 -i tun0 -P out -w /tmp/tcpdump_outbound.pcap
e.g., sudo tcpdump -A port 53 -i tun0 -P in -w /tmp/tcpdump_inbound.pcap
C. Prove the dns query stayed wholly inside the VPN tunnel
e.g., $ wireshark /tmp/tcpdump_outbound.pcap
e.g., $ wireshark /tmp/tcpdump_inbound.pcap
RESULTS:
1. ovpn file: denmark_vpngate_188.114.139.47_tcp_1438.ovpn
2. resolv.conf file: nameserver 10.211.254.254, 8.8.8.8, 192.168.1.1
3. http://ipleak.net result: https://i.imgur.com/xeMKwbm.gif
4. dns query outward pcap file: https://i.imgur.com/E5n51dq.gif
5. dns query inward pcap file: https://i.imgur.com/VTsHUaT.gif
QUESTION:
Do these results actually prove the dns outbound/inbound events
stayed wholly within the VPN tunnel?
BACKGROUND:
In a recent thread of hideous length, we devised a dnsleak test of:
a. Cause a single dns query event
b. Use tcpdump to capture the outbound & inbound dns query events
c. Prove the dns query stayed wholly inside the VPN tunnel
My question is *how* do I interpret the results below?
Do these results actually prove the dns outbound/inbound events
stayed within the VPN tunnel?
A. Cause a single dns query event
e.g., $ ping -c1 google.com
B. Use tcpdump to capture the outbound & inbound dns query events
e.g., sudo tcpdump -A port 53 -i tun0 -P out -w /tmp/tcpdump_outbound.pcap
e.g., sudo tcpdump -A port 53 -i tun0 -P in -w /tmp/tcpdump_inbound.pcap
C. Prove the dns query stayed wholly inside the VPN tunnel
e.g., $ wireshark /tmp/tcpdump_outbound.pcap
e.g., $ wireshark /tmp/tcpdump_inbound.pcap
RESULTS:
1. ovpn file: denmark_vpngate_188.114.139.47_tcp_1438.ovpn
2. resolv.conf file: nameserver 10.211.254.254, 8.8.8.8, 192.168.1.1
3. http://ipleak.net result: https://i.imgur.com/xeMKwbm.gif
4. dns query outward pcap file: https://i.imgur.com/E5n51dq.gif
5. dns query inward pcap file: https://i.imgur.com/VTsHUaT.gif
QUESTION:
Do these results actually prove the dns outbound/inbound events
stayed wholly within the VPN tunnel?
William Unruh
Jan 4, 2016, 12:56:21 PM1/4/16
to
On 2016-01-04, JJ <jj4p...@vfemail.net> wrote:
> Can you help interpret this wireshark tcpdump pcap output?
>
> BACKGROUND:
> In a recent thread of hideous length, we devised a dnsleak test of:
> a. Cause a single dns query event
> b. Use tcpdump to capture the outbound & inbound dns query events
> c. Prove the dns query stayed wholly inside the VPN tunnel
>
> My question is *how* do I interpret the results below?
>
> Do these results actually prove the dns outbound/inbound events
> stayed within the VPN tunnel?
>
> A. Cause a single dns query event
> e.g., $ ping -c1 google.com
> B. Use tcpdump to capture the outbound & inbound dns query events
> e.g., sudo tcpdump -A port 53 -i tun0 -P out -w /tmp/tcpdump_outbound.pcap
> e.g., sudo tcpdump -A port 53 -i tun0 -P in -w /tmp/tcpdump_inbound.pcap
> C. Prove the dns query stayed wholly inside the VPN tunnel
> e.g., $ wireshark /tmp/tcpdump_outbound.pcap
> e.g., $ wireshark /tmp/tcpdump_inbound.pcap
>
> RESULTS:
> 1. ovpn file: denmark_vpngate_188.114.139.47_tcp_1438.ovpn
> 2. resolv.conf file: nameserver 10.211.254.254, 8.8.8.8, 192.168.1.1
That is an illegal resolv.conf line. It must be one IP address per
> Can you help interpret this wireshark tcpdump pcap output?
>
> BACKGROUND:
> In a recent thread of hideous length, we devised a dnsleak test of:
> a. Cause a single dns query event
> b. Use tcpdump to capture the outbound & inbound dns query events
> c. Prove the dns query stayed wholly inside the VPN tunnel
>
> My question is *how* do I interpret the results below?
>
> Do these results actually prove the dns outbound/inbound events
> stayed within the VPN tunnel?
>
> A. Cause a single dns query event
> e.g., $ ping -c1 google.com
> B. Use tcpdump to capture the outbound & inbound dns query events
> e.g., sudo tcpdump -A port 53 -i tun0 -P out -w /tmp/tcpdump_outbound.pcap
> e.g., sudo tcpdump -A port 53 -i tun0 -P in -w /tmp/tcpdump_inbound.pcap
> C. Prove the dns query stayed wholly inside the VPN tunnel
> e.g., $ wireshark /tmp/tcpdump_outbound.pcap
> e.g., $ wireshark /tmp/tcpdump_inbound.pcap
>
> RESULTS:
> 1. ovpn file: denmark_vpngate_188.114.139.47_tcp_1438.ovpn
> 2. resolv.conf file: nameserver 10.211.254.254, 8.8.8.8, 192.168.1.1
"nameserver" keyword. Not sure at all how yours would be interpreted.
And please, cut an paste outputs. Do not "interpret" what the line means
since you admint you have no idea what it means.
> 3. http://ipleak.net result: https://i.imgur.com/xeMKwbm.gif
> 4. dns query outward pcap file: https://i.imgur.com/E5n51dq.gif
> 5. dns query inward pcap file: https://i.imgur.com/VTsHUaT.gif
>
> QUESTION:
> Do these results actually prove the dns outbound/inbound events
> stayed wholly within the VPN tunnel?
would you do that if you want to force them inside.
And why separate the "out" and "in" ? One can see from the line which
they are, and your way makes it harder to figure out what belongs to
what.
And why not have the wla0 as well?
It would have been nicer had you put the few lines into this netnews
post so we do not have to go opening web pages as well.
Anyway, your post shows that queries were sent out on tun0 to 10.
They do not show that nothing was sent out on wlan0.
>
JJ
Jan 4, 2016, 1:47:33 PM1/4/16
to
William Unruh <un...@invalid.ca> wrote in message
n6ebj4$gst$1...@dont-email.me
> That is an illegal resolv.conf line. It must be one IP address per
> "nameserver" keyword. Not sure at all how yours would be interpreted.
Ah, my mistake for not being clear.
I was summarizing.
The actual resolv.conf (sans comments) when on VPN is automagically thus:
$ cat /etc/resolv.conf
nameserver 10.211.254.254
nameserver 8.8.8.8
nameserver 192.168.1.1
Then resolv.conf instantly reverts to just the last line above when off vpn.
It's pretty much perfect.
My main confusion is *where* the "10.211.254.254" and "8.8.8.8"
and "192.168.1.1 came from?
I didn't add them.
I *assume* the VPN server added them.
That's too bad because it doesn't give me a chance to set the nameservers.
> You have three nameservers two are in the tunnel one is outside. Why
> would you do that if you want to force them inside.
Nice observation!
I had not realized that would be a problem.
I didn't actually set the name servers.
All three happened automagically when I followed this setup procedure:
https://forum.vpn.ac/discussion/13/running-openvpn-in-linux-terminal-with-no-dns-leaks
> And why separate the "out" and "in" ? One can see from the line which
> they are, and your way makes it harder to figure out what belongs to
> what.
I don't know how to combine the out and in from a single tcpdump command.
Having never before used tcpdump or wireshark, I am an extreme novice.
> And why not have the wla0 as well?
Good question.
Bear in mind I'm a total novice at this.
I think I can specify the interface as "any" which should, I think,
capture all the packets.
$ sudo tcpdump -i any -w /tmp/tcpdump.pcap
n6ebj4$gst$1...@dont-email.me
> That is an illegal resolv.conf line. It must be one IP address per
> "nameserver" keyword. Not sure at all how yours would be interpreted.
I was summarizing.
The actual resolv.conf (sans comments) when on VPN is automagically thus:
$ cat /etc/resolv.conf
nameserver 10.211.254.254
nameserver 8.8.8.8
nameserver 192.168.1.1
Then resolv.conf instantly reverts to just the last line above when off vpn.
It's pretty much perfect.
My main confusion is *where* the "10.211.254.254" and "8.8.8.8"
and "192.168.1.1 came from?
I didn't add them.
I *assume* the VPN server added them.
That's too bad because it doesn't give me a chance to set the nameservers.
> You have three nameservers two are in the tunnel one is outside. Why
> would you do that if you want to force them inside.
I had not realized that would be a problem.
I didn't actually set the name servers.
All three happened automagically when I followed this setup procedure:
https://forum.vpn.ac/discussion/13/running-openvpn-in-linux-terminal-with-no-dns-leaks
> And why separate the "out" and "in" ? One can see from the line which
> they are, and your way makes it harder to figure out what belongs to
> what.
Having never before used tcpdump or wireshark, I am an extreme novice.
> And why not have the wla0 as well?
Bear in mind I'm a total novice at this.
I think I can specify the interface as "any" which should, I think,
capture all the packets.
$ sudo tcpdump -i any -w /tmp/tcpdump.pcap
William Unruh
Jan 4, 2016, 5:15:33 PM1/4/16
to
On 2016-01-04, JJ <jj4p...@vfemail.net> wrote:
> William Unruh <un...@invalid.ca> wrote in message
> n6ebj4$gst$1...@dont-email.me
>
>> That is an illegal resolv.conf line. It must be one IP address per
>> "nameserver" keyword. Not sure at all how yours would be interpreted.
>
> Ah, my mistake for not being clear.
> I was summarizing.
>
> The actual resolv.conf (sans comments) when on VPN is automagically thus:
> $ cat /etc/resolv.conf
> nameserver 10.211.254.254
> nameserver 8.8.8.8
> nameserver 192.168.1.1
>
> Then resolv.conf instantly reverts to just the last line above when off vpn.
> It's pretty much perfect.
>
> My main confusion is *where* the "10.211.254.254" and "8.8.8.8"
> and "192.168.1.1 came from?
>
> I didn't add them.
>
> I *assume* the VPN server added them.
> That's too bad because it doesn't give me a chance to set the nameservers.
Teh 192.168.1.1 probably came from the dhcp server when you connected to
> n6ebj4$gst$1...@dont-email.me
>
>> That is an illegal resolv.conf line. It must be one IP address per
>> "nameserver" keyword. Not sure at all how yours would be interpreted.
>
> Ah, my mistake for not being clear.
> I was summarizing.
>
> The actual resolv.conf (sans comments) when on VPN is automagically thus:
> $ cat /etc/resolv.conf
> nameserver 10.211.254.254
> nameserver 8.8.8.8
> nameserver 192.168.1.1
>
> Then resolv.conf instantly reverts to just the last line above when off vpn.
> It's pretty much perfect.
>
> My main confusion is *where* the "10.211.254.254" and "8.8.8.8"
> and "192.168.1.1 came from?
>
> I didn't add them.
>
> I *assume* the VPN server added them.
> That's too bad because it doesn't give me a chance to set the nameservers.
your wifi. The 10.211.254.254 probably came from the vpn software. I
have no idea where the 8.8.8.8 came from.
>
>> You have three nameservers two are in the tunnel one is outside. Why
>> would you do that if you want to force them inside.
>
> Nice observation!
> I had not realized that would be a problem.
>
> I didn't actually set the name servers.
> All three happened automagically when I followed this setup procedure:
> https://forum.vpn.ac/discussion/13/running-openvpn-in-linux-terminal-with-no-dns-leaks
>
>> And why separate the "out" and "in" ? One can see from the line which
>> they are, and your way makes it harder to figure out what belongs to
>> what.
>
> I don't know how to combine the out and in from a single tcpdump command.
> Having never before used tcpdump or wireshark, I am an extreme novice.
would dump all packets on the wlan0 interface. Since that is what you
want to check, to make sure packets are NOT going out that interface,
that is probably the best to use.
Note that if you have lots of network activity while you are testing
this could produce a lot of output, and thus you could restrict things
(eg by port number).
man tcpdump
>
>> And why not have the wla0 as well?
>
> Good question.
> Bear in mind I'm a total novice at this.
>
> I think I can specify the interface as "any" which should, I think,
> capture all the packets.
> $ sudo tcpdump -i any -w /tmp/tcpdump.pcap
everythign would be captured.
JJ
Jan 4, 2016, 6:59:53 PM1/4/16
to
William Unruh <un...@invalid.ca> wrote in message
n6eqp5$dm6$2...@dont-email.me
> The 192.168.1.1 probably came from the dhcp server when you connected to
> your wifi. The 10.211.254.254 probably came from the vpn software. I
> have no idea where the 8.8.8.8 came from.
Thanks for postulating where the 3 resolv.conf entries came from:
> have no idea where the 8.8.8.8 came from.
nameserver 10.211.254.254
nameserver 8.8.8.8
nameserver 192.168.1.1
I don't know where they come from, but, the fact that I didn't set them,
nameserver 8.8.8.8
nameserver 192.168.1.1
probably means, as you noted, that the first two came from the VPN site.
Looking at the openvpn log messages for clues, I see three related
messages, which seem to indicate that you are correct where those
dns servers eminate from:
$ sudo openvpn --config "russia_vpngate_87.245.167.54_udp_64434.ovpn"
...
Mon Jan 4 13:48:35 2016
PUSH: Received control message: 'PUSH_REPLY,ping 3,ping-restart 10,
ifconfig 10.211.1.1 10.211.1.2,
dhcp-option DNS 10.211.254.254,
dhcp-option DNS 8.8.8.8,
route-gateway 10.211.1.2,
redirect-gateway def1'
...
Mon Jan 4 13:48:35 2016
ROUTE_GATEWAY 192.168.1.1/255.255.255.0 IFACE=wlan0 HWADDR=00:14:7a:34:af:94
...
Mon Jan 4 13:48:35 2016
/etc/openvpn/update-resolv-conf tun0 1500 1557 10.211.1.1 10.211.1.2 init
dhcp-option DNS 10.211.254.254
dhcp-option DNS 8.8.8.8
...
Mon Jan 4 15:18:16 2016 Initialization Sequence Completed
Notice a few things:
1. The VPN server seems to have 1st set "dhcp-option DNS 10.211.254.254".
2. The VPN server then seems to have 2nd set "dhcp-option DNS 8.8.8.8".
3. Only later, did the "ROUTE_GATEWAY" command set the 3rd line to 192.168.1.1.
Note: The MAC address reported is that of my laptop WiFi wlan0 NIC.
To find out more, I'll increase the 'verbose' option, to search for more clues:
$ grep ^verb "russia_vpngate_87.245.167.54_udp_64434.ovpn"
verb 3
> tcpdump -i wlan0
Since I had never even *thought* about testing VPN before I noticed the
dns leak, my problem isn't tactics, it's strategy, so the tcpdump manpage
is not as helpful as you might think it would be.
All those options are fine - but - I have to first have an idea of
*what* and *where* I'm looking for "things".
I'm so new at sniffing ports that I don't have a stable sense of what
it is that I'm looking for, and where I might sniff to find it.
Do you think I should sniff the specific port used by the tunnel?
$ grep ^remote russia_vpngate_87.245.167.54_udp_64434.ovpn
remote 87.245.167.54 64434
I don't know why VPN even needs a port, but I will look at port "64434"
to see if sniffing "it" tells me something useful:
$ sudo tcpdump -A port 64434 -i any -w /tmp/tcpdump_port64434.pcap
> Well, but that does not put the interfaces into promiscuous mode
I looked up this promiscuous mode stuff and it seems to be extremely
important, and, some cards "can" be put in promiscuous mode, while
others can't.
Being totally new to this, I'm still trying to figure out what my
"strategy" should be to test the vpn tunnel.
Having never thought about testing VPN leaks before, I only belatedly
realized that I might not have to prove that *all* the packets go
thru the tunnel, because maybe I could just concentrate on trying
to find any packets that do NOT go through the tunnel?
Does that sound like a reasonable VPN-testing strategy?
(How do people test VPNs for leaks anyway?)
[I can't be the first person to want to test a VPN for leaks.]
JJ
Jan 4, 2016, 9:58:59 PM1/4/16
to
JJ <jj4p...@vfemail.net> wrote in message n6f11m$cp2$1...@news.albasani.net
> Thanks for postulating where the 3 resolv.conf entries came from:
> nameserver 10.211.254.254
> nameserver 8.8.8.8
> nameserver 192.168.1.1
I just changed VPN providers and the result was a *different* set of
dns nameservers in the resolv.conf file:
nameserver 8.8.8.8
nameserver 8.8.4.4
nameserver 192.168.1.1
So, I'm pretty sure the nameservers are coming from the VPN provider.
> Thanks for postulating where the 3 resolv.conf entries came from:
> nameserver 10.211.254.254
> nameserver 8.8.8.8
> nameserver 192.168.1.1
dns nameservers in the resolv.conf file:
nameserver 8.8.8.8
nameserver 8.8.4.4
nameserver 192.168.1.1
So, I'm pretty sure the nameservers are coming from the VPN provider.
JJ
Jan 4, 2016, 10:34:31 PM1/4/16
to
Here is my first pass interpretation of this 6-packet ping session:
https://i.imgur.com/qWV89pI.jpg
Please correct where I make mistakes, but, I don't see the *response* from
the DNS request in the following quick test of just the tunnel!
TEST PROCEDURE:
STEP 1: $ sudo tcpdump -A -i tun0 -w /tmp/ping.pcap
STEP 2: $ ping -c1 adobe.com
STEP 3: $ wireshark /tmp/ping.pcap
TEST RESULTS: https://i.imgur.com/qWV89pI.jpg
1. 10.13.0.50 sent a dns request to 8.8.8.8 to resolve adobe.com
2. 10.13.0.50 apparently also sent a duplicate dns request to 8.8.4.4
?I don't see where the adobe.com address of 192.150.16.117 came back in the tunnel?
3. 10.13.0.50 then sent an ICMP request to 192.150.16.117
4. 192.150.16.117 sent an ICMP response back to 10.13.0.50
5. 10.13.0.50 sent an additional (slightly different) DNS request to 8.8.8.8
5. 10.13.0.50 sent another (slightly different) DNS request to 8.8.4.4
What's confusing is:
A. I had expected only one DNS server to be queried, but the dns query went to two servers.
# This is /etc/resolvconf/resolv.conf.d/tail
B. I had expected to see a response back from one of the DNS servers but I don't see the response.
C. I did not expect to see a slightly different duplicate set of queries to the DNS servers.
Note: My VPN-assigned IP address was 10.13.0.50
The resolv.conf contained these three lines:
https://i.imgur.com/qWV89pI.jpg
Please correct where I make mistakes, but, I don't see the *response* from
the DNS request in the following quick test of just the tunnel!
TEST PROCEDURE:
STEP 1: $ sudo tcpdump -A -i tun0 -w /tmp/ping.pcap
STEP 2: $ ping -c1 adobe.com
STEP 3: $ wireshark /tmp/ping.pcap
TEST RESULTS: https://i.imgur.com/qWV89pI.jpg
1. 10.13.0.50 sent a dns request to 8.8.8.8 to resolve adobe.com
2. 10.13.0.50 apparently also sent a duplicate dns request to 8.8.4.4
?I don't see where the adobe.com address of 192.150.16.117 came back in the tunnel?
3. 10.13.0.50 then sent an ICMP request to 192.150.16.117
4. 192.150.16.117 sent an ICMP response back to 10.13.0.50
5. 10.13.0.50 sent an additional (slightly different) DNS request to 8.8.8.8
5. 10.13.0.50 sent another (slightly different) DNS request to 8.8.4.4
What's confusing is:
A. I had expected only one DNS server to be queried, but the dns query went to two servers.
# This is /etc/resolvconf/resolv.conf.d/tail
B. I had expected to see a response back from one of the DNS servers but I don't see the response.
C. I did not expect to see a slightly different duplicate set of queries to the DNS servers.
Note: My VPN-assigned IP address was 10.13.0.50
The resolv.conf contained these three lines:
William Unruh
Jan 5, 2016, 1:13:39 AM1/5/16
to
resolvers mind you) but the last if from your own dhcp for your
wireless I am pretty sure.
JJ
Jan 5, 2016, 1:39:45 PM1/5/16
to
JJ <jj4p...@vfemail.net> wrote in message n6fdk5$h6s$1...@news.albasani.net
> Please correct where I make mistakes, but, I don't see the *response*
> from the DNS request in the following quick test of just the tunnel!
Running the test a few more times, I was able, with good technique, to
hone the dns query down to the 3 steps that I would assume it consists of.
https://i.imgur.com/bDAAiHb.jpg
A. I capture only tun0 packets: $ sudo tcpdump -i tun0 -w /tmp/tun0.pcap
B. I ping only once to a FQDN: $ ping -c1 apple.com
1. My IP 10.11.1.17 sends a dns request over tun0 to 10.211.254.254
2. The dns server 10.211.254.254 returns Apple IP 17.142.160.59 over dns
3. My IP 10.11.1.17 sends an ICMP packet to 17.142.160.50
Since I'm new to Wireshark and tcpdump, this is the first pcap capture
which has made complete sense to me (with respect to its logic sequence).
My goal is to see if *any* packets are being sent *outside* the tunnel.
> Please correct where I make mistakes, but, I don't see the *response*
> from the DNS request in the following quick test of just the tunnel!
hone the dns query down to the 3 steps that I would assume it consists of.
https://i.imgur.com/bDAAiHb.jpg
A. I capture only tun0 packets: $ sudo tcpdump -i tun0 -w /tmp/tun0.pcap
B. I ping only once to a FQDN: $ ping -c1 apple.com
1. My IP 10.11.1.17 sends a dns request over tun0 to 10.211.254.254
2. The dns server 10.211.254.254 returns Apple IP 17.142.160.59 over dns
3. My IP 10.11.1.17 sends an ICMP packet to 17.142.160.50
Since I'm new to Wireshark and tcpdump, this is the first pcap capture
which has made complete sense to me (with respect to its logic sequence).
My goal is to see if *any* packets are being sent *outside* the tunnel.
JJ
Jan 5, 2016, 1:50:50 PM1/5/16
to
William Unruh <un...@invalid.ca> wrote in message
n6fmph$tf1$1...@dont-email.me
> The first two probably are (Not sure why they would be using google's
> resolvers mind you) but the last if from your own dhcp for your
> wireless I am pretty sure.
fed to me by the VPN provider while the last nameserver maybe is being
'calculated' on my machine?
The fact the MAC address shows up in the openvpn log hints at some
calculation being performed:
Mon Jan 4 13:48:35 2016
ROUTE_GATEWAY 192.168.1.1/255.255.255.0
IFACE=wlan0 HWADDR=00:14:7a:34:af:94
I wonder if openvpn automatically runs an "arp" command to get this?
ROUTE_GATEWAY 192.168.1.1/255.255.255.0
IFACE=wlan0 HWADDR=00:14:7a:34:af:94
Marek Novotny
Jan 5, 2016, 2:03:19 PM1/5/16
to
On 2016-01-05, JJ <jj4p...@vfemail.net> wrote:
the actual DNS is:
#!/bin/bash
#################################################
#
# Script: vpntest.sh
# written by: Marek Novotny
# version: 1.2
# Date: 2015-04-19
# Notes: Network Testing
#
#################################################
let mtab=22
divider()
{
printf "%$(tput cols)s\n" "" | tr ' ' '='
}
versionHeader()
{
version='1.2'
versionDate='2015-04-19'
printf "%*s\n" "$(tput cols)" "$(date)"
printf "%*s\n" "$(tput cols)" "Version $version, released: $versionDate"
}
network()
{
printf "%s\n" "Network Info"
divider
deviceIP=$(ip route get 8.8.8.8 | awk 'NR==1 {print $7}')
deviceID=$(ip route get 8.8.8.8 | awk 'NR==1 {print $5}')
printf "%${mtab}s %s %s\n" "Device IP:" "$deviceIP" "($deviceID)"
defaultRoute=$(route | egrep -i default.*${deviceID} | awk '{print $2}')
printf "%${mtab}s %s\n" "Default Route:" "$defaultRoute"
which wget &> /dev/null
if (($? == 0)) ; then
externalIP=$(wget -4 -qO- icanhazip.com)
printf "%${mtab}s %s\n" "External IP:" "$externalIP"
else
externalIP="Not Detected"
printf "%${mtab}s %s\n" "External IP:" "$externalIP"
return 1
exit 1
fi
isp=$(wget -4 -qO- ipinfo.io/$externalIP/org)
country=$(wget -4 -qO- ipinfo.io/$externalIP/country)
printf "%${mtab}s %s\n" "ISP:" "$isp"
printf "%${mtab}s %s\n" "Country:" "$country"
dnsIP=$(dig redhat.com | awk '/SERVER/{print $3}' | awk -F \# '{print $1}')
dnsName=$(dig +short -x $dnsIP)
if [ ! $dnsName ]; then
dnsName="Not Detected"
fi
printf "%${mtab}s %s\n" "DNS IP:" "$dnsIP"
printf "%${mtab}s %s\n\n" "DNS Name:" "$dnsName"
}
errorStatus()
{
errorCon="$?"
if ((errorCon >= 1)) ; then
printf "%${mtab}s %s\n" "Exit Status:" "${errorCon}"
fi
}
wp()
{
((count++))
printf "%${mtab}s %s --> %s: %s\n" "Status:" "Pass" "Host" "$ix"
}
wf()
{
printf "%${mtab}s %s --> %s: %s\n" "Status:" "Fail" "Host" "$ix"
}
webTest()
{
printf "Spider Web Crawl \n"
divider
let count=0
sites=("www.redhat.com" "www.ubuntu.com" "www.google.com" "www.yahoo.com")
for ix in ${sites[@]}
do
wget -q -t1 -T5 --spider $ix && wp || wf
done
printf "\n"
if ((count >= 1))
then
return 0
fi
}
clear
versionHeader
network
errorStatus
webTest
# END #
So if that says 127.0.1.1 while you are connected to vpn it is very
likely you are leaking.
I just wrote this in the morning to watch basic dns on port 53 for tun0.
If you don't see traffic on this, you're leaking.
#!/bin/bash
#############################################################
#
# script: dumpdev.sh
# date: 2016-01-05 7:50AM PST
# version: .01
# written by: marek novotny
# purpose: tcpdump dns traffic on vpn tunnel
# notes: none
#
#############################################################
addr=8.8.8.8
device=""
priv=sudo
report () {
echo "$2" && getSudo
}
getSudo () {
if [ $(id -u) != 0 ] ; then
sudo -v
if [ $? == 1 ] ; then
report 1 "Wrong Password..."
fi
else
unset priv
fi
}
dumpDevice() {
$priv tcpdump -i $device port 53 -nSX
}
waitForDevice () {
until [[ $device == "tun0" ]] ; do
device=$(ip route get $addr | awk 'NR==1 {print $(NF-2)}')
done
dumpDevice
}
getSudo
waitForDevice
# END #
It's not very tested. I just popped it out and didn't test it well.
Probably a bug here and there. All it does it spits out live dns traffic
over port 53 when you are connected with tun0. If you see nothing,
that's a problem. If you see traffic pumping through it, you should be
good.
So again, I'd personally just use the vpntest.sh to see what your dns,
among other things, is while connected. Try running it before and after
so you see what changes. You can do this with the simple dig command we
talked about a while back. Seems like you got tcpdump down a bit too so
sounds like you're getting a handle on it all.
I skipped much of the conversation, sorry it was long and I'm on several
medications which make me ill for now. Not adjusted to my situation just
yet.
--
Marek Novotny
https://github.com/marek-novotny
William Unruh
Jan 5, 2016, 2:42:33 PM1/5/16
to
On 2016-01-05, JJ <jj4p...@vfemail.net> wrote:
Note that since the vpn is presumably running on the wireless network,
everything that goes on tun0 also goes on the wireless. So you would
need to look for wireless traffic that does NOT go to the tun0 router.
Could you router then divert and not only send to the tun0 router but
also to NSA.gov? Sure, and nothing you look at on your computer would
show that up. Mind you you hope that it is all encrypted but that would
still allow traffic analysys.
Shadow
Jan 5, 2016, 7:47:57 PM1/5/16
to
On Tue, 5 Jan 2016 18:39:42 +0000 (UTC), JJ <jj4p...@vfemail.net>
wrote:
>JJ <jj4p...@vfemail.net> wrote in message n6fdk5$h6s$1...@news.albasani.net
>
>> Please correct where I make mistakes, but, I don't see the *response*
>> from the DNS request in the following quick test of just the tunnel!
>
>Running the test a few more times, I was able, with good technique, to
>hone the dns query down to the 3 steps that I would assume it consists of.
>
> https://i.imgur.com/bDAAiHb.jpg
>
OK, it's working
Baby steps. Always use "all interfaces" when you are learning.
Next, write
dns
where it says Filter:
The "Apply" button will light up. Click on it .Voila.
As to all the other protocols, get the Wireshark manual, study
it for 2 or 3 months, and post back. You probably won't need help
anymore.
;)
[]'s
"Colher de cha"
https://www.wireshark.org/video/wireshark/introduction-to-wireshark/Introduction%20To%20Wireshark.mp4
(5 minute tutorial)
and
https://www.lcuportal2.com/index.php?option=com_content&view=category&layout=blog&id=49&Itemid=75
http://www.howtogeek.com/104278/how-to-use-wireshark-to-capture-filter-and-inspect-packets/?PageSpeed=noscript
Links courtesy Craig and David Lipman from alt.comp.freeware
--
Don't be evil - Google 2004
We have a new policy - Google 2012
wrote:
>JJ <jj4p...@vfemail.net> wrote in message n6fdk5$h6s$1...@news.albasani.net
>
>> Please correct where I make mistakes, but, I don't see the *response*
>> from the DNS request in the following quick test of just the tunnel!
>
>Running the test a few more times, I was able, with good technique, to
>hone the dns query down to the 3 steps that I would assume it consists of.
>
> https://i.imgur.com/bDAAiHb.jpg
>
Baby steps. Always use "all interfaces" when you are learning.
Next, write
dns
where it says Filter:
The "Apply" button will light up. Click on it .Voila.
As to all the other protocols, get the Wireshark manual, study
it for 2 or 3 months, and post back. You probably won't need help
anymore.
;)
[]'s
"Colher de cha"
https://www.wireshark.org/video/wireshark/introduction-to-wireshark/Introduction%20To%20Wireshark.mp4
(5 minute tutorial)
and
https://www.lcuportal2.com/index.php?option=com_content&view=category&layout=blog&id=49&Itemid=75
http://www.howtogeek.com/104278/how-to-use-wireshark-to-capture-filter-and-inspect-packets/?PageSpeed=noscript
Links courtesy Craig and David Lipman from alt.comp.freeware
--
Don't be evil - Google 2004
We have a new policy - Google 2012
Kirk_Von_Rockstein
Jan 7, 2016, 11:58:12 AM1/7/16
to
On 2016-01-05, JJ <jj4p...@vfemail.net> wrote:
<snip>
> Since I'm new to Wireshark and tcpdump, this is the first pcap capture
> which has made complete sense to me (with respect to its logic sequence).
>
> My goal is to see if *any* packets are being sent *outside* the tunnel.
You need to be sniffing at the last interface node on your network.
> which has made complete sense to me (with respect to its logic sequence).
>
> My goal is to see if *any* packets are being sent *outside* the tunnel.
The WAN port interface ...to see for certain wither you have a DNS leak
or other going on.
Big Bad Bob
Jan 20, 2016, 4:09:12 AM1/20/16
to
On 01/05/16 10:39, JJ so wittily quipped:
maybe you can monitor all of the interfaces, then filter out the tunnel
interface in the display? [that way you only display packets NOT going
over tun0]
I'd think that would be the easiest way of seeing, well, if ANY traffic
does NOT go over tun0.
interface in the display? [that way you only display packets NOT going
over tun0]
I'd think that would be the easiest way of seeing, well, if ANY traffic
does NOT go over tun0.
0 new messages