Forum Discussion
F5 LTM SNAT: only 1 outgoing connection, multiple internal clients
- Dec 03, 2018
After a lot of back and forth, this is the configuration we ended up implementing on F5 LTM v12.1.3.6, that allowed us to utilize MRF to combine multiple connections into a single outgoing connection. The connection exits via the SNAT IP. Hope this helps someone.
First, we defined a Virtual Server to which the clients send the Diameter requests:
ltm virtual /Common/virtual_Diameter_Message_Routing { destination /Common/HSS_v_Diameter_v6:3868 ip-protocol tcp profiles { /Common/profile_diam_message_routing { } /Common/profile_diam_message_routing_router_profile { } /Common/tcp { } } rules { /Common/qux } source-address-translation { pool /Common/diameter_snatpool type snat } translate-address enabled translate-port enabled }
... while the destination is defined as:
ltm virtual-address /Common/HSS_v_Diameter_v6 { address fd41:2:2:1::111 arp enabled icmp-echo enabled traffic-group /Common/traffic-group-1 }
The profiles are defined as:
ltm message-routing diameter profile session /Common/profile_diam_message_routing { acct-application-id 4294967295 app-service none auth-application-id 16777217 defaults-from /Common/diametersession origin-host myoriginhost.test.com origin-host-rewrite myoriginhost2.test.com origin-realm test.com product-name product vendor-id 10415 } ltm message-routing diameter profile router /Common/profile_diam_message_routing_router_profile { app-service none defaults-from /Common/diameterrouter routes { /Common/profile_diam_message_routing_static_route_to_peer } } 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 peer /Common/profile_diam_message_routing_peer { pool /Common/pool_diameter_server transport-config /Common/profile_diam_message_routing_transport } ltm message-routing diameter transport-config /Common/profile_diam_message_routing_transport { ip-protocol tcp profiles { /Common/profile_diam_message_routing { } /Common/tcp { } } rules { /Common/qux } source-address-translation { pool /Common/diameter_snatpool type snat } }
The SNAT is defined as:
ltm snatpool /Common/diameter_snatpool { members { /Common/ext_SNAT_v6 } } ltm snat-translation /Common/ext_SNAT_v6 { address 2607:f160:11:1101::63 inherited-traffic-group true traffic-group /Common/traffic-group-1 } ltm snat /Common/outgoing_snat_v6 { description "IPv6 SNAT translation" mirror enabled origins { ::/0 { } } snatpool /Common/outgoing_snatpool_v6 vlans { /Common/internal } vlans-enabled }
... and finally, the iRules had to be setup to remove Mandatory flags from some of the AVPs that should not have the mandatory bits (bug?) and to send additional Diameter AVPs:
ltm rule /Common/qux { when DIAMETER_EGRESS { switch [DIAMETER::command] { "257" { 260 Vendor-Specific-Application-Id 258 Auth-Application-Id 266 Vendor-Id set aaid_avp [DIAMETER::avp create Auth-Application-Id 0 1 0 0 16777264 unsigned32] set vid_avp [DIAMETER::avp create Vendor-Id 0 1 0 0 10415 unsigned32] DIAMETER::avp append is not designed to create nested avp (ID371630) set grouped_avp [DIAMETER::avp append Auth-Application-Id $aaid_avp source $vid_avp] set grouped_avp ${vid_avp}${aaid_avp} set vsa_avp [DIAMETER::avp create Vendor-Specific-Application-Id 0 1 0 0 $grouped_avp grouped] DIAMETER::avp delete Vendor-Specific-Application-Id DIAMETER::avp insert Vendor-Specific-Application-Id $vsa_avp if { [DIAMETER::is_request] } { DIAMETER::avp mflag set Product-Name 0 DIAMETER::avp mflag set Firmware-Revision 0 } } default { do something } } } }
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.
GRamanan,
The idea would be to take all these internal Diameter clients making outgoing Diameter connections, and funnel them through a single outgoing TCP connection.
The internal Diameter clients are using SNAT currently when establishing an outgoing connection, and that results in the same originating connection IP, but different ports, and therefore multiple connections.
So, the solution we'd need would combine all these different outgoing connections in a single TCP connection, but through it, multiple Diameter CERs would flow.
Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com