Forum Discussion

pspecht_152507's avatar
pspecht_152507
Icon for Nimbostratus rankNimbostratus
Nov 19, 2014

Cant use windows remote assistance to VPN clients

While testing several of my remote sales employees with the F5 Edge client we found that after they connect, our helpdesk team cannot use remote assistance, remote control, or RDP to the remote sales machines. We also cannot ping the clients after they connect. Is there

 

Remote Control (control) port 2701 Remote Control (data) port 2702 Remote Control (RPC Endpoint Mapper) port 135 Remote Assistance (RDP and RTC) port 3389

 

14 Replies

  • You might try to enable "Preserve Source Port Strict" in the Network Access configuration. This is just a guess and I'm not sure that it will fix your issue.

     

    If this doesn't work then I would suggest taking a tcpdump on the bigip to see if you can find out where it is failing. Please report back with any additional information.

     

    Seth

     

  • check on which VLAN you have the connectivity profile corresponding to this NA resource assigned to.

     

    Alex

     

  • i have a similar problem. servers need to connect out to clients across F5 Edge. The clients are able to connect to servers just fine, but if the server tries to initiate a connection it does not make it.

     

    i can't even connect from the F5 itself to the client (ping or telnet to a listening port). I did the 'reserve strict port' above. nope.

     

    then i created a virtual server to route to that pool subnet. nope.

     

    yes, these pool IP's are routed and there is no SNAT.. so the client IP is what arrives on the servers, etc.

     

    i have a case open. to me it should just work. something must be missing.

     

    • Mark_129802's avatar
      Mark_129802
      Icon for Nimbostratus rankNimbostratus
      Did you ever get a fix for this Brad? I'm in the same boat, everything works fine Client - Tunnel - Server (etc) However nothing on the reverse, I have my routes in place in our networking gear for the Network Access IP pool... Wonder if I need to add a route on the F5 itself for the Client Pool
  • Is it any different if you split tunnel or not? At one point I could route back if all traffic was in the tunnel but did not when split.. but then I got that to work too..

     

    Things that seemed to have solved it: 1. No SNAT - Source Address Translation set to None on virtual server. 2. Preserve Source Port Strict set to ALL on the network stttings of the access profile (advanced). 2. Network must route the VPN pool subnet traffic back to the F5.

     

    At one time I had also put the VPN pool subnet in the tunnel address space, but then I found it wasn't needed. It is probably implied.

     

    I also found clients weren't resolving DNS. Well the DNS servers were internal IP's so those IP's also have to be in the split tunnel IP list in order for the queries to be routed through the VPN. Alternative would be to have the VPN use an external/public DNS/NS.

     

    We are also using DTLS and it works well-- this is a VoIP application.

     

    Think that was all, but it was a struggle to get it going.

     

    • Mark_129802's avatar
      Mark_129802
      Icon for Nimbostratus rankNimbostratus
      I'm just doing Full Tunnel: 1. No SNAT - Check set to none on the Virtual Server and Snat Pool none on NA Network Settings 2. Perserve Source Port Strict - Check enabled in NA Network Settings 3. Return Route - Check, route is in place pointing to the Inside vIP of the BIG-IP 3 I suspect is fine as I can initiate connections from Edge Client NA to the servers and receive traffic back. I just can initiate connections from the Network Side. If I point my return route anywhere else (vIP of Virtual Server) Both ways break. So I think the route is okay. I did a tcpdump in the tunnel and I can't even sing icmp requests when intiated from the Network Side, Client side I see the request and reply just fine. I'll have to open a case I suppose.
  • Update: I did a:

     

    tcpdump -i internal host NAclientip

     

    And I can see the icmp echo requests hitting the Inside Vlan of the BigIP so routing is definitely working in my network.

     

  • do you have a virtual server to route back to the client? I missed that as I always have created these for resources behind the Big-IP...

    it is a IP forwarding virtual server service all ports all protocols.... in this example my IP pool is 10.255.128.0/24

    ltm virtual /Common/vocera_toclientIP {
        destination /Common/10.255.128.0:0
        ip-forward
        mask 255.255.255.0
        profiles {
            /Common/fastL4 { }
        }
        source 0.0.0.0/0
        translate-address disabled
        translate-port disabled
        vlans {
            /Common/vocera_cp_custom
        }
        vlans-enabled
    }
    
  • Hi

     

    I have the same problem. Had to make a foward IP VS to be able to ping the clients, so that works now, but I can not do RDP etc. to the clients.

     

  • I've made my virtual server as per above... however do I need a route table entry on the Big-IP for it to forward to? It seems to forward the traffic now but doesn't have a route to the Network Access clients. I've tried a combination of routes however as the Network Access doesn't have it's own interface no matter where I point it, it doesn't seem to work.

     

    • Mark_129802's avatar
      Mark_129802
      Icon for Nimbostratus rankNimbostratus
      It is definitely a routing issue Trace route From Network Access Client to PC on inside Inside Big-IP > Router Gateway > Internal Client From Internal Network to Network Access Client Internal Client > Inside Big-IP > Router Gateway > Inside Big-IP > Router Gateway > Inside Big-IP > Router Gateway > Inside Big-IP > Router Gateway > Inside Big-IP > Router Gateway ... Looping Until it times out. I'm thinking it is hitting the default route of the Big-IP and sending it back the way it came. I just can't seem to figure out how to point the route to that network down the tunnel?
  • With the help of our lokal F5 Engineer we figured out the problem we had. As we where using routing domains, I had forgoten to add the VPN client IP adr. to the routing domain. After that was done we where able to do connect to the clients with RDP.

     

    • Mark_129802's avatar
      Mark_129802
      Icon for Nimbostratus rankNimbostratus
      Hi Bjarne, When you say "add the VPN client IP adr. to the routing domain" do you mean you added network resource connectivity profile vlan to the members list of the Route domain? I can't find anywhere where you can just put the IP's in.
    • Bjarne_Talg__21's avatar
      Bjarne_Talg__21
      Icon for Nimbostratus rankNimbostratus
      You only need to do this when you use Route domains. Under Network -> Tunnels you will have a profile named "somthing_access_cp" I had to but this tunnel into the same route domain where the link net is (VPN client next hop). Network -> Route domain ->"name of route domain" and add the *_access_cp tunnel.