Forum Discussion

Hans_Schneider2's avatar
Hans_Schneider2
Icon for Nimbostratus rankNimbostratus
Dec 04, 2014

Using F5 as default gateway in Amazon AWS

Hi!

 

I'm using a VPC with 3 different subnets in Amazon. They are called public, private and test. The external traffic hits the external IP of F5 in the public network and an iRule redirects the traffic to the test network. This is working as it should.

 

The problem I have is that when the servers in the test environment initiates the traffic they get the external IP of the NAT machine in the public network. This is because the routing table 0.0.0.0/0 points to this machine. This is needed since the servers in the private network needs to access the Internet, that's how the Amazon VPC is built. More information: http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_NAT_Instance.html

 

But for the test network I want the F5 to be the default gateway so outbound traffic from test gets the F5 external IP. I have created a NAT list with the following information: NAT Address: F5 External IP Origin Address: Test IP Enabled on all

 

The test server is now configured to use F5 test interface as gateway but it is still not able to send traffic to the Internet. I'm not even able to see any hits on the statistics tab of the NAT configuration.

 

Could anyone help me with this?

 

11 Replies

  • Does the LTM default route point to the AWS NAT 'machine'?

     

    Is the NAT enabled on the correct VLAN(s)?

     

  • Well, the default gateway is the Amazon gateway that exists in every subnet on the IP XX.XX.XX.1. I guess this forwards external traffic to the AWS NAT instance which then sends it with the external IP of that instance. Since I have a NAT rule using the F5 external IP address I guess it should forward to this or am I wrong? Strange however I cant see any hits in the statistics of this NAT rule.

     

    It is enabled on every VLAN.

     

  • This appears to be the classic problem of getting the return traffic back through the LTM, which isn't specific to AWS. The problem you are facing then, is that you can't put a more specific route on the pool members because you don't know the source addresses clients will come from (ie: Internet).

     

    If this is the case, the simple solution is to apply SNAT Automap on the Virtual Server. Among other things this will allow you to retain AWS as the Default Gateway on your Pool Members. The traffic to the pool member will then be sourced from the BIG-IP's Self IP on that internal vlan.

     

  • Hi,

     

    The security group connected to F5 and Test1 are open for any. The network ACL is open for any in the public and test subnet.

     

    I have a Virtual Server that is configured with SNAT Automap and this works as a charm for incoming traffic to F5 which then sends it to the test network and a reply back to the Internet.

     

    My problem is that network traffic origin from my test network gets the external IP of the NAT instance which is different from my F5 external IP. My customers has only the F5 external IP whitelisted in their firewalls, not the NAT instance external IP.

     

    See below picture for a better understanding of my problem:

     

     

    The blue arrow shows how the traffic is flowing today when I start a connection from my Test1 server. I want the traffic to flow like the yellow arrow.

     

    To fix this I thought I could create a NAT rule stating that all traffic origin from 10.0.16.0/24 towards 0.0.0.0/0 should NAT to the external IP of F5. This rule is enabled on the Test network VLAN. The strange thing is that I don't see any hits on the statistics for this NAT rule and I cant access Internet. Test1 server has the default gateway of F5 interface on the Test network. So what am I doing wrong?

     

    Thank you for your time.

     

  • Update: I have disabled source/destination check on every F5 interface because I read about a similar product that required this but it did not help.

     

    Anyone with another idea what the issue might be?

     

  • Solution:

     

    You need to disable source/destination checks on the f5 interfaces.

     

    You need to create a Virtual server with forwarding IP which has the F5 test interface as source, destination 0.0.0.0/0 and none in source address translation.

     

    Create a NAT rule which has the F5 private IP in the public network as the translation IP and the origin address as the test network.

     

  • Hans, can you confirm what path the inbound traffic takes please? Is it the same (blue arrows) but in reverse?

     

    Also, what exactly is this 'NAT Instance', is it actually a hop in the path (from a L3 perspective)?

     

  • Hi,

     

    Thought I answered on this topic but I guess not. I solved my problem and it was 3 things.

     

    Disable source/destination checks on the public and stage interfaces on F5. Create a Virtual server with Forwarding(IP) and none in source address translation. Instead of using F5 external IP as translating address you need to use the F5 public interface IP.

     

    It is a bit messy when using Amazon VPC but very smooth when it works.

     

    • Jeremy_Harris_2's avatar
      Jeremy_Harris_2
      Icon for Nimbostratus rankNimbostratus

      could you clarify the following

       

      Create a Virtual server with Forwarding(IP) and none in source address translation. Instead of using F5 external IP as translating address you need to use the F5 public interface IP.

       

      referring back to the diagram you posted. not sure what settings you are adding for Source address transaltion and what type of SNAT or NAT you have configured.

       

      thanks

       

  • Although, I have a new problem now.

     

    When I try and ping from the test network I get 'Destination net unreachable', but I can open a web browser and go to the website I'm trying to ping.

     

    The default gateway is F5 test interface.

     

    Is F5 stopping the traffic in some way? I have enabled the virtual server to work for all protocols. No ACL or Security group is interfering.