locked
WCF and VPN (net.tcp) RRS feed

  • Question

  • We have a set of servers communication on a domain using WCF with net.tcp binding.  Everything works well, everybody can play together.  However, if I start a VPN connection on a client machine even though the connection to the remote WCF service does not use VPN (Use default gateway or remote network is unchecked), and the IP address I'm connecting to does not exist on the WCF server (it is on the local machine only), the mere fact that VPN is running prevents the WCF client from making the connection to the remote machine.  We get a message saying something to the effect of "the remote logon faiiled" and "the server has rejected the client credentials".  Presumably VPN is screwing up the client credentials somehow, but ...

    We cannot always guarantee that our customers will never have VPN running!  In fact, I need VPN to connect to our bug tracking system.  It seems like there should be some way to use WCF with net.tcp binding and yet allow a completely unrelated VPN connection to be made.

    Any ideas would be greatly appreciated!

     

     

     

    Monday, September 27, 2010 9:58 PM

All replies

  • Look at VPN as a tunneling protocol.  It uses the same physical connections (NIC) cards to encrypt the data AND it changes the routing scenarios.... Here's an example

    Client ---Private Network non routable home network to your router

             ---Public Network ---Goes to gateway and onto the Internet.

             -- VPN network --- Goes to the corporate network. Though the Public Network NIC Card

    This is how I work everyday.  When I start the VPN connection I receive a virtual address for that corporate network via Dynamic DHCP.  This address is register with the VPN list of DNS servers at corp.  Along with that configuration comes a list of DNS server appended to my TCP/IP config for that "Virtual route".  Outbound packets that are known to be server by the VPN network must make it to the Virtual route as they are non-routable packets.  The VPN routers know how to bridge then 10.11.XX class C's into their own 10.10.XX networks.  But there are times that happen in VPN configuration whereby an outbound won't go to either the Public Network or the internal Private network (Such as my wireless printer).  Every single time I've had problems with this in the past it turned out to be VPN Configuration issues.  (With the exception of one time, the VPN client had become corrupt but that showed up as more than just a small issue)...

    It is a guess, but, you can easily trace this using wireshark.  All you need to do is to determine which NIC card the start requests are going out on.  That will tell you everything you need to know.  Sometimes you have to change the order of DNS servers to get the right route, as failed DNS queries that reply definitive for the Domain will stop any futher probing.  Good luck.


    Javaman
    Tuesday, September 28, 2010 4:01 AM
  • Even if I get my own personal network to work with WCF and VPN that doesn't solve the real problem.  We are selling this software to customers.  We cannot know what the Customer's network setup will be.  We cannot know for a fact that they won't open a VPN connection, thereby completely breaking WCF.  We cannot possibly ship a product with this HUGE hole in it waiting to bite the customer on the ____.

    There has got to be some way to prevent WCF from malfunctioning just because somebody creates a VPN connection!  The only way I see right now is to completely abandon the built in net.tcp binding security and write our own.  That's not impossible, but it shouldn't be necessary!

     

     

    Tuesday, September 28, 2010 6:21 PM
  • Ken I think you missed my point.  The point is this: there has been no conclusion that WCF is broken in any VPN network.  You merely reported that you have instances of problems and suspect it to be VPN related.  My post was an attempt for you to figure out the root cause on a case by case basis. 

    All WCF is from a TCP/IP perspective is a IPAddress/Port (Socket) communication.  From a VPN perspective it either routes things correctly or it doesn't.  The real question is this for the places where it's failing: "Why doesn't your VPN configuration allow a open to this IPAddress on this Port?"  VPN knows NOTHING about WCF, TCP/IP knows NOTHING about WCF.  WCF is an intermediary layer known to .NET... 

    So try this, continue your tests.  Then zero in on your concern.  If a VPN issue is shown, then start from the problem and work backward.  If you know "it works in NON-VPN" but not "in VPN" you can't assume the problem is with WCF.  You have to trace it all out and determine root cause.  Shoot if WCF didn't work in VPN then what good would it be?

    I'm just guessing but your problem description indicates to me a 95% or better chance that the problem is in the VPN config, NOT your WCF Service. 

     


    Javaman
    Tuesday, September 28, 2010 8:21 PM
  • It is absolutely related to VPN.  It is 100% repeatable that WCF with net.tcp binding works when VPN is not running and doesn't work when it is.  Disable VPN and everything works again.

    To clarify my configuration:

    Computer 1 (10.1.10.100)     ---------------> Computer 2 WCF (10.1.10.101) (DomainX)

         | (VPN address 192.168.1.5)

         |

         |   

         V

    VPN (DomainY (and Computer 3) with 192.168.1.Q) subnet

    The WCF call to Computer 2 is make explicitly using the 10.1.10.101 IP address.

    However, you're right that I don't know for certain exactly who is blocking things or exactly how.  I have turned on WCF debug spew and used Wireshark to determine that WCF messages are getting to Computer 2, and that Computer 2 rejects the client credentials because the Credential has DomainY \userName rather than DomainX\userName.  

    What I don't know is who it is that is responsible for forming the credential that Computer 2 is rejecting -- WCF or some unrelated network layer.  I suspect it is WCF because I can use .NET Remoting with the same network configuration and it works fine.

    If I look at the Windows Identity of the WCF calling thread, I can see that it is DomainX\userName that is making the call into WCF, not DomainY\userName.

    So, somebody is forming the DomainY \userName credential and is passing it to Computer 2.  I suspect, but don't know for sure that it is WCF doing this. IF it is WCF, then WCF is picking the credential up from somebody, and is passing it in a message.  In that case presumably both the DomainX\userName and the DomainY\userName are both available on Computer 1 and WCF is choosing the wrong one, but all I can see in the calling code is DomainX\userName.

    Does that make sense?

     

    Wednesday, September 29, 2010 6:36 PM
  • Yes it makes good sense and shows that you've proceeded to the next step which is starting at root cause and working backward.  In your case you are seeing a credential issue being the last problem known before the failure.  Couple of quick questions, is Computer 1 the client and Computer 2 the host?  When you want to go to Domain Y are you looking for a WCF host or is a client there trying to get to Computer 1 or 2 etc.

    Let's back up one sec. to the VPN layer.  When VPN is started on a computer, (at least in one configuration) it can use DCHP as well as Dynamic DNS updating, this new address of course is a virtual address and looks like a point to point configuration to that other network (192.168.1.Q).  The "Gateway" on that other side can be either a Bridge like config, or a router like config, in that the other side's bound address (remember this looks like Point to point) determines how to route packets etc.  The point is, that when you get the new DHCP from the VPN, for that adapter, your local computer's configs. can and will change.   For example I get DNS suffix updates, a new IP address etc.  But the domain name on my computer DOES NOT change as I am still a part of the same domain I was prior to connecting to the VPN tunnel.  From a pure TCP perspective regarding credentials, network access security etc.  Someone, somewhere has to allow me into the network.  So when you say this is absolutely a VPN issue, I believe you may be indicating as you proved it is really a Security issue within the VPN network.

    Couple of things I'd do next is to see If I can determine what credential is being passed in.  I am guessing it is the credential of Computer 1 in Computer1's original domain.  Then I'd determine what needs to be done to solve the issue, for example "Do you need to pass a credential into VPN network different than that on Computer 1?" Or does VPN network security config need to be changed to allow Computer1's Original Domain.

    Having said that .NET gives first class access to credentialing and has a class that is all about that stuff.  I am personally week on WCF credentialing and Security in general, but I believe you are well on your way to solving this issue, and that WCF will be a good solution for you (Even in VPN networks).

     

     


    Javaman
    Thursday, September 30, 2010 3:47 PM
  • Yes.  Computer 1 is the host.  Computer 2 is the server.  DomainY has absolutely nothing to do with WCF.  We are only using it in order to get to our bug tracking system (not WCF).  The DomainY connection is simply straight TCP.  The WCF application itself never contacts DomainY at all.

    We are using a generic Microsoft VPN connection to DomainY.  The only thing I changed is that I Unchecked the "use default gateway on remote network".  Yes, the default VPN connections do have "Append primary and connection specific DNS suffixes" and "Append parrent suffixes of the primary DNS suffix" set.

    I am convinced that WCF itself is forming the credential it is using for security negotiation.  It does this using the VPN domain credentials even if I explicitly set the channel factory Credentials.Windows.ClientCredential to a credential that includes the correct (non VPN) domain, user name, and password before creating the channel.

    What I am looking for is a way to force WCF to either use the correct credential based on the connection being made (10.1.10.100 to 10.1.10.101) OR by using the credential that I explicitly tell it to use.

     

     

     

     

     

    Thursday, September 30, 2010 5:09 PM
  • You may now want to try to open new thread "WCF and VPN Crendentials" to get the experts'  (on WCF internals) attention now that you absolutely feel it is that issue.  Glad to see you narrowed it down to credentialing.  As I mentioned earlier I am weak on Security and on WCF.
    Javaman
    Thursday, September 30, 2010 7:10 PM