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

Not sure i fully understand the scenarios which you described; however If you use standard virtual server, its a full-proxy architecture, so it will maintain two separate TCP connections between client-side and server-side. In your case if you have multiple clients they all individually initiate capability exchange with bigip, and bigip initiate separate capability exchange with server (in this process bigip send its own Origin-Host in the CER) when first message receive from client.

Proxying CER/CEA is against RFC (https://tools.ietf.org/html/rfc6733section-5.3) and let me rephrase the full-proxy architecture, as i mentioned in my previous comment, proxy will maintain two separate connections for client and server (let assume your internal diameter element is a client side and external diameter element is a server side). So all your internal clients establish individual connection towards bigip, and bigip establish separate connection towards the external server, and these connections remain forever (unless some other issues terminated the connection). Diameter is not like other protocols (example HTTP, request & response and close the connection), it has a mechanism to send Watch-Dogs if the connection is idle and that's maintain the connections between diameter elements.

Hope the above clarifies, you dont need something like send all CER's from your internal element to proxy to your external element and again it violate RFC. why because the proxy(bigip) is sitting in between and maintain the connections separately and route the message based on routes.

If you are setup Diameter Load Balancing and Message Routing; Refer the following. https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/ltm-implementations-12-1-0/39.html https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/bigip-service-provider-message-routing-administration-13-0-0/1.html

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?