Forum Discussion

Woody_'s avatar
Woody_
Icon for Nimbostratus rankNimbostratus
Jan 26, 2015

Pool connectivity from the internal network

Hello,

 

I've successfully deployed SharePoint 2013 using the F5 BigIP LTM iApp. I need SharePoint to be able to connect to our OWA pool. The OWA deployment documentation has a section about creating an iRule on the SharePoint VIP that forwards traffic with OWA headers to the OWA pool.

 

I have everything set up correctly but the SharePoint sessions aren't able to forward traffic to the OWA pool. This is evidenced by no traffic hitting the pool members.

 

We have firewalls between the F5 and internal network as well as between clients and the external network.

 

Can I have the SharePoint VIP forward traffic to the OWA pool members without having to go back through the internal/external firewalls? Only the External network can be configured for a VIP based on our security requirements.

 

Thanks,

 

7 Replies

  • mikeshimkus_111's avatar
    mikeshimkus_111
    Historic F5 Account

    Hi Woody, does your external BIG-IP have a route to the OWA servers? If the firewall is between the external BIG-IP and internal network, then the traffic will either need to go through the firewall or route around it.

     

  • Woody_'s avatar
    Woody_
    Icon for Nimbostratus rankNimbostratus

    Hi Mike,

     

    Here's the layout:

     

    Client ---------> Firewall -------------> F5 External Network/Presentation Zone (VIPs) -----------------> Firewall ---------> F5 Internal Network/Application Zone (pool members).

     

    Since we can't route around the F5 sounds like going through the Internal firewall is required.

     

  • Hi Woody, traffic forwarded by a virtual server to pool members should show up in the pool member statistics. For non locally attached pool members you have probably a route pointing to the internal firewalls, right? Do the pool member statistics for the pool_owa show "In" packets but no "Out" packets? This would be an indicator for asymmetric traffic flow which could be avoided by applying SNAT to the virtual server. It will force all responses back to the BIG-IP and the BIG-IP will return the responses exactly the same way where the requests came in (aka F5 AutoLastHop feature). Thanks, Stephan
  • Woody_'s avatar
    Woody_
    Icon for Nimbostratus rankNimbostratus
    Hi Stephan, the pool members show no stats for either incoming or outgoing traffic.
  • In an example set up such as this, we have added the VS on the internal F5 as a pool member on the external F5. This way traffic that hits the external VS, gets 'forwarded' to the internal VS and then LB-ed to the respective servers. You will need to ensure snat automap is on to route back to the external F5. Hope this helps.

     

  • Woody_'s avatar
    Woody_
    Icon for Nimbostratus rankNimbostratus

    Nikhil,

     

    Thank you. This is actually what I did after the OWA iRule on the SP VS didn't work. I created a VS on the internal network and pointed the VS to the OWA servers LB. Because we don't have the F5 cabled/configured to have VS on the internal network, this won't work and thus the need to get back out to the external VS. I was hoping I could configure it so that it didn't have to go back to the external VS to access the OWA servers and looks like this won't work.

     

  • Hi Woody, if there are no "In" statistics for your pool members it looks like the related virtual server does not receive traffic, does not have a route to the pool members or some of the required conditions do not fit. Do you see incoming traffic on the F5 which should hit a virtual server? tcpdump -nnni 0.0:nnnp -s 0 -c 1000 You are aware, that a virtual IP address does not need to belong to any of the locally attached networks (specified by self IPs; floating self IPs to be used as next hop for the peripheral components) and can be reached through each VLAN as long as you not disable it? I still have no picture of your network layout and do not really understand the traffic flow you want to establish. Thanks, Stephan