Forum Discussion

Joern_Oltmann's avatar
Joern_Oltmann
Icon for Nimbostratus rankNimbostratus
Mar 09, 2021

Create outgoing Server with resticted destination by hostnames (not IP)

Hi all,

I have one question about outgoing virtual Server.

I know that I can create an outgoing VS with restricted destination IP or Network(s).

In time of Cloud it is more intressting to restrict the Destination by Hostname because the IP's in the Cloud are dynamic.

 

My Question. It is possible to restriced on outgoing VS by destination with one or more Hostnames and not IP's?

 

Thanks

Joern

BIG-IP
devops
iRules
  • Simon_Blakely's avatar
    Simon_Blakely
    Icon for Employee rankEmployee
    Mar 11, 2021

    You can do this using Address Lists and Traffic matching Criteria

     

     

    You can specify the address list as the destination-address-list of a traffic-matching-criteria

     

    Note that you can only configure a traffic-matching-criteria and assign it to a virtual server in TMSH or via the iControl rest API.

     

    Alternatively, you can use AFM firewall rules on the traffic hitting the virtual server to allow only specific destinations by fqdn.

    • Joern_Oltmann's avatar
      Joern_Oltmann
      Icon for Nimbostratus rankNimbostratus
      Mar 11, 2021

      Hi Simon,

      sorry I am an expert for BigIP LTM,

      I don't understand it.

      I don't know the destination IPs, because they are dynamic. So I have to use an hostname like www.google.com. But how canI configure it?

      Could you give me an simple example, because I got an error with traffic-matching-criteria

      (cfg-sync Standalone)(Active)(/Common)(tmos)# show traffic-matching-criteria all-properties
Syntax Error: "traffic-matching-criteria" unexpected argument
      • Simon_Blakely's avatar
        Simon_Blakely
        Icon for Employee rankEmployee
        Mar 11, 2021
        (tmos)# list ltm traffic-matching-criteria

        traffic-matching-criteria exist in the ltm context

        You need to create a dns-resolver and associate it with the global-fqdn-policy

        (tmos)# list net dns-resolver
net dns-resolver my_dns_resolver {
    route-domain 0
}
 
(tmos)# modify security firewall global-fqdn-policy dns-resolver my_dns_resolver
 
(tmos)# list security firewall global-fqdn-policy
security firewall global-fqdn-policy {
    dns-resolver my_dns_resolver
}
 
(tmos)# list security firewall address-list my_address_list
security firewall address-list my_address_list {
    fqdns {
        google.com { }
        microsoft.com { }
    }
}
 
(tmos)# create ltm traffic-matching-criteria my_traffic_matching_criteria destination-address-list my_address_list
 
(tmos)# modify ltm traffic-matching-criteria my_traffic_matching_criteria source-address-inline 192.168.0.0/16
There were warnings:
Traffic Matching Criteria's inline destination address has been set to any4 from any6 to match inline source address' address family.
 
(tmos)# list ltm traffic-matching-criteria my_traffic_matching_criteria ltm traffic-matching-criteria my_traffic_matching_criteria {
    destination-address-inline 0.0.0.0
    destination-address-list my_address_list
    source-address-inline 192.168.0.0/16
}
 
(tmos)# create ltm virtual VIP-HTTP traffic-matching-criteria my_traffic_matching_criteria
 
(tmos)# list ltm virtual VIP-HTTP
ltm virtual VIP-HTTP {
    creation-time 2021-03-11:14:08:48
    last-modified-time 2021-03-11:14:08:48
    profiles {
        fastL4 { }
    }
    traffic-matching-criteria my_traffic_matching_criteria
    translate-address disabled
    translate-port disabled
    vs-index 4
}

        It's not easy (yet), and you would probably be better looking at other solutions, but it can be done.

        Of course, you can also create a destination pool for a virtual server that dynamically populates from an FQDN.