Forum Discussion
NimbostratusF5 VE with VMWare problem
Hi guys,
I just built the F5 VE with vmware, and I've been stucked for days.
================================================================================
So we use 2 physical NIC and trunked 4 VLANS onto the F5 (let's say Internal, External, DMZ and Mgmt).
- Internal: 192.168.1.x /24. Self IP 192.168.1.100
- External: 192.168.2.x /24. Self IP 192.168.2.100 and 192.168.2.250 (this is for the Virtual Server)
- DMZ: 192.168.99.x /24
- Mgmt: 192.168.100.x /24
Next step would be creating the Monitor, Node, Pool and Virtual Server. All are good here.
- Virtual Server 192.168.2.250:443 -> Pool Member Test_Svr -> Node 192.168.30.250:5000
Routing table in F5:
- Default (0.0.0.0) via 192.168.99.254 (DMZ interface in firewall)
- 192.168.30.250 /32 via 192.168.1.254 (Internal interface in firewall)
VLAN in F5:
- Internal, untagged 1.1
- External, untagged 1.2
- DMZ, untagged 1.3
==============================================================================
I then had a client fires up the application destined to 192.168.2.250, but couldn't access the Node.
Troubleshooting from the firewall shows that the F5 doesn't use the internal interface 192.168.1.100 to reach 192.168.30.250, although in the routing table it's specifically instructed to use 192.168.1.x.
My question is definitely, why didn't F5 use it's internal interface? I assume it's something wrong with the VMWare configuration for the network setup, but I am not sure. Reason is, we have a production physical F5 which have similar configuration and it works fine.
Any help is appreciated.
Thank you.
11 Replies
IheartF5_45022Nacreous
Can you ping your next-hop IPs? 192.168.99.254 and 192.168.1.254?
ciscoarcWell, technically I can ping it, the next hop is a firewall.
The firewall blocks it but I can see it from the logs.
Also, what's weird is, I ssh to the F5, telnet 192.168.30.250 5000 and it shows connected. Upon checking the firewall, this telnet traffic comes from internal interface of F5 192.168.1.100.
I guess that sort of proving the network connection is there?
It's just that when client fires off the application, hits the Virtual Server, but then F5 refuses to use the internal interface to reach destination server thus being blocked by the firewall.
Any idea?
- IheartF5_45022
So what interface does it use to try to connect to 192.168.30.250 when you go via the virtual server?
- ciscoarc
The client's own IP address..
- IheartF5_45022
I meant - do you see the F5 trying to send traffic to 192.168.30.250 via an interface other than internal?
What do you see when you run a tcpdump?
tcpdump -i nnn:0.0 -s0 -XX host 192.168.30.250
- ciscoarc
Sorry I didn't make myself clear.
I did the tcpdump and all I can see going out is from the client's IP address, which I thought not supposed to be. I assume it has to use the internal interface. At least that's what happens in our production F5.
- IheartF5_45022
Ah right - you don't have "snat automap" enabled? Sounds like that will fix it.
You only have to use snat if the F5 is not in the natural routing path between the client and server. However if you assumed that the source IP on the serverside would be the self-ip and that is what you configured in the firewall, then using snat will help there too. Hope that makes sense :-)
- ciscoarc
Well, what do I know.
I put the SNAT to automap and it works like charm.
I don't understand how it works though. I'll have a read Thanks mate.
- ciscoarc
Is there anywhere else to enable to SNAT besides in Virtual Server page?
I am trying to determine why I don't have this enabled in production F5..
- IheartF5_45022
No nowhere else to enable (except iRule actually).
Either your network topology is slightly different in prod or - you mentioned a firewall rule blocking the request when it had source IP of the client. Perhaps if you change the rule to allow client ip and self-ip through to the server, you can take snat off and see if it still works. So the point of difference between environments may be the firewall rather than the F5.
