11/26/2014

DataPower: How to send logs to a remote syslog server

Well, here's my first post to this blog. From time to time, I'll try to share some things I learned over the past few years I'm enjoying working with DataPower. Thanks to Bruno Neves for inviting me to colaborate to this blog!

I will start with a little thing, so simple, but I consider it so important: to send DataPower log information to a remote server. Because we don't want to keep DataPower system logs in DataPower filesystem only, right? We never know when an appliance will crash!

DataPower offers a variety of options to send logs elsewhere. We can send them to a SOAP client, via email (SMTP), to a NFS system... Here, we will send log information to a syslog server. The key object to achive this is the Log Target object. It's located at default domain (of course, your user account must have the right privileges to deal with it).

Configure a syslog server


First things first! We need a syslog server, right? Here, I will show how to set up a syslog server in a machine running Ubuntu. It's quite simple using rsyslog service. First, you need to allow rsyslog to accept incoming syslog information from clients. For that, you have to change the rsyslog.conf file, as showed bellow:

$> sudo vi /etc/rsyslog.conf

Uncomment the lines that allow incoming traffic over UDP or TCP protocols. I chose TCP, so I remove comments from these lines below to allow traffic over TCP using port 514:

# provides TCP syslog reception
$ModLoad imtcp
$InputTCPServerRun 514

Now, we will define the file name pattern for our log files. I decided to store the files at /var/log/rsyslog/<datapower_name>, and they must be named with the date (year-month-day) plus DataPower name. So, I had to add the following lines to the end of the file:

$template DailyPerHostLogs, "/var/log/rsyslog/%HOSTNAME%/%$YEAR%%$MONTH%%$DAY%-%HOSTNAME%.log
dtp* -?DailyPerHostLogs

If you want to change the file name pattern, that's fine. Go to http://www.rsyslog.com/doc/master/configuration/properties.html and look for other options.

Now we have to allow the user syslog to write on our log directory:

$> sudo chown syslog:syslog rsyslog

Save these changes and restart rsyslog service:

$> sudo service rsyslog restart

Configure a Log Target on DataPower


Now it's time to setup a syslog client on DataPower, by creating a new Log Target object. I will explain how to do that via Web GUI. Later you can play around and try to do that with SSH or XML.
  • On default domain, look for "Log Target" or go to Objects > Logging Configuration > Log Target;
  •  A list of Log Targets will be displayed. You must have at least one, the default-log object, which throws log entries to the default system log. Don't change it, unless you really know what you're doing! Click Add to create a new object;
  • Change the following properties:
    • Name: it's the name of the object. I named it "Syslog-LogTarget" (you can go with anything else);
    • Target Type: select "syslog-tcp";
    • Local IP Address: the IP address of your DataPower device. In my case, it's "192.168.75.128" (which is set up in a Host Alias object);
    • Local Identifier: identifies who's sending the log info for the syslog server. I went with"dtp6";
    • Remote Host: the IP address where the syslog server is running. For me, it's "192.168.75.133";
    • Remote Port: the port where the syslog server is running. It should be "514", unless you set up a different port on rsyslog.conf file;
Log Target configuration with syslog-tcp as target type
  • We also have to define what type of info will be sent to our syslog server. Go to the Event subscriptions tab. A list of events must be provided. Here, we will send all types of information, with a log level of "notice". You may want to have a more filtered log. If you do, select different events;
Adding event subscriptions to Log Target

  • Save these changes (by clicking Apply).

At this point, you should start seeing your logs being sent to your syslog server. You will notice that the file is named with the date stamp and your DataPower identifier.

$> cd /var/log/rsyslog/dtp6
$> ls
20141125-dtp6.log

Now, use tail -F * while interacting with DataPower and watch the magic happen.

I hope this helps. Let me know your thoughts. Feel free to comment here.

Cheers!

10/20/2014

DataPower: The Interoperability Test Service

Hate having to create an XML Firewall service configured as loopback every time you want to test a single stylesheet using DataPower extension functions? Well, you may have more options available to you…

Since version 5.0, IBM released a capability called Interoperability Test Service (IOP). One of the features this mode supports is the ability to listen to requests containing a stylesheet file along with its equivalent request, then it processes the instructions present on the stylesheet against its request, and finally sends the output of the stylesheet back as the result.

To use the IOP, you first need to enable the service at Objects > Device Management > Interoperability Test Service.

For the second step, you will need a client to send requests to the service you have just enabled. IBM thinking about on making our lives easier, made available two clients that can be found at Resource Kit 5.0.

After downloading it, just extract it to your local file system, and then refer to the files DPInteropClient.jar or dp-interop-client.sh (depending on your preference, operating, system, etc).

The Resource Kit 5.0 comes with some samples that can be used for testing. The first scenario we will cover here will be the conversion of an XML file into the base 64 by using the dp:encode extension function:

The XML message to be converted to base 64
$ cat message.xml
<msg>Hello World!</msg>

The XSLT used to encode the message into base 64
$ cat toBase64.xsl
<xsl:stylesheet version="1.0" 
  xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
  xmlns:dp="http://www.datapower.com/extensions"
  extension-element-prefixes="dp">

  <xsl:template match="/">
    <xsl:value-of select="dp:encode(., 'base-64')"/>
  </xsl:template>
</xsl:stylesheet>

The IOP client sending both the XSLT and message to be encoded along with the result from DataPower:
$ ../../clients/dp-interop-client.sh -x toBase64.xsl -i message.xml -h [dphostname] -p [port]
>> Creating the XSLT request...
>> Sending the request to http://dphostname:port/
>> No basic authentication is provided.
SGVsbG8gV29ybGQh

Another interesting feature available is the ability to test XPath syntaxes. For example, take into account the following XML (not included in the Resource Kit):

$ cat bookstore.xml 
<?xml version="1.0" encoding="UTF-8"?>
<bookstore>
<book category="COOKING">
<title lang="en">Everyday Italian</title>
<author>Giada De Laurentiis</author>
<year>2005</year>
<price>30.00</price>
</book>
<book category="CHILDREN">
<title lang="en">Harry Potter</title>
<author>J K. Rowling</author>
<year>2005</year>
<price>29.99</price>
</book>
<book category="WEB">
<title lang="en">XQuery Kick Start</title>
<author>James McGovern</author>
<author>Per Bothner</author>
<author>Kurt Cagle</author>
<author>James Linn</author>
<author>Vaidyanathan Nagarajan</author>
<year>2003</year>
<price>49.99</price>
</book>
<book category="WEB">
<title lang="en">Learning XML</title>
<author>Erik T. Ray</author>
<year>2003</year>
<price>39.95</price>
</book>
</bookstore>

Now use the following XPath expression against it (this expression will select the title and price of all books on the category "WEB" that are priced above 39.95:

/bookstore/book[@category=\"WEB\" and price>39.95]/(title|price)

To apply the above XPath expression to the IOP client command, use the following:

$ ../../clients/dp-interop-client.sh -t xpath -e "/bookstore/book[@category=\"WEB\" and price>39.95]/(title|price)" -i bookstore.xml -h [dphostname] -p [port]
>> Creating the XPath request...
>> Sending the request to http://dphostname:port/
>> No basic authentication is provided.
Found 2 nodes:
-- NODE --
<title lang="en">XQuery Kick Start</title>
-- NODE --
<price>49.99</price>

Cool, huh?

Besides XSLT and XPath testing, you can also use this tool to test FFD requests and perform schema validation. For more details, refer to the Interoperability Test Service page at the DataPower Information Center.

I remember that in the past, there used to be a DataPower plugin for Eclipse that enabled you to do practically the same stuff, but for some reason I think it was discontinued by IBM. Have you ever heard of it? Had a chance to use it? How do you compare it with this new method available?

DataPower: No more XG45, XI52, XB62 and XI50B

You read it correctly folks, as of November 21st, 2014, there will be no more DataPower Service Gateway XG45, no more DataPower Integration Appliance XI52, and no more DataPower B2B Appliance XB62. No reason to be scared though, even with that scary headline I put on purpose (I am sorry about that).

As usual, every October IBM releases some news regarding the next firmware version that becomes available every November. This time IBM announced the firmware version 7.1 and with it, its intention to unify the family of appliances into a single product, the IBM DataPower Gateway.

The IBM DataPower Gateway will come equipped with the same functions the current XG45 comes with. If advanced functions are needed, such as B2B features available only on the current XB62, a software module can be installed to satisfy the requirement.

This is actually good news for companies that already have XG45 and/or XI52 appliances and were planning to acquire more appliances to support B2B functions. With the version 7.1, it will now be possible to install the new software module on the current appliances and take advantage of the B2B functions previously available only on the XB62 appliances.

The DataPower family of appliances is downsizing again, in both models and colors (remember the good times?). From the green XA35, the yellow XS40, the blue XI50, the purple XB60, and the silver XM70, passing through the XG45, XI52, XB62, all black, to only one Gateway Appliance now (color TBD, but I can bet it will be black as well). In spite of that, no feature was left behind, every thing that could be done a few years back can still be done on the current offerings, and that is what really matters for us, DataPower lovers.

Please refer to the official IBM Announcement describing the new offerings in details.

7/16/2014

IIB: WebSphere MQ no longer required to run IBM Integration Bus

As you may know, the IBM Integration Bus is the successor of the WebSphere Message Broker. You may also know that to install the WebSphere Message Broker you also need to install a copy of the WebSphere MQ. And this is also true for the latest final version of the IBM Integration Bus, the version 9.

What you may not know is that the upcoming version of the IBM Integration Bus, the version 10, will no longer require a pre-installation of the WebSphere MQ, based on the current version of the IBM Integration Bus, the V10 Open Beta.

WebSphere MQ license is still part of the IBM Integration Bus package, but its installation will be required in only a few cases, such as when you want to use an MQ Input or MQ Output nodes in one of your flows.

To see what else is new in this fairly new version, you can refer to the latest release notes of the product published by IBM back in May.

6/16/2014

DataPower: IBM technotes are now providing GatewayScript sample code in addition to XSLT

With the recent release of the GatewayScript for the DataPower family of appliances, IBM is now writing technotes that, in addition to XSLT, also contain a sample of code for the new GatewayScript format.

An example of this, would be a technote published last week that describes how to remove the Content-Type header that DataPower automatically adds to the responses. For the XSLT example they provided the following solution:

<xsl:template match="/">
 <dp:remove-http-response-header name="Content-Type"/>
</xsl:template>


Now for the GatewayScript, the following code was provided:

var hm = require('header-metadata');
hm.current.remove('Content-Type');


For experienced DataPower developers, the first solution seems simpler, as it requires only one line of code to perform that action (ignoring of course the opening and closing of the <xsl:template> element).

The GatewayScript solution though, may look simpler for those used to the JavaScript language, which the GatewayScript is based on.

What would have been your choice if you were assigned to solve this issue? XSLT or GatewayScript?

5/13/2014

DataPower: Meet the new features that will be available on firmware V7.0

We are exactly one month away from the general availability of the new DataPower firmware V7.0. Although we have already mentioned the capability that will change the course of our lives forever (just kidding), the new firmware will also bring to the table many other cool features that many clients have been asking as enhancements, like the following:
  • A dedicated virtual appliance edition for developers
  • SFTP support for XG45
  • GatewayScript (JavaScript enablement in the processing policy)
  • Improved API Management
  • Network Link Aggregation for redundancy and increased throughput
  • WebSocket Proxy for low-latency communication
  • Support for Sterling Multi-Enterprise Integration Gateway (MEIG)
  • GTID or Global Transaction ID to ease troubleshooting of chained services
  • Citrix XenServer support for additional deployment flexibility

Yesterday IBM released a new slide deck detailing each of the new features. Highly recommended if you/your company have been waiting for any of these features to be available.

5/08/2014

DataPower: 5 secrets that you may not have known

Okay, let's go straight to the point, starting with a few questions:
  1. Is it possible to disable a Multi-Protocol Gateway or a Web Service Proxy?
  2. Is it possible to export a certificate from the cert: directory?
  3. Is it possible to increase the number of transactions in the probe history?
  4. Can a Front Side Handler object be created automatically when creating a Web Service Proxy?
  5. Can a service have higher priority over others?

You might have answered yes to at least one of these questions, but would you be surprised if I told you that the answer for every single one is yes?

Follow the link below to see more details about each of the secrets above.

4/15/2014

DataPower: What to expect from the new GatewayScript?

GatewayScript is what is called a new capability that will be available in the upcoming DataPower firmware version 7.0. A lot of attention has been put into this topic recently and it will be present in at least four different presentations at Impact 2014 by the end of this month.

The GatewayScript expands the number of programming languages currently available in DataPower. GatewayScript is completely based on JavaScript language and brings to the table all the power that its base language has to offer.

It does not mean that the available programming languages, such as XSLT and XQuery, were lacking power. The main idea on bringing a new programming language to the table is to leverage common programming skills, speeding up DataPower adoption and making it even more popular.

New ways to debug code have also been made available for the GatewayScript functionality, making it possible to add break points, print variable values, explore stack trace, etc.

Performance is not supposed to be an issue with the new available language, as the code will be compiled, cached and reused on demand. IBM keeps promising wire-speed for processing.

Examples will be provided with the new firmware in order to give us a better idea on what exactly can be accomplished with this new capability. They will be located under store:///gatewayscript/example-*.js.

In the morning of April 15th, Tony Ffrench (STSM DataPower Architect), Tim Smith (DataPower Architect) and Ozair Sheikh (DataPower Product Line Manager), gave a very rich presentation at the WebSphere User Group website, about the new capabilities that will be available on the new firmware version. If you did not have a chance to attend to this webinar, you can download the presentation used by them right here.

To see the official IBM announcement of the new firmware version 7.0, click here.

EDIT: On April 17th, the replay of the above presentation has been made available by the WebSphere User Group website. To watch it, just click here.

The IBM Integration Middleware and the Heartbleed exploit

Wondering if the IBM Integration Middleware is affected by the Heartbleed exploit? Good news for you! In general the answer is no, but there are exceptions...

According to the official IBM Security Bulletins released so far, Cast Iron version 7.x and two MQ Support Pacs are affected. The recommendation for people who work with any of these tools is to keep watching the IBM Support Portal as well as the IBM Product Security Incident Response Team (PSIRT) for more security bulletin updates.

See the official IBM Security Bulletins for each technology:

Besides the need of reissuing certificates that may have been compromised, there should also be an effort to revoke them. Imagine revoking and reissuing new certificates for 66% of the Internet... The Certificate Authorities might be laughing really loud by now with this unforeseen profit about to enter their books...

4/06/2014

DataPower: How to configure SSL mutual authentication?

That should be a mandatory question when interviewing a DataPower candidate if you want to give him/her a hard time. I can say that most of them will fail to answer it correctly based on my experience in the field.

It is not entirely their fault though. The way that DataPower presents the objects responsible for configuring mutual authentication can be tricky if you are trying to learn it by yourself.

The main reason that could lead us, DataPower professionals, to a confusion is the fact that the SSL Proxy Profile object has a parameter called “Direction” that can be set as “Forward”, “Reverse” and “two-way”. 

Is “two-way” and mutual authentication the same thing?


The first impression is that the “two-way” option could be a representation of mutual authentication, it is because the definition of mutual authentication suggests that both client and server authenticate to each other, or in other words, they perform two-way authentication.

Although it could make sense, setting the direction to “two-way” has nothing to do with the set up of mutual authentication. SSL mutual authentication is independent of the SSL Proxy Profile direction parameter. You can perfectly have mutual authentication using Forward or Reverse as the direction, there is nothing wrong with that.

The “two-way” direction simply enables DataPower to act as a client or server using a single SSL Proxy Profile. And that is all, no mutual authentication here!

But then how to configure mutual authentication in the box, device, appliance (or whatever you may call it)? The answer is, as usual: it depends…

DataPower acting as Server


If DataPower is acting as the server and you want it to authenticate the client certificate, you can set the direction parameter of the SSL Proxy Profile to “Reverse”, and then on the Reverse Crypto Profile, you have to set up a Validation Credential that will contain a copy of the client certificate (or root CA) to be validated against.

Ah, now it starts to make sense on why the Validation Credential is not a required parameter on the Reverse Crypto Profile, and it is just because mutual authentication is not always required for SSL traffic.

08/25/2015 UPDATE: This is actually the most basic way to configure the Reverse Crypto Profile to authenticate its clients. There are many variations to this configuration and depending on your requirement, you can make your mutual authentication scenario mandatory or optional.

See below some variations of all the possible configurations and an explanation of each scenario:

Scenario 1:
Reverse Crypto Profile WITH ValCreds
Client Authentication is Optional OFF
Always Request Client Authentication OFF
Results:
Client certificate is required because of the ValCreds configured in the Reverse Crypto Profile. Authentication is performed by the ValCreds. If certificate is not provided, the SSL handshake will fail because the option Client Authentication is Optional is set to OFF.
Mutual Authentication is mandatory.


Scenario 2:

Reverse Crypto Profile WITH ValCreds
Client Authentication is Optional OFF
Always Request Client Authentication ON
Results:
Client Certificate is required because of the ValCreds configured in the Reverse Crypto Profile. Authentication is performed by the ValCreds. If certificate is not provided, the SSL handshake will fail because the option Client Authentication is Optional is set to OFF.
Mutual Authentication is mandatory.


Scenario 3:
Reverse Crypto Profile WITH ValCreds
Client Authentication is Optional ON
Always Request Client Authentication OFF
Results:
Client certificate will be asked because of the ValCreds configured in the Reverse Crypto Profile. If provided, authentication will be performed by the ValCreds. If certificate is not provided, the connection will still be established because the option Client Authentication is Optional is set to ON.
Mutual Authentication is optional.


Scenario 4:
Reverse Crypto Profile WITH ValCreds
Client Authentication is Optional ON
Always Request Client Authentication ON
Results:
Client certificate will be asked because of the ValCreds configured in the Reverse Crypto Profile. If provided, authentication will be performed by the ValCreds. If certificate is not provided, the connection will still be established because the option Client Authentication is Optional is set to ON.
Mutual Authentication is optional.


Scenario 5:
Reverse Crypto Profile WITHOUT ValCreds
Client Authentication is Optional OFF
Always Request Client Authentication OFF
Results:
Client certificate is not required because there is no ValCred set in the Reverse Crypto Profile and the option Always Request Client Authentication is set to OFF.
Mutual Authentication is not enabled.


Scenario 6:
Reverse Crypto Profile WITHOUT ValCreds
Client Authentication is Optional OFF
Always Request Client Authentication ON
Results:
Client Certificate is required because the option Always Request Client Authentication is set to ON. Authentication will be performed by the Processing Policy. If certificate is not provided, the SSL handshake will fail because the option Client Authentication is Optional is set to OFF.
Mutual Authentication is mandatory.


Scenario 7:
Reverse Crypto Profile WITHOUT ValCreds
Client Authentication is Optional ON
Always Request Client Authentication OFF
Results:Client certificate is not required because there is no ValCred set in the Reverse Crypto Profile and the option Always Request Client Authentication is set to OFF.
Mutual Authentication is not enabled.


Scenario 8:
Reverse Crypto Profile WITHOUT ValCreds
Client Authentication is Optional ON
Always Request Client Authentication ON
Results:Client certificate will be asked because the option Always Request Client Authentication is set to ON. Authentication will be performed by the Processing Policy. If certificate is not provided, the SSL connection will be established as the option Client Authentication is Optional is set to ON, however the authentication may fail during the Processing Policy.
Mutual Authentication is optional.


DataPower acting as Client


Now, when DataPower is acting as Client, it is a different story… For this case, you are going to choose the direction “Forward” on the SSL Proxy Profile and then on the Forward Crypto Profile you will have to set an Identification Credential object to force DataPower to identify itself to the backend it is calling. Simple like that!

At this point, you might also have noticed that in the Forward Crypto Profile, the Identification Credential parameter is not required, once again because mutual authentication is not always required to SSL traffic.

Why then SSL Proxy Profile “two-way”?


So, you could be asking yourself now, why in earth do we have the option of “two-way” direction in the SSL Proxy Profile, is it just to confuse us?

Well, there is actually a plausible reason for that… Some of us fight everyday to keep our DataPower configuration as simple as we can, having this “two-way” option allow us to have a single SSL Proxy Profile referring to one Reverse Crypto Profile and one Forward Crypto Profile at the same time. It basically means less objects to be configured, yay!

Once all of them are configured correctly, you will never have to worry about which crypto object to select in order to allow a front or backside connection to be established properly, as the “two-way” object will automatically select the correct Crypto Profile (Forward or Reverse) to use according to the direction of the transaction.

So now, if you had a chance to give a different name for the “two-way” direction of the SSL Proxy Profile, what would that be?

06/23/2015 UPDATE: As of firmware version 7.2, DataPower is deprecating the Proxy Profile object. This object must be replaced by the SSL Server Profile or the SSL Client Profile, depending on whether DataPower is acting as a server or as a client. In addition to these two objects, there is a new object called SSL SNI Server Profile, which enables the SNI (Server Name Indication) feature. In short, the SNI feature on the SSL Client Profile will send the intended host name as part of the SSL handshake process with the server, so that the SNI-enabled server can select which certificate it should return to the client, given that the server is hosting multiple domains in the same IP and port combination.

For more information on the SNI feature, go to https://en.wikipedia.org/wiki/Server_Name_Indication.
For more information on the new SSL Client Profile, go to https://www.youtube.com/watch?v=nMud8cnd56w.
For more information on the new SSL Server Profile and the new SSL SNI Server Profile, go to https://www.youtube.com/watch?v=14DPPjl4u5w.

DataPower: Testing SNMP using ManageEngine MibBrowser

Not sure if you are already aware of this tool, but it helped me a lot to prove whether DataPower was correctly configured for both SNMP Polling and Trap. The name of this tool is MibBrowser from the company ManageEngine, it is free and can be used to browse the DataPower MIB files, extract any information from the box (SNMP Polling) as well as can be used as a lightweight SNMP server to listen to the SNMP traps sent by the device. See the images below for details: 

1. SNMP Polling


https://images-blogger-opensocial.googleusercontent.com/gadgets/proxy?url=http%3A%2F%2F1.bp.blogspot.com%2F-ZTyiDb4eNC4%2FU0D_LGFPhSI%2FAAAAAAAADl0%2FTWw02jKlRYA%2Fs1600%2FMibBrowser1.PNG
 

2. SNMP Traps


http://3.bp.blogspot.com/-SCepMs82RS0/U0EBt2n6pSI/AAAAAAAADmE/fKeKLUO1Y14/s1600/MibBrowser2.PNG


To download it, just go to http://www.manageengine.com/products/mibbrowser-free-tool/index.html

This company seems to have some other interesting free networking tools, see the link below for the full list: 

http://www.manageengine.com/free-software-download.html?plink=mibB 

By the way, talking about other free tools, I have been using other two that have helped me in some matters, one of them is for keys/certificates management and the other is for LDAP browsing: 

Portecle - Extracts and converts keys and certificates - http://portecle.sourceforge.net/ 
ADExplorer - Connects to a LDAP server so you can verify every single LDAP object - http://technet.microsoft.com/en-us/sysinternals/bb963907.aspx 

Do you guys use any other tools to help somehow performing your day to day work?

DataPower: Static routes and management interface

(Read the whole article before making any changes to your environment)

I wanted to share with you some of my experience when configuring the DataPower appliances from scratch.

As you know, during the DataPower initialization process, there is a wizard available that will make the initial configuration a lot easier. That wizard asks you a few questions about your network and then directs you to the WebGUI, so you can accept the license terms. Most of the times, since the WebGUI is already up and running, people will never come back to the configuration of the management interface to adjust it as they should, in order to avoid unexpected behaviors in the future. But what adjustment am I talking about here?

The static route of course! Right, you do not need to configure it in order to make the WebGUI or any other management service, such as SSH and SOMA, to work fine, however you do need to adjust it in order to prevent DataPower from using such interface for application data traffic.

The trick here is the following, whenever you see a default route configured for the management interface, you may be under the risk of DataPower not behaving the way you are expecting it to. For example in this case:

xg45# show route
 Destination       Device Int Type Device Int Gateway       Metric Route Type Route Protocol
 -----------       --------------- ---------- -------       ------ ---------- --------------
 0.0.0.0/0         Ethernet        mgt0       10.206.137.1  0      remote     netmgmt
 0.0.0.0/0         Ethernet        eth11      10.206.137.1  0      remote     netmgmt
 10.206.137.0/24   Ethernet        mgt0       0.0.0.0       0      local      local
 10.206.137.0/24   Ethernet        eth11      0.0.0.0       0      local      local


The destination 0.0.0.0/0 is the default route. As you can see, there are two default routes in the example above, one being used by the mgt0 interface and the other being used by the eth11. The default route is added to the routing table every time that there is a default gateway defined in the interface. So as soon as you remove the default gateway, the default route will disappear from the route table:

xg45# show route
 Destination       Device Int Type Device Int Gateway       Metric Route Type Route Protocol
 -----------       --------------- ---------- -------       ------ ---------- --------------
 0.0.0.0/0         Ethernet        eth11      10.206.137.1   0     remote     netmgmt
 10.206.137.0/24   Ethernet        mgt0       0.0.0.0        0     local      local
 10.206.137.0/24   Ethernet        eth11      0.0.0.0        0     local      local


By removing that, you are explicitly telling DataPower to never use the management interface for any outbound traffic. It also means that, as soon as you remove the default gateway, you *may* lose access to the box, as it will not know how to reply back to you [if you are not on the same subnet of the device (/24) or the management service is not configured for all network interfaces (0.0.0.0)]. Technically you are not really losing access, your requests are reaching the box, but the box does not know how to get back to you.

So, how to fix that? By adding a static route is the answer. Before removing the default gateway details from the management interface configuration, make sure to configure a static route that will teach the box how to reach you back.

If your terminal is configured with static IP address and you want to restrict the DataPower management interface to talk only to you, the following command should do the trick:

xg45(config-if[mgt0])# ip route 10.206.14.160/32 10.206.137.1

<ip route> invokes the command to create the static route
<10.206.14.160/32> is the final destination of the responses, or the IP address of your terminal
<10.206.137.1> is the network gateway to be used to reach the final destination


And the final result:

xg45(config-if[mgt0])# show route
 
Destination       Device Int Type Device Int Gateway       Metric Route Type Route Protocol
 -----------       --------------- ---------- -------       ------ ---------- --------------
 0.0.0.0/0         Ethernet        eth11      10.206.137.1   0     remote     netmgmt
 10.206.14.160/32  Ethernet        mgt0       10.206.137.1   0     remote     netmgmt
 10.206.137.0/24   Ethernet        mgt0       0.0.0.0        0     local      local
 10.206.137.0/24   Ethernet        eth11      0.0.0.0        0     local      local


As you can see above, the configuration of the final destination uses the CIDR notation. The /32 means that such static route will only work for such specific IP address (subnet mask 255.255.255.255). If you want to configure a static route to reach an specific subnet, you can use different CIDRs to accomplish it. For example, you know that a specific subnet is safe and want to allow all terminals on that subnet to manage the box, you could use 10.206.14.0/24 (subnet mask 255.255.255.0).

Now going back to the unexpected behaviors we mentioned earlier, when there is more than one default route, there is no default route, makes sense? :-) With that said, if no static route is configured, DataPower will randomly select any ethernet interface that has a default route set up and you will start seeing application data traffic coming out of the management interface, and management traffic coming out of the application data interface at random basis. Sometimes you are going to experience intermittent connectivity issues, as the gateway configured for the management interface may not know how to route the request to the application backend and vice-versa.

In addition to what has been discussed so far, static routes can do much more! For example, you may want to use one of the various ethernet interfaces available in the appliance to segment traffic to different networks, but this a topic for another post. :-) 

Reference: IBM WebSphere DataPower SOA Appliance Handbook - http://www.amazon.com/IBM-WebSphere-DataPower-Appliance-Handbook/dp/0137148194