Access to same subnet than BIIG IP from SSL VPN

Forgive me but where is the F5 involved?

• What is the Virtual Server IP address?
• Is the SSL VPN terminated on the F5?

Do you have a SNAT of some sorts turned on the Virtual server? If not, you'll need that without the F5 being your Default Gateway. Otherwise you will route around your F5 and break the connection..

Hi,

@What Lies Beneath Yes of course F5 is the VPN Termination point... Virtual Server is 172.16.1.100 which is in the same subnet than the DMZ...

That's why I'm getting asymetric routing... First packet is sent directly (via the VPN to the F5) and then the answer is sent back from the server via the Firewall which doesn't have any opened session...

@iRuleYou Everything works fine with SNAT or Automap on the VS but in this case I'm not able to identify the orgininal IP (192.168.250.x)...

I also had a look to Route Domain but not able to find a correct solution

Thanks for your help

Nicolas

Original IP is saved on BIG-IP in logs. Also you may create iRule to manipulate with src IP (save in special file or similar) But if you wish using None for Snat, and your clients are from another subnet, then the backend servers will use the default GW for responses, and you have to configure default GW to redirect responses to BIG-IP, or use BIG-IP as GW (btw, you may use BIG-IP as firewall too with the AFM module).

If I'm understanding the above correctly you will need to add a static route to the servers to point the 192.168.250.0/24 range to the BIGIP instead of the default route.

Hi,

Yes static route will solve my issue but it's not something that we want to implement... If we have to deploy more server into the DMZ it will become a nightmare to maintain...

Today I will try to setup a lab and add a new VLAN (10.1.1.x). I will create a new Route Domain and will associate it with the VPN feature... In this case I suppose that VPN will need to use the defaut route of the new domain. This route will point to the Firewalls... This will maybe solve my issue

I'll keep you posted

Assuming you are willing to entirely redesign and build the DMZ and F5 setup then sure, you can fix this. Your best bet would be to put the F5 'inline'; so have a /29 small subnet between the firewall and F5, route a /24 or similar for Virtuals from the Firewall to the F5 over it and use another /24 for the real servers. Let me know if you want me to expand on that.

Hi,

Not sure I understand why we need to put it inline?

What will be the benefits inspite of using a dedicated DMZ for the F5 ?

Thanks for you help

Another way to solve this is to have the DMZ servers pointing to the firewall as normal as the default gateway but add a secondary IP to the firewall interface.

You then configure an IP Pool for the VPN users on the same network range as the secondary IP range. You also enable proxy arp on the Network Access policy so that the APM responds to ARP requests correctly and the firewall picks up the responses on the secondary IP range. What would happen is that the APM routes to the secondary IP on the firewall and then back out the interface to the DMZ Servers. The DMZ Servers would route to the original default gateway then back out the same interface to the IP Pool configured.

However you lose the original source IP which I believe you want to keep (although you can see which clients had what pool IP in the logs which is better than using SNAT). Welcome to the wonderful world of network engineering :) You will need to either implement the static routes, manage your design differently or take the option above as a compromise but would require a bit more looking up of client to pool IPs if there are any issues.

Hi All,

Finally found a good setup !

Here is what I tested yesterday...

1. Define a new DMZ Zone on the Firewall (172.16.10.0/24)
2. Define a new Interface on the F5
3. Define a new Route Domain on the F5 a place the newly created VLAN into the RD.
4. Use stric isolation in the RD
5. Add a new defaut route into the route domain to point the new interface on the Firewall
6. In APM assign the Route Domain after authenticated

Everything works fine with Route Domain

Thanks for your help