I have a question regarding setting up inbound access to my companies webserver [forgive me if this is too basic for this forum but I have read the appropriate manuals in the knowledgebase and couldnt get a satisfactory answer. I recently took over this role and I'm new to F5's]. For outbound traffic we currently have multihoming setup on out F5s with a primary 100MB link and a backup 4MB link. All internet traffic is routed out the 100MB, if this link goes offline we failover to the 4MB link and this works as required. For inbound traffic we want to be able to be able to assign 2 IP addresses to our web server [one from each ISP] and have all inbound traffic connect via the primary ISP address [lets call it 100.100.100.100] and if that goes offline users will still be able to connect to the same URL via the backup ISP IP address [lets call it 4.4.4.4]. I have setup the appropriate virtual servers linking 100.100.100.100 and 4.4.4.4 to the internal ip address of our web server and both ip addresses can be pinged from the web. I can HTTP to 100.100.100.100 ok but if I try to HTTP to 4.4.4.4 it fails [internet explorer cannot display the web page]. [Both servers have exactly the same access through our firewall]. Will the 4.4.4.4 address only be accessible from the web once we have failed over to the 4MB link or should I be able to HTTP to it from the web at anytime? Also do I need to setup an Inbound Wide IP to be able to access this server via the same URL? [i.e. web users connect to www.whatever.com which resolves to 100.100.100.100. Then our primary ISP goes offline and 100.100.100.100 is no longer accessible. Will www.whatever.com now resolve to 4.4.4.4 because the Inbound Wide IP advertises it or will BGP still be needed?] Any advice would be much appreciated. Thanks

Since you mentioned Inbound Wide IPs, are you using Link Controller? Or GTM? Have you done a tcpdump from the F5 box when trying to HTTP to 4.4.4.4? I'd be curious whether your F5 is trying to send the server's response out the 100.100.100.x link.

Im using Link Controller, I will run a tcpdump and check the output

Posted By biglouie on 01/14/2011 07:52 AM Im using Link Controller, I will run a tcpdump and check the output So your setup is like this: Link 1 - 111.111.111.x Link 2 - 4.4.4.x Virtual Server 1 - 111.111.111.111:80 Pool for Virtual Server 1 - Let's say 10.1.1.1 Virtual Server 2 - 4.4.4.4:80 Pool for Virtual Server 2 - Let's say same as Pool for Virtual Server 1 How do you have your links defined so that outbound only uses Link 1? It's been a little while since I've been in Link Controller so am curious. Also, LC should be able to use DNS to handle the Link Failure you described.

Put the ISP router IP addresses for both links into a pool called "pool_default_gateways" and have this as the default gateway for the LC. Give the primary link a priority of 5 and give the backup link a lower priority and set priority group activation = less than 1. So all outbound traffic goes through the higher priority link until that fails, then it goes through the lower priority link.

Gotcha. That makes sense and handles outbound just fine but can definitely cause issues with inbound. For inbound, you'll define a wide ip and have it use your Virtual Servers from each link. I can't remember how to have it only hand out the Virtual Server from link 1 though...

Inbound Web access | DevCentral

Forum Discussion

Recent Discussions

Viprion End of Software Support (EoSS)
1 day ago
Bryan_T_
Restore configuration to GTM Sync Group device
2 days ago
leemedz
Questions on device trust
2 days ago
InquisitiveMai
BIG‑IQ: Adding rSeries/Velos Devices through the REST API
2 days ago
Ichnafi
AppWorld DC Booth Kiosk Generator
2 days ago
JRahm

Forum Discussion

Win Big in Vegas: The iRules Contest is back with $5k on the line at AppWorld 2026

Jürgen - February 2026 Featured Member

F5 Architecture Track Sessions - AppWorld 2026

Recent Discussions

Viprion End of Software Support (EoSS)

Restore configuration to GTM Sync Group device

Questions on device trust

BIG‑IQ: Adding rSeries/Velos Devices through the REST API

AppWorld DC Booth Kiosk Generator

Related Content

Mitigating OWASP Web Application Risk: Broken Access Control using BIG-IP

SSL Orchestrator Advanced Use Cases: Inbound Authentication

SSLO in public cloud: Azure inbound L3 use case

SSL Orchestrator Use Case: Inbound SNI Switching

Mitigating OWASP Web Application Risk: Broken Access attacks using F5 Distributed Cloud Platform