dslreports logo
 
    All Forums Hot Topics Gallery
spc
Search similar:


uniqs
3832
garrettm
join:2002-05-23
Beaverton, OR

garrettm

Member

[FiOS] Cannot map drives when on corporate VPN thru Frontier FIO

This is a strange problem but it seems isolated to Frontier FIOS.

When I login in to my corporate VPN from my home over my Frontier FIOS connection, I connect to the VPN but cannot map out my corporate drives. I literally cannot see any of the mapped drives yet I am getting inside the corporation as I can see intranet websites.

What confuses me is that the same laptop has no trouble with VPN and mapping drives when I log in over my ATT hotspot, Centurylink DSL and Comcast High Speed Cable.

The Frontier FIOS connection looks like this ONT(on side of house, thru coax) to Actiontec MI424WR rev F to Netgear(router).

I have tried going directly into the Actiontec (with same results, no mapping) and directly into the Netgear router (which sits in a an Actiontec DMZ (again same results VPN, yes mapping, no).

On both routers I have tried wired connection and wireless connection with same results with VPN connection but no ability to see mapped drives.

I am stumped and so is my IT department.

My next and last step is to have Frontier change the ONT to ethernet instead of coax, therefore eliminating the Actiontec router and directly attaching my own router or the Netgear directly to the ONT

Ben J
My spoon is too big
Premium Member
join:2011-09-16
Elk Grove, CA

Ben J

Premium Member

Re: [FiOS] Cannot map drives when on corporate VPN thru Frontier

Sounds like an MTU/PMTUD problem.
garrettm
join:2002-05-23
Beaverton, OR

garrettm

Member

The MTU on the Actiontec is set to automatic I have not adjusted that parameter. I will try it. I suppose 1500 is a good guess.

Ben J
My spoon is too big
Premium Member
join:2011-09-16
Elk Grove, CA

Ben J

Premium Member

Wouldn't be on the Actiontec.

Your PC and the server automatically detect the MTU of the network and adjust their packet sizes accordingly. If you filter ICMP unreachables anywhere between you and the server, you'll break PMTUD. This generally means that if any link in the path has an MTU smaller than 1500, the connection won't work very well, because the PC/server will just "assume" it's 1500 (the MTU of their local ethernet interface) and keep trying that size. Any packet that gets transmitted above the MTU gets lost and the PC/server never adjusts.

A VPN makes this worse, because it must encapsulate the packets, thus making the MTU even smaller.

This actually happens a lot when uninformed people (your typical IT engineers) finish reading their Security+ book and scream "RAWR!! ICMP BAD!!!" and filter it, without understanding the broader implications of doing so. IT engineers have gotten lazy because ISPs have worked hard over the past 15 years to ensure all links support at least 1500. But there is no guarantee it's always the case.

So when I hear "it works on one path but not another path", the first thing I think of is a link in the middle with a smaller MTU, and PMTUD is broken becausse ICMP is filtered.
Ben J

Ben J to garrettm

Premium Member

to garrettm
So after you've checked that and if it's not the problem, I'd look at the IP of the server. Is it on the same subnet as the IP the Actiontec is giving you?

Then we'd have to start looking at the type of VPN. PPTP, L2TP, IPSEC (Transport mode? Tunnel mode?), SSL? Is it set up for split tunneling or dedicated? And what type of file server? Windows share? NFS?
garrettm
join:2002-05-23
Beaverton, OR

garrettm

Member

We use Cisco AnyConnect

Smith6612
MVM
join:2008-02-01
North Tonawanda, NY
·Charter
Ubee EU2251
Ubiquiti UAP-IW-HD
Ubiquiti UniFi AP-AC-HD

2 edits

Smith6612 to Ben J

MVM

to Ben J
said by Ben J:

This actually happens a lot when uninformed people (your typical IT engineers) finish reading their Security+ book and scream "RAWR!! ICMP BAD!!!" and filter it, without understanding the broader implications of doing so. IT engineers have gotten lazy because ISPs have worked hard over the past 15 years to ensure all links support at least 1500. But there is no guarantee it's always the case.

I have to agree with this and see it constantly. It seems to be more common with the governmental-related institutions around here as well. ICMP is so filtered out to the point where MTU Path Discovery absolutely fails to operate. Often times it's restrictive enough to the point where you can't traceroute anything beyond the initial router you have to go through even though there's still a router or two left on the Intranet, which does not need ICMP filtering. The WAN is often filtered to the point where you can't ping or traceroute beyond the firewall from either direction but Path discovery still works fine. Those are often networks I find that run terrible (as in, sites that won't load, VPNs that bug out completely, etc) even when they have a Gigabit+ connection coming in with an unspecific MTU. Host to Host communication within the Intranet is often what doesn't fail to work though. I never bother their IT Dept. about such issues as they generally won't listen anyways, but just some food for thought. It's a matter of taking that nice expensive Firewall you have and making it do what it's supposed to.

A common MTU for VPNs that tends to work well is 1300 bytes per packet. If you temporarily set your host to 1300, see if your VPN starts to work properly, too. VPN traffic does not like being fragmented. Cisco AnyConnect can be set up to use a number of different procotols, the default being SSL-based encryption which each has further amounts of overhead based on what they are. The older, no-longer-supported Cisco VPN Client often came with a "Set MTU" tool that defaulted all of the host's interfaces to 1300 to compensate for the overhead from IPSEC-based VPN and to also make room for lesser connections like PPPoE-based DSL.
Aranarth
join:2011-11-04
Stanwood, MI

Aranarth to garrettm

Member

to garrettm
I would double check that you can ping the file servers as well.

If you can at least ping them though vpn over FIOS then you might be able to map through the the ip address rather than unc.

We use a zyxel box using SSL vpn and I can ping the servers and I can map through ipaddress but not through the unc name.
garrettm
join:2002-05-23
Beaverton, OR

garrettm

Member

I can ping the IP address but not the \\aaa.bbb.ccc.ddd name address.
1300 MTU's did not work.
Aranarth
join:2011-11-04
Stanwood, MI

Aranarth

Member

You don't need to ping the \\ip address.

Just enter that into your run window and see it will show you the available shares so you can map the drive.
garrettm
join:2002-05-23
Beaverton, OR

garrettm

Member

I can ping it but when I map it it says the remote device will not accept the connection. I have gone back and changed the MTU setting with no difference. What gets me is that it is only Frontier(my home provider where this problem occurs, same laptop).

I have now removed the actiontec router from the equation and am coming directly out of the ONT with a Dlink router, all the same problems exist.

Here's what I know:
It is not home router related.
It is not my laptop related.
It is not MOCA (Actiontec coax bridge) related.
It is not the Actiontec router
I can ping the server I am trying to map but I cannot connect to it.
zebibyte
join:2006-04-25
Fairview, OR

zebibyte to garrettm

Member

to garrettm
Could you be facing a netbios block somewhere? TCP and UDP Ports: 135, 137-139, and 445

Also, if possible, can you adjust the NAT traversal method on the Cisco AnyConnect client? Either try a UDP mode or an alternate TCP mode?
garrettm
join:2002-05-23
Beaverton, OR

garrettm

Member

I dont have access to changing the VPN from UDP to TCP.

Frontier has assured me that they are not blocking ports.

Interesting thing is that when I use Canyouseeme.org for checking ports everything seems to be blocked on Frontier. Including port 80.

However when I check it on Centurylink all of those ports are blocked except for 80 and the VPN mapping works on Centurylink.

I am not sure if this tells me anything.

By the end of the week I will probably just go back to Comcast again and call it quits. I am sure there is a magic software switch out there somewhere(that I do not have access to) that would make this work.(Either at Frontier or my company). There is no way that my problem is going to get enough interest to have either side care enough. There are people at work with both Frontier, Comcast and CenturyLink and all seem to VPN in OK.

Smith6612
MVM
join:2008-02-01
North Tonawanda, NY
·Charter
Ubee EU2251
Ubiquiti UAP-IW-HD
Ubiquiti UniFi AP-AC-HD

4 edits

Smith6612

MVM

AnyConnect's configuration is based on the VPN administrator's settings. Poke around in the XML files at C:\ProgramData\Cisco\ or /opt/cisco/anyconnect/... sometime

Oh yeah. Canyouseeme.org won't show open ports unless you port forward or use the DMZ, AND you have a service running on that port. The Ports Frontier blocks are to combat spam (Port 25 :P ), and if they do a Port 80 block, to stop folks from running HTTP servers (even though to my last knowledge, HTTP could be used if it was non-commercial).

Also, having to support Cisco AnyConnect at work, it is a troublemaker. Today we had a problem where AnyConnect could not connect to the VPN Servers from ANY network unless it was on a specific secured network that already had corporate access. It was the weirdest thing ever, and the machine with this problem could not contact the VPN gateways even with known good connections, both internal and external. That was a good hour long facepalm as me and a few other techs worked to figure out what was going on. Happened to every gateway we tried, too.
Skippy25
join:2000-09-13
Hazelwood, MO

Skippy25 to garrettm

Member

to garrettm
Couple things to try as we use AnyConnect as well.

First, what is your OS and the network server you are trying to map to? Windows 7 needs a reg hack to connect to 2000 and earlier servers. However, that issue will show you a login screen but will never accept your creds. Which you did not mention, but thought I would mention this.

Second, Try Always Tunnel on the VPN connection and see if that resolves the problem.

Third, have you tried to connect using IP addresses instead?
garrettm
join:2002-05-23
Beaverton, OR

garrettm

Member

First: My OS is Win7. Good question as to what the servers are, on the corporate side. Keep in mind I dont think my laptop is the problem since any other internet connection seems to work. Comcast, Centurylink, ATTCellHotspot. I have tried them all but for some reason the Frontier FIOS does not map(connects but doesnt map).

Second: I dont see this option but will go back and check

Third: yes. Still does not map, but comes back with something to the effect that this server does not take sharing (SMB)

I dont think it is Frontier, but maybe it is related to my IP address (assigned by Frontier) or something and that particular block has not yet been given access rights to get onto the drives. I am only grasping at ideas at this point. I one point I read that Frontier was getting off Verizon's IP addresses so who knows if this is related.

Smith6612
MVM
join:2008-02-01
North Tonawanda, NY
·Charter
Ubee EU2251
Ubiquiti UAP-IW-HD
Ubiquiti UniFi AP-AC-HD

1 edit

Smith6612

MVM

Interesting that you mention this:
said by garrettm:

Third: yes. Still does not map, but comes back with something to the effect that this server does not take sharing (SMB)

Only Linux and Unix systems (including the Macintosh) use Samba (SMB) to map to Windows drives. Windows doesn't have a need or has a use for Samba. Are these *nix-hosted shares you're trying to map to on a Windows machine?

Also, Frontier stopped using Verizon IPs a while ago. You may however want to do a whois against your IP to see who owns your netblock. I'm pretty sure the sale of Verizon's network included some ranges in the form of SpinCo as a part of the Reverse Morris Trust deal. In which case, minus the routing differences between Frontier and Verizon along with the settings used, the IPs basically had a transfer and a change of records. The Actual IPs themselves never changed.

If AnyConnect is truly making a solid connection, whatever ISP you're on should not be affecting the connection. It's a tunnel after all. Unless it's an MTU issue or an ALG/MITM issue I'm failing to see how being on Frontier FiOS breaks things. Unless of course, the client is set up in a more unique stance where it uses the system DNS rather than the DNS supplied by the Gateway, or it isn't tunneling all network traffic through the VPN in the first place.

darcilicious
Cyber Librarian
Premium Member
join:2001-01-02
Forest Grove, OR
·Ziply Fiber

1 edit

1 recommendation

darcilicious

Premium Member

said by Smith6612:

Interesting that you mention this:

said by garrettm:

Third: yes. Still does not map, but comes back with something to the effect that this server does not take sharing (SMB)

Only Linux and Unix systems (including the Macintosh) use Samba (SMB) to map to Windows drives. Windows doesn't have a need or has a use for Samba. Are these *nix-hosted shares you're trying to map to on a Windows machine?

Uhm... Windows file sharing IS SMB:
quote:
Most usage of SMB involves computers running Microsoft Windows, where it was known as "Microsoft Windows Network"
From: »en.wikipedia.org/wiki/Se ··· ge_Block

Linux and OS X use the equivalent known as "Samba" to connect with Windows file sharing using the same protocol...
Skippy25
join:2000-09-13
Hazelwood, MO

Skippy25 to garrettm

Member

to garrettm
I can assure you Windows 7 can't map a drive or connect to a share that is on Windows 2000 or older without adding the below to the registry.

1 . Open registry editor
2 . Browse to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
3. Create a new DWORD value named LmCompatibilityLevel with a value of 1
4. Restart the computer

As I mentioned before, this typically is a fix for when you get the share but it refuses to take your credentials (even blank or no password). However, it is worth a try at this point.

Always Tunnel may not be an option. I just took it for granted that it was being we have always had it as a option on our machines to force ALL traffic across the VPN. This helps with some issues like yours and allows for printing in the office when remote, which may be the reason we have it.

IP address is irrelevant. As long as it is public and allows you to gain access to the internet and establish a VPN connection you are golden. Port blocking wont matter as it goes through the VPN from your computer to your VPN server. Nothing anyone does in between can effect that.
garrettm
join:2002-05-23
Beaverton, OR

garrettm

Member

Update: Sorry it took me a week to put in this update. The company gave me a VPN Beta option(We have a few VPN site options you can go into) which pushes a latest Cisco Anyconnect update on my computer. Everything now works. I have asked but have not been told what the difference between the different versions is. I still do not have a clear picture as to why Frontier was the only connection that would not work on the existing VPN options nor can anyone else explain it. I do appreciate the help from all the individuals on DSLReports. Thanks.
Aranarth
join:2011-11-04
Stanwood, MI

Aranarth to garrettm

Member

to garrettm
Glad you got it all sorted.

As for what changed, it may have been a bug or a configuration change in the vpn software itself that had nothing to do with your specific machine or network settings.