locked
S4B-Web-Plugin is requesting internal (unroutable) EDGE IP from WAN RRS feed

  • Question

  • Hi there,

    Is there any way to find out why the following is happening:

    -S4B Server 2015 on premise, all CUs, installed after best practise guide (1 FE and 1 EDGE-Server with dedicated external IPv4 addresses for each service), split brain DNS

    - road warrior with macbook pro

    - OS X 10.12.3, S4B-Web Plugin on Safari, S4B 16.3.241 client installed, too, little snitch firewall.

    for testing how our partners would communicate with us, I used this machine from outside. (50MBit/s DSL to 155MBit/s dedicated line)

    When connecting to a S4B online meeting with the browser plugin I can connect - but the connection is very laggy and interrupted from time to time - AND the strangest thing is:

    The local firewall asks for permission to connect Safari-PlugIn to 192.168.10.1:54902 - this is the INTERNAL interface of the EDGE-Server.

    A "nslookup EDGE.mydomain.com" at the same time gives correct EXTERNAL IPv4 address. 

    How does this come?

    Doing the same with a Win8.1 PC with S4B 2016 native Client from outside does not give any problem at all and is not laggy, too!

    I´m really confused about that.

    Regards - F.One

    Friday, February 10, 2017 2:17 PM

All replies

  • For the communication of the SFB client it will use ICE on the SDP protocoll and try to reach the internal IP of the Edge.

    From external this IP is not reachable and the client will use the external address.


    regards Holger Technical Specialist UC

    Saturday, February 11, 2017 9:04 AM
  • Hi

    From your information i could understand that external safari plugin is trying to connect to your internal Edge IP address through the firewall ? is that correct . How about MAC client  did you try joining the meeting using that? From external there should not be a request coming for an internal NIC address , unless we have not isolated the internal network from external , do you have a default gateway defined for the internal NIC? 


    Linus || Please mark posts as answers/helpful if it answers your question.

    Monday, February 13, 2017 5:06 AM
  • Hi F.One,

    The reason was stated by Holger and because this issue didn’t occur on Windows8, we suggest you do the following steps to check if the issue persist:

    1. Update OS X and Safari to the latest
    2. Re-install SFB-Web Plugin
    3. If “local firewall” mean it is on OS X, disable local firewall to have a test

    Best Regards,
    Jim Xu
    TechNet Community Support


    Please remember to mark the replies as answers if they helped.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Monday, February 13, 2017 6:27 AM
  • Hi there all,

    thank you all for your input.

    @Linus ("From external there should not be a request coming for an internal NIC address , unless we have not isolated the internal network from external , do you have a default gateway defined for the internal NIC?")

    First, I did not track the native OS X client - I will do that asap. But my guess is that there is something in your phrase I quoted above. Let me explain our configuration:

    The EDGE is a non domain joined hyperV-VM on a Bladecenter-Host in the DMZ. It has 4 virtual NICs, all connected to the DMZ:

    1. internal IP "EDGE", no gateway, just a dedicated route to the internal LAN for this NIC only
    2. SIP, internal IP, NATed to public IP
    3. AV, internal IP, NATed to public IP
    4. webcon, internal IP, NATed to public IP

    A "route print" on this server confirms these settings, especially that the route to the internal LAN is bound to the NIC of "edge" only.

    Also verifying this in the topology-builder - internal and others are well defined.

    AFIK the best practice is to connect the internal NIC directly to the LAN, bypassing the internal gateway - but unfortunately I have no real idea how I could solve this for the given environment:

    • IBM Bladecenter H with one switch module giving the 10G uplink to DMZ-switch
    • Bladeserver as HyperV-Host with one real NIC connected via Bladecenter Backplane to that switch
    • HyperV-Guest "EDGE" with 4 virtual NICs
    • Co-located HyperV-guest as FE server (domain joined)
    • Co-located HyperV-Guest as Office WebApps-Server (domain joined)
    • (And some other HyperV-Guests)

    So I resolved this by defining a "forward all" rule from that EDGE-IP (and FE, too) into the LAN with highest priority on the internal firewall.

    We payed two different MVPs to evaluate my implementation of a "S4B on premise"-environment - and yes, of course the would love to have the internal NIC of the edge connected directly to the internal LAN, but our setup passed all their tests and so they where fine with that at the end.

    Do you have any further thoughts on this?


    Monday, February 13, 2017 11:39 AM
  • @Holger:

    I understand, that an internal client would connect to the internal IP of the edge-server.

    But who is telling the INTERNAL (unroutable) IP of the edge to an EXTERNAL client? Or is the edge server telling both, internal and external IP and the client is just probing the internal first and then using the external? If this is "works as designed" what will happen if by coincidence in the LAN where the external client is situated a system exists with the given internal IP of the edge?

    Thank you - F.One

    Monday, February 13, 2017 11:40 AM
  • @Jim Xu

    OS X is latest (10.12.3, Safari, too) 

    it was a fresh installation of the plugin, reinstallation did not change anything

    Disabling firewall does not accelerate screen sharing at all - it just suppresses the notification that the web-plugin is requesting unroutable IPs.

    I did NOT confirm, that the Win8-client was NOT requesting such IPs (I just not did track connection data for the Windows machine as I did for the OSX, I will repeat that asap!) - I just reported a good quality of connection while using the native S4B 2016 on Windows machine)

    Thanks, F.One

    Monday, February 13, 2017 11:41 AM
  • Hi F.One,

    To this issue, we suggest you re-produce the issue and check if there are any errors in application log, then post them to us for troubleshooting.


    Best Regards,
    Jim Xu
    TechNet Community Support


    Please remember to mark the replies as answers if they helped.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Wednesday, February 22, 2017 2:09 AM