F5 LTM SNAT: only 1 outgoing connection, multiple internal clients

Hi,

I've configure a simple setup based on diameter message routing on a 13.1 LTM. I should be as generic as possible to achieve the setup nejasmicz requested.

What it does:

• CER/CEA went well between client an F5
• F5 selects server (10.10.10.1) from correct pool
• F5 does correct SNAT: source is 10.10.10.10 towards server

What's wrong:

• the CER to server F5 seems to ignore the parameters I've defined in "profile_diam_message_routing" to be used for CER.

The config I used:

ltm pool /Common/pool_diameter_server {
    members {
        /Common/10.10.10.1:3868 {
            address 10.10.10.1
        }
    }
    monitor /Common/monitor_GatewayFast
    service-down-action reselect
}

ltm snatpool /Common/diameter_snatpool {
    members {
        /Common/10.10.10.10
    }
}
ltm virtual /Common/virtual_Diameter_Message_Routing {
    destination /Common/1.1.1.1:3868
    ip-protocol tcp
    mask 255.255.255.255
    profiles {
        /Common/profile_diam_message_routing { }
        /Common/profile_diam_message_routing_router_profile { }
        /Common/tcp { }
    }
    source 0.0.0.0/0
    translate-address enabled
    translate-port enabled
}
ltm message-routing diameter peer /Common/profile_diam_message_routing_peer {
    pool /Common/pool_diameter_server
    transport-config /Common/profile_diam_message_routing_transport
}
ltm message-routing diameter route /Common/profile_diam_message_routing_static_route_to_peer {
    peers {
        /Common/profile_diam_message_routing_peer
    }
    virtual-server /Common/virtual_Diameter_Message_Routing
}
ltm message-routing diameter transport-config /Common/profile_diam_message_routing_transport {
    ip-protocol tcp
    profiles {
        /Common/Diameter_server_tcp { }
        /Common/diametersession { }
    }
    source-address-translation {
        pool /Common/diameter_snatpool
        type snat
    }
}
ltm message-routing diameter profile router /Common/profile_diam_message_routing_router_profile {
    app-service none
    defaults-from /Common/diameterrouter
    max-pending-bytes 0
    max-pending-messages 0
    mirror disabled
    mirrored-message-sweeper-interval 1000
    routes {
        /Common/profile_diam_message_routing_static_route_to_peer
    }
    traffic-group /Common/traffic-group-1
    transaction-timeout 10
    use-local-connection enabled
}
ltm message-routing diameter profile session /Common/profile_diam_message_routing {
    acct-application-id 0
    app-service none
    array-acct-application-id { 0 }
    array-auth-application-id { 0 }
    auth-application-id 0
    defaults-from /Common/diametersession
    dest-host-rewrite none
    dest-realm-rewrite none
    handshake-timeout 10
    host-ip-address 10.10.10.10
    max-message-size 0
    max-watchdog-failures 1
    origin-host siteserver.customf5.com
    origin-host-rewrite none
    origin-realm customf5.com
    origin-realm-rewrite none
    persist-avp SESSION-ID[0]
    persist-timeout 180
    persist-type none
    product-name none
    reset-on-timeout enabled
    vendor-id 10415
    vendor-specific-acct-application-id 0
    vendor-specific-auth-application-id 16777264
    vendor-specific-vendor-id 10415
    watchdog-timeout 30
}

These are the 2 types of CER

 Command Code: 257 Capabilities-Exchange
 ApplicationId: Diameter Common Messages (0)
 Hop-by-Hop Identifier: 0x80000000
 End-to-End Identifier: 0x8dc56807
 AVP: Origin-Host(264) l=20 f=-M- val=hss.loadgen.com
 AVP: Origin-Realm(296) l=16 f=-M- val=loadgen.com
 AVP: Host-IP-Address(257) l=14 f=-M- val=2.2.2.2
 AVP: Vendor-Id(266) l=12 f=-M- val=0
 AVP: Product-Name(269) l=12 f=--- val=LOADGEN
 AVP: Inband-Security-Id(299) l=12 f=-M- val=TLS (1)
 AVP: Vendor-Specific-Application-Id(260) l=32 f=-M-
      AVP Code: 260 Vendor-Specific-Application-Id
      AVP Flags: 0x40, Mandatory: Set
      AVP Length: 32
      Vendor-Specific-Application-Id: 0000010a4000000c000028af000001024000000c01000030
           AVP: Vendor-Id(266) l=12 f=-M- val=10415
                AVP Code: 266 Vendor-Id
                AVP Flags: 0x40, Mandatory: Set
                AVP Length: 12
                Vendor-Id: 10415
                VendorId: 3GPP (10415)
           AVP: Auth-Application-Id(258) l=12 f=-M- val=3GPP SWm (16777264)
                AVP Code: 258 Auth-Application-Id
                AVP Flags: 0x40, Mandatory: Set
                AVP Length: 12
                Auth-Application-Id: 3GPP SWm (16777264)

 Command Code: 257 Capabilities-Exchange
 AVP: Origin-Host(264) l=19 f=-M- val=host.f5.com
 AVP: Origin-Realm(296) l=14 f=-M- val=f5.com
 AVP: Host-IP-Address(257) l=14 f=-M- val=10.10.10.10
 AVP: Vendor-Id(266) l=12 f=-M- val=3375
 AVP: Product-Name(269) l=16 f=-M- val=F5 Bigip
 AVP: Origin-State-Id(278) l=12 f=-M- val=0
 AVP: Auth-Application-Id(258) l=12 f=-M- val=Diameter Common Messages (0)
 AVP: Acct-Application-Id(259) l=12 f=-M- val=Diameter Common Messages (0)
 AVP: Firmware-Revision(267) l=12 f=-M- val=1

The static route does intentionally matches all Application IDs, Origin Realms and Desitination Realms to forward all incoming Diameter traffic (to 1.1.1.1:3868) regardless of its AVPs to the peer node (10.10.10.2).

Why are these parameters not evaluated in the CER towards my server node but instead Origin-host is set to "; and Product-Name is "F5 Bigip" - is it something blueprint? Furthermore my Vendor-Specific-Application-Ids are ignored completely.

Had anyone experience in configuring message routing for diameter and could point out what went wrong?