Diameter Firewall HA
Telkomsel – Indonesia
Diameter Firewall High availability
Page | 1
Diameter Firewall HA
Legal Notices
© 2022 AdaptiveMobile. All rights reserved. This document, or any part thereof, may not,
without the written consent of Adaptive Mobile Security Limited, be copied, reprinted or
reproduced in any material form including but not limited to photocopying, transcribing,
transmitting or storing it in any medium or translating it into any language, in any form or by any
means, be it electronic, mechanical, optical, magnetic or otherwise.
AdaptiveMobile, Network Protection Platform and Policy Filter are trademarks of Adaptive
Mobile Security Ltd.
All other products are trademarks or registered trademarks of their respective owners and are
hereby recognized as such.
The information contained herein is believed to be accurate and reliable. Adaptive Mobile
Security Ltd. accepts no responsibility for its use by any means or in any way whatsoever.
Adaptive Mobile Security Ltd. shall not be liable for any expenses, costs or damage that may
result from the use of the information contained within this document. The information
contained herein is subject to change without notice.
Revision History
Version Date Remarks Author
1.0 11th Feb 2022 Initial release Thirupathi Reddy
Prepared for Telkomsel - Indonesia
Partner Lintas
Solution Name Diameter Signaling Protection
Page | 2
Diameter Firewall HA
Table of Contents
1. Diameter Integration Option ...............................................................................................................................4
1.1 Netfilter Module ..........................................................................................................................................4
1.2 Keepalived .................................................................................................... Error! Bookmark not defined.
1.3 Keepalived Monitoring ................................................................................................................................5
1.3.1 Overview .............................................................................................................................................5
1.3.2 Use Cases ............................................................................................................................................5
1.3.3 Solution - .............................................................................................................................................6
1.3.4 Configuration – ...................................................................................................................................6
2. Failover ..................................................................................................................................................................8
2.1 Failover at PXP .............................................................................................................................................8
2.2 Failover at IPX: .............................................................................................................................................8
2.3 Failover Primary/Secondary Association: ...................................................................................................8
3. Fail open ................................................................................................................................................................9
Page | 3
Diameter Firewall HA
1. Diameter Integration
Option
In Telkomsel, Diameter Firewall will be integrated in a full transparent security gateway mode as an SCTP Proxy
(behind Telkomsel L3 switch) and in between the Telkomsel DEAs and the IPX/RP DEAs.
This means the Diameter Firewall will be terminating multi-homed SCTP associations and processing Diameter
traffic fully transparently so that neither the IPX DEAs nor the Telkomsel DEAs are aware of the Diameter Firewall,
i.e. the Diameter FW still advertises the DEA Public IP
The transparency is achieved by using Netfilter Module.
Static routing will be used in L3 Switch, PE Router, PXP, DEA to route traffic from one node to another.
PXP will be assigned two different subnets (1 for ingress to/from IPX, 1 for egress to/from DEA), i.e., IPX facing VIP,
DEA facing VIP.
IP layer routing will control the HA availability rather than application layer.
Failover between PXPs will be handled using new Private VIPs implemented by AMS on each PXP.
The failover between the PXPs is achieved by using the KeepAliveD monitoring.
Fail-open handled by IPX/Roaming Partner, i.e., in unlikely event both PXPs on single site fail, IPX/RP will
automatically fail over traffic to second site.
1.1 Netfilter Module
The NetFilter Module enables the Signaling Firewall to transparently accept and terminate Diameter traffic from
both the IPX DEAs and the Telkomsel DEAs, process it and then forward it transparently to the origin destination by
performing Destination Network Address Translation function (DNAT).
Page | 4
Diameter Firewall HA
IPX originated Diameter traffic destined for Telkomsel DEA will be routed by the PE-CS Router towards the L3
Switch and onward to Diameter Firewall (next hop). Then the NetFilter module will translate the destination IP
address & port of the incoming traffic to the local IP address and port of the Diameter Firewall so it can accept and
process the diameter traffic.
1.2 KeepAliveD
KeepAliveD is a routing software to provide simple and robust facilities for high availability to Linux system.
High availability is achieved by using VRRP protocol.
KeepAliveD provides interface failover.
It uses virtual IP addresses, defined as VRRP instances, and are assigned to the master server's network interfaces.
The backup server listens for multicast VRRP advertisement packets that the master server transmits at regular
intervals.
If the backup nodes fail to receive three consecutive VRRP advertisements, the backup server with the highest
assigned priority takes over as the master server
and assigns the virtual IP addresses to its own network interfaces.
1.3 KeepAliveD Monitoring
1.3.1 Overview
There is a need to monitor a 1+1 Diameter PXP configuration, so that traffic can continue to flow in
case an individual PXP instance fails.
This operational integrity should also be maintained for network issues or hardware failures in the
path of the traffic.
This capability must not impact any transparency implemented at the PXP side.
1.3.2 Use Cases
1. A Diameter Firewall is deployed as a 1+1 PXP instance arrangement, and if one of the PXP
instances' software fails, the remaining PXP instances takes the traffic
2. A Diameter Firewall is deployed across 2 sites with 1+1 PXPs in each site.
3. Should the first site NIC card fail on the Active PXP, then the second PXP on that site
processes all the traffic.
Page | 5
Diameter Firewall HA
4. Should the first site network cable be abruptly pulled on PXP1 and the second PXP
processes all the traffic.
5. In all cases on failover, NIC fail, PXP software fail, network fail, then both VIPs should
failover at same time. That is, if the network fails for 1 VIP (for example), the VIP1 will
failover but so should VIP2 even though the network is ok on VIP2. And vice versa.
6. Should PXP service go down on PXP01 (master), then both VIPs should failover to PXP2.
1.3.3 Solution -
We have to configure KeepAliveD which can be used to monitor
• Two interfaces of a PXP
• PXP service running.
If either PXP or an interface goes down, then both the VIPs should failover to the other
machine.
The NPP (Controller component) will monitor status of KeepAliveD service.
1.3.4 Configuration –
Below is the Example Keepalived Configuration on PXP -
vrrp_script chk_PXP {
script "/usr/bin/killall -0 PXP_DSG"
interval 1
weight 2
vrrp_script chk_interfaces {
script "/home/adaptive/check_interfaces.sh"
interval 1
weight 2
vrrp_instance VIP {
Page | 6
Diameter Firewall HA
state MASTER
interface bond0
virtual_router_id 82
priority 101
advert_int 1
authentication {
auth_type PASS
auth_pass Passw0rd
virtual_ipaddress {
10.155.33.110/29 brd 10.155.33.111 dev bond2 label bond2:1
virtual_ipaddress_excluded {
10.155.33.118/29 brd 10.155.33.119 dev bond3 label bond3:1
track_script {
chk_PXP
chk_interfaces
There are two scripts to monitor the PXP service & Interface
• vrrp_script chk_PXP is to monitor the PXP service.
• vrrp_script chk_interfaces is to monitor the Interfaces.
Page | 7
Diameter Firewall HA
2. Failover
Failover can be divided into three scenarios:
1. Failover at PXP
2. Failover at IPX
3. Failover from Primary to Secondary Association on each site
2.1 Failover at PXP
1. The VIPs will be managed so that they can fail between PXP1 and PXP2.
2. At any time, the VIPs will be on one PXP. Therefore Active/Passive Solution.
3. Should an issue with software (PXP service) , hardware or external network communication occur, then
the VIP Software will monitor and failover to second PXP.
4. When Second PXP has both VIPs then the Router will not need a change as it has the VIP configuration as
before.
5. The VIPs wont failover separately (i.e. VIP1 on PXP1 and VIP2 on PXP2). This can’t be allowed to occur as a
packet won’t be allowed to route. The DEA communication would end up on PXP2 and the IPX
communication on PXP1. Therefore, a split network scenario. So, when 1 VIP fails over then all VIPs
failover.
6. Should both PXPs go down then the IPX will control the failover. The IPX will fail to second Telkomsel site
as they will see all associations down.
2.2 Failover at IPX:
1. The IPX has connection to 2 sites in Telkomsel (TBS & BRN)
2. The IPX will fail all traffic to second site when the following occurs:
a. Both DEAs go down. PXP will recognise this and tear down its associations with IPX
b. PXPs go down. IPX will notice that the associations have gone down and will switch to second site
3. Both Layer3 Switches go down
2.3 Failover Primary/Secondary Association:
This occurs and is managed by IPX under the following circumstances:
1. Should Primary connection between PXP and DEA go down, then the PXP will tear down its Primary
Association with IPX
2. PXP tears down its Primary Association with IPX
3. Physical network issue in the path tears down the Primary Association.
Page | 8
Diameter Firewall HA
3. Fail open
Fail-open is responsibility of IPX/Roaming Partner. There is no fail-open around the PXP solution should it go down,
i.e. In the unlikely event both PXPs on single site fail, IPX/RP will automatically fail over traffic to second site. Also,
if both PXPs on both sites fail, the IPX/RP should detect this and route around directly to DEA
4. Fail over Testing
4.1 IP fail over to standby PXP (node2) when
PXP service is down on active PXP (node1).
Description:
This test case is to test the both the VIPs failover to standby PXP node when per service
running on active PXP goes down.
Procedure:
1. Login to the active PXP (node1) and standby PXP (node2) and check the network
interface config (ifconfig -a).
Both the VIP addresses are assigned to the active node.
2. On the active PXP (node1), bring down the controller process first.
kill -9 <PID of controller process from pcf_Status.sh> as root user.
3. On the active PXP (node1), bring down the PXP service
service PXP stop as an adaptive user
4. Check the network interface config on both active (node1) & standby PXP (node2).
(ifconfig -a)
Both the VIP addresses are assigned to the standby node (node2).
5. On the node 1, start the PXP service
service PXP stop as an adaptive user
6. Check the network interface config on both active (node1) & standby PXP (node2).
(ifconfig -a)
Both the VIP addresses are assigned to the active node (node1).
Page | 9
Diameter Firewall HA
7. Start the controller –
pcf_Run.sh as adaptive user.
Expected Result:
The Keepalived assigns both the virtual IP addresses to the standby PXP (node2) incase
the PXP service goes down on active PXP (node1).
Actual Result: Pass/Fail*
Remarks:
Date/Time:
Witness:
Signature:
4.2 IP fail over to standby PXP (node2) when
network Interface on active PXP (node1)
goes down.
Description:
This test case is to test both the VIP failover to standby PXP node when any network
interface on active PXP goes down.
Procedure:
1. Login to the active PXP (node1) and standby PXP (node2) and check the network
interface config (ifconfig -a).
Both the VIP addresses are assigned to the active node.
2. On the active PXP (node1), bring down the interface bond2
Ifconfig bond2 down
3. Check the network interface config on both active (node1) & standby PXP (node2).
(ifconfig -a)
Both the VIP addresses are assigned to the standby node (node2).
4. On the node 1, bring up the interface bond2
Page | 10
Diameter Firewall HA
Ifconfig bond2 up
5. Check the network interface config on both active (node1) & standby PXP (node2).
(ifconfig -a)
Both the VIP addresses are assigned to the active node (node1).
6. Repeat the steps 2 to 5 with the interface bond3.
Expected Result:
The Keepalived assigns both virtual IP addresses to the standby PXP (node2) in case of
network interfaces goes down on active PXP (node1).
Actual Result: Pass/Fail*
Remarks:
Date/Time:
Witness:
Signature:
4.3 Ping (ICMP) fail over to standby PXP
(node2) when network Interface on active
PXP (node1) goes down.
Description:
This is the ping test on both active & standby PXP nodes when any network interface on
active PXP goes down.
Procedure:
1. Login to the active PXP (node1) and standby PXP (node2) and check the network
interface config (ifconfig -a).
Both the VIP addresses are assigned to the active node.
2. From switch, ping SIG1-VIP
3. Tshark trace on bond2 on both PXPs. Ping should come on PXP1.
4. Disable the bond2 interface on PXP1.
Ifconfig bond2 down
5. ICMP packets should be seen on PXP2 bond2
6. Up the bond2 interface on PXP1.
Page | 11
Diameter Firewall HA
Ifconfig bond2 up
7. ICMP packets should be seen on PXP1.
8. Repeat the steps 2 to 7 with the SIG2-VIP.
Expected Result:
The ping should be working from switch to the VIPs during the network interfaces down on
the active PXP.
Actual Result: Pass/Fail*
Remarks:
Date/Time:
Witness:
Signature:
Page | 12
