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

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.

etc, etc, etc.

RDNS resolves both of these to kryptotel.net: 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

Jeff Liebermann wrote, on Sun, 07 Sep 2014 16:24:07 -0700:

Kubuntu 13.10

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.

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) ... :)

Yes. As has been said in this thread numerous times ( whith I admint, many other things also being said by others in this thread)

For my information-- can you tell me any vpn implimentation which does not encrypt the headers but does encrypt the contents of the packet?

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.

Sure. Any IPSEC implementation that does not use AH header compression. This explains how it works: Note that there are usually two IP headers involved. The encapsulated IP header, which contains the LAN IP address, and the external IP header which defines the VPN terminating server. The LAN IP headers are always encrypted. The external IP (routing) header is usually not encrypted. See Fig 3 above.

If the WISP were sniffing the traffic looking for contract violators using his system for commercial purposes but only paying consumer rates, he would be most interested in the external IP (routing) header, which would be needed in order to connect to the terminating VPN server. What is happening on the LAN at either end is of little concern.

Hint: One of the most common VPN screwups that I've seen is where the IP block at both the client and company network use the same Class C network block. For example, if the company used 192.168.1.xxx and the client used the same block for his local network, there's a really good chance that there are going to be duplicated IP addresses when the two networks are glued together by the VPN tunnel. This is why I like to use goofy Class C (non-routable) IP blocks for home networks. My office is 192.168.111.xxx and home is something else.

Back to fighting with Windoze 8.1. I'm losing.

Just one question: Did he speak English? Well, one more: Did he install seat belts on your chair?

If you have a split tunnel setup, you get to download your Usenet junk on your own dime. If you have a full VPN, which funnels all traffic through your employers VPN, he gets to pay for your Usenet junk. Somehow, I don't think the IT people will appreciate the traffic. As a compromise, you might consider just downloading article headers and only reading what is worth reading (like my postings).

Dilbert, working from home:

Upgrade to 14.04LTS

It was the "encapsulated" headers I was refering to. The others had better not be encrypted since they are critical for delivering the packet from the vpn client to the server.

Not clear how sending packets even to a vpn server at your company could be considered a vilation.

Why in the world one would route the local network over the vpn I do not know, but I agree there could well be problems if there are duplicate addressses on the remote network as on the local one.

I think this is the crux of the matter. The statement you have made is not correct. The correct statement would be that all traffic from the computer goes through the tunnel.

The problem is that you are familiar with a Citrix product which is not actually a VPN, although it provides some VPN-like services in a different way. Some people might even incorrectly call it a VPN, but is neither a full tunnel nor a split tunnel.

Scott

Service port numbers /of the encapsulated packet/, not the payload.

I think you've misunderstood what Unruh's asking. When Unruh said 'the headers', he meant those of the /encapsulated packet/, not the outermost one, as that is the implication of what you originally wrote.

I suppose you could indeed run an IPsec tunnel with the 'null' encryption algorithm but I would think those would be few and far between.

You could just create a static route to the news server's IP via your default gateway rather than the tunnel.

The routes related to my employer's VPN have a metric of 1. For the addresses that they suck in, (it's a split tunnel), I can't make any exceptions because I can't get anywhere near that metric. From memory, the best I can do is a metric of 21.

Teh OP has a box which is supposed to be doing the VPN for him. It is not clear to me how that box is attached, or what the innards of that box are. It could be that that box is simply another computer with an address on his local network, which he is supposed to route all his company traffic, or all his traffic to. It will take over the job of setting up the VPN and the routing. Now I would doubt that the company would allow a full tunnel into their site (Ie, allow all traffic from his machine to run through the company network) That would seems to be as bad a security hole as allowing him to log onto the company network from outside. Thus that box might have a routing table which routes company IP through that tunnel, and all other traffic through his ISP. Or it may have the condition that ONLY traffic to the company is to go through that box.

It will be interesting to see if the company person who is going to set it up for him will be totally flummoxed when he sees a Linux machine, or come up with a new rule that only Windows and Macs are allowed to connect to the company. Anyway it will be interesting to see what happens. I hope the OP reports.

Sorry. I was using "IP headers" to refer to both the routeable IP headers, and the encapsulated headers for the local LAN. Sorry for the muddle.

For the record, the LAN IP headers and port numbers are encapsulated, encrypted, and not visible. However, that's not what's important here. The OP is trying to determine what the WISP can sniff to avoid a rate increase precipitated by a change from consumer to commerical service. That will largely be determined by the amount of traffic, but also by what he's using the WISP services. Staying connected to a VPN server all day long is usually deemed commercial use as it's assumed that only business users (and paranoid hackers) use VPN's. I vaguely recall (and am too lazy to check) that the AT&T and Comcast ToS (terms of service) specifically define using a VPN server as commercial use. Yeah, here's a really old reference: and it's more relaxed mutation: From the AUP at: there's no specific mention of VPN, but does mumble that the service cannot be used for: "use the Service for operation as an Internet service provider or for any business, other legal entity, or organization purpose (whether or not for profit)" I'll assume that the WISP ToS and AUP policies are similar.

Anyway, the question is whether the ISP can see the VPN server IP address, the common VPN ports, and the amount of traffic through the VPN. For all 3 questions, the answer is "yep".

It's not common but is often done where the encryption and encapsulation overhead would excessively slow the system down, or where security isn't a big concern. For example, I use several unencrypted IPsec tunnels to seperate non-time critical traffic from various weather stations that all share the same source IP address using a shared link where I'm a low priority user. That makes QoS much easier to setup and gives me big discount. Actually, I barely recall how it's setup as it's been running essentially untouched since about 2006.

Back to doing battle with Windoze 8.0 -> 8.1

That's a different headache. Assuming different Class C IP blocks for the local LAN (which I'll call the remote office) and the other side of the VPN server (which I'll call corporate headquarters), the idea is to make the headquarters LAN visible to the remote offices. To do this, each machine connected via the VPN ends up with two IP addresses. One is the original local LAN IP address, which is assigned by the local DHCP server. The other is delivered from an address pool in the VPN server and is on the corporate headquarters LAN IP block.

On the remote office client machines, the big question is where does the default gateway point to? For the local LAN, it's easy. It goes to the IP address of the local router that connects to the internet. However, it can also point to the default router on the corporate headquarters LAN if the admins decide that EVERYTHING at the remote offices will go through their security system (looking for viruses and leaks of confidential information). It can also point to the corporate VPN server IP, and do much the same things.

Want me to diagram it out with example IP addresses? (I'm busy right now and don't have the time).