What does the Wireless ISP (WISP) "see" when I'm using VPN fromhome?

Discussion in 'Wireless Internet' started by Yaroslav Sadowski, Sep 5, 2014.

  1. So let us keep talking about the same thing, a VPN
    While a vpn is sort of like a proxy, it is also different.
    The only thing your ISP (which I assume is what you meant by IP just
    below) sees is your address and the port that you talk to the VPN on,
    and the address of the VPN server, and the port of the VPN server
    software on the server. Your isp cannot see the address the encrypted
    packet is eventually going to go to, nor the port at that address that
    packet will eventually go to.
    True if you mean your VPN server, false if you mean say google, or
    pinkworld.
    Once the packet arrives at the vpn server, it unencrypts the packet,
    looks at the header, replaces the source IP/port in that header with its
    own IP and a high number port that it records as meaning anything coming
    to that port is to be forwarded over the vpn to your address.

    The ONLY machine anywhere that knows that traslation from the vpn
    server's address and high random port to your IP and your port is on
    that vpn server. Noone else can "unhide" it. There are no sites, except
    the vpn server who can do it.

    Your real ip is no longer part of the packet. Only the vpn server's ip
    is part of the packet. All delivers go back to the server.
    It then translates tresponse port to your IP/port.
    Nope Only during the delivery of that encrypted packet ( which hides the
    destination IP/port header in the encrypted packet.
    Nope. There is nothing in the packet sent to the final source (eg
    www.google.com) that contains your adddress/port. Nothing. There is just
    the VPN IP/port.
    ISP again? No it knows that you delivered a packet to the vpn server but
    that is all. It does NOT see the final destination where you want it to
    go.

    Yes, it does see that you are sending a packet to the VPn server.

    No idea what "a pulic IP" means. After the packet leaves the vpn server,
    there is nothing in the packet that traces it back to you, except a
    random source port number which can be translated only by that vpn
    server.
    The server replaces your real IP.
    Nope. it is not. That that packet content relates to you is known only
    by the vpn server. That you sent an encrypted packet to the vpn server
    IS known by the ISP, but neither the contents nor the ultimate address
    is known by them. And after it leaves the vpn server nothing in the
    packet points back to you.


    No idea what you mean by anonymity.

    ISp knows you sent and received packets from the vpn server. Noone else
    knows you sent and received packets since their return (source) address
    is that of the vpn server.
     
    William Unruh, Sep 7, 2014
    1. Advertisements

  2. Yaroslav Sadowski

    Caver1 Guest

    That's right and I never said that it did. It only applies to those
    programs themselves.
    You know nothing about using a fake IP or refuse to accept what is
    correct. You can use a fake IP as your real IP is only hidden not
    replaced. The internet network can still see your real IP but most other
    sites or networks cannot. Your real IP is still used to route you but
    only your Fake IP is shown. How that is accomplished I do not know, I
    just know that it works. What do you think a proxy does?

    No.
     
    Caver1, Sep 7, 2014
    1. Advertisements

  3. For that one vpn tunnel yes. That does NOT mean that your employers will
    work the same way. In fact you will be unable to determine the routing
    table there since that box will be what is doing the routing and you
    will not have access to it, except to sent network packets to it and
    receive them

    You could put a sniffer on the output to the box, then try to access
    various things-- like www.google.com,.. and see where the packets coming
    out of the box go to (what the destination IP/port of those outgoing
    packets is).
     
    William Unruh, Sep 7, 2014
  4. William Unruh wrote, on Sat, 06 Sep 2014 22:36:33 +0000:
    Here's the summary, of what has been said about that routing table ...
    Here's a route -n after rebooting but before connecting to the VPN server:
    https://www.vpnoneclick.com

    $ route -n
    Kernel IP routing table
    Destination Gateway Genmask Flags Metric Ref Use Iface
    0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 wlan0
    This is your original default route.
    A destination of 0.0.0.0 with mask 0.0.0.0 matches all addresses
    so it's the least specific and what it says is wlan0 is the default.
    192.168.1.0 0.0.0.0 255.255.255.0 U 9 0 0 wlan0
    This is a route to your LAN out of wlan0.

    $ gksudo vpn1click &
    $ inxi -i | grep eth0
    WAN IP: 198.143.153.42 IF: eth0 ip: N/A IF: tun0 ip: 10.43.0.210 IF: wlan0 ip: 192.168.1.3

    $ route -n
    Kernel IP routing table
    Destination Gateway Genmask Flags Metric Ref Use
    Iface
    ......
    0.0.0.0 10.43.0.209 128.0.0.0 UG 0 0 0 tun0
    the route to half the internet goes through tun0: (which is the VPN)
    Any address with a 1 bit inthe most significant bit of the
    address will be sent to tun0
    This covers a destination of 0.0.0.0 to 127.255.255.254.
    This is the 1st half of the Internet split by the VPN provider.
    if 10.43.0.209 it is sent directly on tun0 (the tunnel)
    If 10.43.0.1 it is sent to 10.43.0.209 on tun0
    if 128.x.x.x it is sent to 10.43.0.209 on tun0
    if 1bbbbbb.x.x.x it is sent to 10.43.0.209 on tun0
    128.0.0.0 10.43.0.209 128.0.0.0 UG 0 0 0 tun0
    This covers a destination of 128.0.0.0.1 to 255.255.255.254.
    This is the 2nd half of the Internet split by the VPN provider.
    and so does the other half go to tun0:
    ......
    0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 wlan0
    This is your original default route.
    A destination of 0.0.0.0 with mask 0.0.0.0 matches all addresses
    so it's the least specific and what it says is wlan0 is the default.
    This was your route before starting the VPN.
    10.43.0.1 10.43.0.209 255.255.255.255 UGH 0 0 0 tun0
    10.43.0.209 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
    This means that 10.43.0.209 can be reached by a packet out of tun0.
    198.143.153.42 192.168.1.1 255.255.255.255 UGH 0 0 0 wlan0
    108.178.54.10 192.168.1.1 255.255.255.255 UGH 0 0 0 wlan0
    These two are static routes added by the VPN client software.
    The only traffic that doesn't traverse tun0 is traffic to these
    two IP addresses.
    This is probably the VPN server.
    These two are explicitly routed via the wlan0 connection
    192.168.1.0 0.0.0.0 255.255.255.0 U 9 0 0 wlan0
    This is a route to your LAN out of wlan0.
    if 192.168.1.x it is sent directly to wlan0
    if 108.178.54.10 it is sent to 192.168.1.1on wlan0
    if 192.143.153.42 it is sent to 192.168.1.1 on wlan0
    anything else is sent on wlan0.

    Thus if you go to 56.23.44.8 it will go on wlan0(not vpn)
    If you go to 142.103.234.23 it will go via tun0 (vpn)

    Note: The fact that lo0 doesn't appear in the routing table,
    accounts for 127.0.0.0 - 127.255.255.255.
    Note: tun0 is the VPN tunnel.

    All the traffic on wlan0 is going to/from either 198.143.153.42 or
    on 108.178.54.10, or both.

    I recognize 192.168.1.1 as my home broadband router.
    I recognize 198.143.153.42 as the VPN server.

    'Iface' is the interface on which the gateway IP address can be reached.

    Then, when I kill the vpn, here's the route:

    $ ps -elfww|grep vpn
    0 S usr 3170 1701 0 80 0 - 58576 hrtime 13:15 pts/0 00:00:01 gksudo vpn1click
    4 S root 3175 3170 0 80 0 - 17214 poll_s 13:15 ? 00:00:00 /usr/bin/sudo -H -S -p GNOME_SUDO_PASS -u root -- vpn1click
    4 S root 3176 3175 2 80 0 - 36051 poll_s 13:15 ? 00:00:16 vpn1click
    5 S root 3331 1701 0 80 0 - 8266 poll_s 13:15 ? 00:00:05 /usr/sbin/openvpn --config /etc/vpnoneclick/client.ovpn --daemon

    $ sudo kill -9 3170 3175 3176 3331 (or killall vpn1click)
    $ route -n
    Kernel IP routing table
    Destination Gateway Genmask Flags Metric Ref Use Iface
    0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 wlan0
    192.168.1.0 0.0.0.0 255.255.255.0 U 9 0 0 wlan0
    198.143.153.42 192.168.1.1 255.255.255.255 UGH 0 0 0 wlan0

    I notice that the VPN server of "198.143.153.42" is *still* in the route.
     
    Yaroslav Sadowski, Sep 7, 2014
  5. Yaroslav Sadowski

    Caver1 Guest

    Only to the VPN's network no where else. Unless you are originating from
    within that network. Then that is also not the case. How is the tunnel
    created to a site that has no client software? It can't. that's one
    reason why the network blocks accesses to other places.
     
    Caver1, Sep 7, 2014
  6. Jeff Liebermann wrote, on Sat, 06 Sep 2014 20:38:08 -0700:
    Hi there Jeff,

    I have wireshark running:
    $ sudo apt-get install wireshark
    $ wireshark &

    Up pops a blue & white Wireshark version 1.10.2 (SVN Rev 51934) window
    which says on the left "Capture" side:

    No interface can be used for capturing in this system with the current
    configuration.

    So, I'm going to have to figure out how to put the wlan0 card into
    the right mode for the Wireshark program to sniff it, I think???

    The Google inxi program reports the wlan0 card is:
    Network: Card-1: Intel Centrino Ultimate-N 6300 driver: iwlwifi
     
    Yaroslav Sadowski, Sep 7, 2014
  7.  
    William Unruh, Sep 7, 2014
  8. Nope. Any address with a 0 bit in the most significant bit.
    Yes, those all have 0 in their MSbit.
    128.0.0.0 to 255.255.255.255
    I got this wrong. It was covered by the first of the tun0 rules.
    nope. 192.168.1.x traffic also goes directly to the relevant computer via wlan0. It is assumed
    that any such address is on the local network, and packets will be
    delivered via arp/mac not via IP address. (arp is the local tables that
    translate IP addresses to mac addresses for the local network).

    It does no harm All this says is that if something sends a packet to
    this address it should go via the wlan0 gateway. But the default route
    would have sent it that way anyway.
     
    William Unruh, Sep 7, 2014
  9. William Unruh wrote, on Sun, 07 Sep 2014 20:43:00 +0000:
    That's a good point.

    I hook up the box tomorrow, so, we'll see what happens to my traffic
    at that point, and whether their net nanny blocks anything.

    I asked the IT guys about the company nntp newserver and he said
    there wasn't one.
     
    Yaroslav Sadowski, Sep 7, 2014
  10. Jeff Liebermann wrote, on Sat, 06 Sep 2014 20:38:08 -0700:
    Yeah, It's in Santa Cruz, near where you hail.
    We'll see what their net nanny does to my nntp traffic! :)

    It seems these main programs tell me something nice about
    the network traffic when using VPN:

    route -n

    sudo apt-get install iftop
    sudo iftop -n -i wlan0

    sudo apt-get install wireshark
    wireshark &
     
    Yaroslav Sadowski, Sep 7, 2014
  11. Groan. I should have guessed by the deluge and formatting.
    Yet another nym?
    Current stable version is 1.12.0.
    Which Linux mutation are you using?
    If my memory is still functional, I vaguely recall that you have a
    Ubiquiti M2 wireless client radio sitting on your roof with a dish
    pointed at your friendly local WISP. If that's correct, you don't
    want to sniff the radio. You want to sniff the ethernet card that's
    driving the radio. The only time you want to sniff the wireless card
    is when it's inside the computah or plugged in via USB. All that
    radio link does is gift wrap your ethernet packets inside 802.11
    packets for transport (layer 2), and unwrap them at the destination
    end resulting in the original ethernet packets.
    Ok, maybe you don't have a Ubiquiti M2, PoE cable, and rooftop radio.
    If you're using an inside router to connect to your rooftop Ubiquiti
    radio, make our lives easier by running some CAT5 between the ethernet
    port of your Linux box, and one of the LAN ports on your inside
    router. That takes a 2nd Wi-Fi link out of the picture.
    If you must sniff the inside wi-fi link, try:
    <http://wiki.wireshark.org/CaptureSetup/WLAN>
    Ignore any mention of Windoze and WinPcap. Pay attention to the
    difference between monitor and promiscuous model. However, I would
    run the CAT5 and forget about sniffing your inside wi-fi traffic.
     
    Jeff Liebermann, Sep 8, 2014
  12. Yep. That's about it. There's some question as to what the WISP
    considers commercial traffic versus home user traffic. My guess(tm)
    is that he doesn't care, and simply identifies the owner of the
    terminating VPN. If it's a commercial operation, that has
    telecommuters using its service, you're a commercial user.
    Possibly true. If the VPN is NOT a split tunnel and DOES encrypt the
    IP headers, the WISP cannot determine what you're doing. However, if
    the headers are visible and not encrypted, the service port numbers
    will also be visible. From those and some traffic analysis, he can
    get a fair idea of what you're doing. As I mentioned, much depends on
    the type of VPN tunnel.

    Realistically, he probably doesn't care unless your traffic
    dramatically increases. If your traffic is just company email and
    some document juggling, you won't attract any attention. However, if
    you screw up and misconfigure your end to pass *ALL* the internet
    traffic through the VPN and out via your employers internet
    connection, your traffic volume is going to drastically increase,
    which is certain to get the attention of your new employer.

    Incidentally, many VPN's fail to appreciate much in the way of packet
    loss. If wireless link is furiously dropping packets, you're going to
    have problems staying connected. The easiest test is to use ping, or
    better yet, hrPING:
    <http://www.cfos.de/en/ping/ping.htm>
    Do a continuous ping to something local to your WISP, such as their
    gateway server. If all the delays are roughly the same, you win. If
    they are all over the place, you're seeing retransmissions and
    therefore longer latencies. You can fish retransmission statistics
    using SNMP from your Ubiquiti M2 radio, but it's easier to just use
    hrPING.

    You should also run a MAX MTU test to make sure your WISP or anything
    along the roadway to your new job is messing with MAX MTU setting. I
    thought that was a thing of the past, but I just ran into it about 2
    weeks ago.
    See for thyself with Wireshark. Much depends on the type of VPN
    tunnel, and whether the IP headers are encapsulated.
    True. But they know to whom you are connected. If the RDNS resolves
    to something like "telecommuter.vpn.example.com" on a Cisco EZVPN
    server, it's a fair assumption that you're using the WISP service for
    business purposes.
     
    Jeff Liebermann, Sep 8, 2014
  13. Groan... My palatial office is in Santa Cruz (city).
    Same as what I would do. Throttle it with QoS or side track it with a
    VLAN.
    Yawn. SNMP and Netflow (Cisco) are more fun. I can make pretty
    graphs of your traffic broken down by protocol. The reports are
    suitable for presentation with your impending WISP rate increase.

    <http://www.paessler.com/network_traffic_monitoring_tools>
    <http://www.nagios.com/solutions/protocol-monitoring>
    <http://www.servercare.nl/Lists/Posts/Post.aspx?ID=5>
    <http://oss.oetiker.ch/rrdtool/gallery/index.en.html>
    etc, etc, etc.
     
    Jeff Liebermann, Sep 8, 2014
  14. RDNS resolves both of these to kryptotel.net:
    <http://www.kryptotel.net>
    <http://www.kryptotel.ae>
    which is located in the UAE (united arab emirates) and Hong Kong.
    Geolocation puts 198.143.153.42 at singlehop.net in Phoenix AZ, and
    108.178.54.10 at singlhop.net in Chicago. Traceroute verifies the
    locations.
     
    Jeff Liebermann, Sep 8, 2014
  15. Jeff Liebermann wrote, on Sun, 07 Sep 2014 16:24:07 -0700:
    Kubuntu 13.10
     
    Yaroslav Sadowski, Sep 8, 2014
  16. Jeff Liebermann wrote, on Sun, 07 Sep 2014 16:47:53 -0700:
    I had never heard of hrPing before so thanks for that tip.
    Going to that web page, I see they explain why yet another ping,
    and that its a Windows executable (no linux in sight).

    I'll bring it over to my Windows machine and test it out.
    Thanks.
     
    Yaroslav Sadowski, Sep 8, 2014
  17. Jeff Liebermann wrote, on Sun, 07 Sep 2014 16:59:42 -0700:
    I love your jokes, as this is the second (or third), which I had
    to read twice, and then, I smile, and chuckle out loud (my wife
    looking at me across the bed wondering why) ... :)
     
    Yaroslav Sadowski, Sep 8, 2014
  18. Yes. As has been said in this thread numerous times ( whith I admint,
    many other things also being said by others in this thread)
     
    William Unruh, Sep 8, 2014
  19. For my information-- can you tell me any vpn implimentation which does
    not encrypt the headers but does encrypt the contents of the packet?
     
    William Unruh, Sep 8, 2014
  20. Jeff Liebermann wrote, on Sun, 07 Sep 2014 16:59:42 -0700:
    I'm in Scotts Valley, so the IT guy just called and said
    he'd stop over my place at 9am to set me up on the hardware
    VPN.

    When I asked him, he said they don't have a company
    news server, so, I hope the freeware news servers
    work under vpn.
     
    Yaroslav Sadowski, Sep 8, 2014
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.