i-Rule for Diameter AVP realm rewrite on a virtual server

This rule applies to both directions of a flow. Under 11.5, BIG-IP retains its full-proxy "client-server" view for Diameter traffic. In this architecture, the "client-side" is a transport flow between a system and a BIG-IP Virtual Server. The "server-side" is the proxied flow based on client-side traffic. Thus, when a Diameter instance initiates a flow toward a BIG-IP Virtual Server with the diameter profile applied, this usually initiates a server-side flow toward a pool member, which is a different Diameter instance. I say "usually" because it may re-use an existing server-side Diameter connection. In either case, there client-side traffic and server-side traffic belong to single connection (aka, flow) table entry. the DIAMETER_EGRESS event will fire just before a Diameter message is proxied in either direction.

So let us assume your flow looks like this:

peer1  <-->  BIG-IP  <-->  peer2

peer1 is talking to a BIG-IP Virtual Server, while peer2 is a pool member. Let's say that peer1 sends a CCR with the Origin-Realm set to "ims.mnc090.mcc100.3gppnetwork.org". The iRule above, if applied to the Virtual Server, will fire. The message will be proxied to peer2, but the Origin-Realm will be set to "ims.mnc099.mcc100.3gppnetwork.org". When peer2 responds with a CCA, it belongs to the same BIG-IP connection table (aka, flow) entry, so the iRule will apply to it, as well. Therefore, when it assert "ims.mnc099.mcc100.3gppnetwork.org" as the Origin-Realm, the message will be proxied to peer1, but the Origin-Realm will be changed to "ims.mnc090.mcc100.3gppnetwork.org".

Based on your request, I believe this is what you desire and expect.

If, on the other hand, you are saying that either peer1 or peer2 may initiate a Diameter connection (meaning, it will initiate the transport and assert the CER), then you will need a Virtual Server or set of Virtual Servers (each with the diameter profile and this iRule applied) to which either peer can connect.