Oracle EBS WebLogic: Troubleshooting Security:090220 Rule 2 Connection Rejection

You receive a call: WebLogic requests are being rejected.

The error appears in the logs:

[Socket:000445]Connection rejected, filter blocked Socket,
weblogic.security.net.FilterException:
[Security:090220]rule 2

At first, you might start checking WebLogic authentication, AdminServer credentials, or database connectivity.

Don’t start there.

The exception is already giving you a very strong clue about where to investigate.

The Error Tells the Story

The important part is:

weblogic.security.net.FilterException
[Security:090220]rule 2

Oracle documents BEA-090220 as:

A connection filter rule denied access.

In other words, WebLogic is rejecting the connection because of a configured connection-filter rule.

This is different from an authentication failure.

The request is reaching the WebLogic server, and the connection filter is evaluating the incoming connection.

What Is a WebLogic Connection Filter?

WebLogic connection filters provide a network-level access-control layer.

They can be used to control which clients are permitted to connect to a WebLogic Server instance. Oracle describes connection filters as an additional security layer that can restrict access at the network level.

A simplified flow looks like this:

Client
   |
   v
WebLogic Listener
   |
   v
Connection Filter
   |
   +---- ALLOW ----> Continue processing
   |
   +---- DENY -----> Connection rejected

This is why an error such as:

Connection rejected, filter blocked Socket

is so useful during troubleshooting.

Understanding Security:090220 Rule 2

This is where we need to be precise.

WebLogic evaluates connection-filter rules in the order in which they are configured.

The first matching rule determines whether the connection is allowed or denied. If no rule matches, the connection is permitted by the default filter implementation.

For example:

Rule 1: 192.0.2.11 * * allow
Rule 2: 192.0.2.12 * * allow
Rule 3: 0.0.0.0/0 * * deny

If a connection matches Rule 3, WebLogic reports:

[Security:090220]rule 3

Therefore:

rule 2 identifies the connection-filter rule associated with the rejection reported by WebLogic. Always inspect the actual configured rule sequence rather than assuming it is the catch-all deny rule.

Where Is the Configuration?

For Oracle E-Business Suite Release 12.2, the WebLogic connection-filter configuration can be found in:

$DOMAIN_HOME/config/config.xml

Oracle’s EBS documentation shows the connection-filter configuration in this file.

For example:

<connection-filter>weblogic.security.net.ConnectionFilterImpl</connection-filter>

<connection-filter-rule>192.0.2.11 * * allow</connection-filter-rule>

<connection-filter-rule>192.0.2.12 * * allow</connection-filter-rule>

<connection-filter-rule>0.0.0.0/0 * * deny</connection-filter-rule>

In an EBS environment you may also see an EBS-specific connection-filter implementation, such as:

<connection-filter>oracle.apps.ad.tools.configuration.wls.filter.EBSConnectionFilterImpl</connection-filter>

If that is what your environment is using, don’t replace the filter class just because you are troubleshooting a rule. Focus on the configured rules.

Check the Rules Before Changing Anything

First inspect the actual configuration:

cd $DOMAIN_HOME/config

grep -n -A10 -B5 "connection-filter" config.xml

You want to establish:

• Which connection-filter implementation is configured?
• What are the connection-filter rules?
• Which source IP is making the connection?
• Which rule is actually denying the connection?
• Is the source IP supposed to be allowed?

This is much better than immediately changing the filter to allow.

Always Back Up config.xml

Before making any manual configuration change:

cd $DOMAIN_HOME/config

cp -ip config.xml config.xml_$(date +%Y%m%d_%H%M%S).bak

If this is an EBS environment, also consider the run/patch filesystem implications before making a change that needs to persist through online patching. Oracle’s EBS documentation notes that configuration changes on the run filesystem are propagated to the patch filesystem during fs_clone.

Don’t Confuse This With Basic Authentication

While reviewing config.xml, you may encounter:

<enforce-valid-basic-auth-credentials>
    false
</enforce-valid-basic-auth-credentials>

It is tempting to associate this with every WebLogic security-related error.

But BEA-090220 specifically indicates that a connection-filter rule denied access.

Therefore, for this particular error, the first investigation should be:

Security:090220
       ↓
Connection Filter
       ↓
Connection Filter Rules
       ↓
Source IP / Port / Protocol

rather than Basic Authentication.

A Typical Configuration

Oracle’s EBS documentation provides examples such as:

<connection-filter-rule>192.0.2.11 * * allow</connection-filter-rule>

<connection-filter-rule>192.0.2.12 * * allow</connection-filter-rule>

<connection-filter-rule>192.0.2.100 * 17001 allow https</connection-filter-rule>

<connection-filter-rule>0.0.0.0/0 * * deny</connection-filter-rule>

The final rule:

0.0.0.0/0 * * deny

acts as a catch-all deny.

Oracle specifically documents this pattern: allow the required sources first, then use 0.0.0.0/0 * * deny as the final rule so that all other sources are rejected.

The Incident Scenario

In our case, the error was:

[Socket:000445]Connection rejected, filter blocked Socket,
weblogic.security.net.FilterException:
[Security:090220]rule 2

During the investigation, we reviewed the WebLogic configuration and traced the rejection back to the connection-filter rules.

The important distinction was:

WebLogic is running
        |
        v
Request reaches WebLogic
        |
        v
Connection filter evaluates request
        |
        v
Configured rule denies connection
        |
        v
Security:090220

That changed the direction of the investigation immediately.

Resolution

Once the offending rule has been identified, there are two approaches.

Option 1 — Correct the Allow Rule

This is the preferred approach.

For example, if the trusted WebLogic client is:

192.0.2.50

the configuration could contain:

<connection-filter-rule>192.0.2.50 * * allow</connection-filter-rule>

<connection-filter-rule>0.0.0.0/0 * * deny</connection-filter-rule>

The important point is that the allow rule must appear before the catch-all deny rule.

Option 2 — Temporary Troubleshooting Workaround

In a controlled troubleshooting situation, changing:

0.0.0.0/0 * * deny

to:

0.0.0.0/0 * * allow

can be used to confirm that the connection filter is the cause of the problem.

However, this effectively removes the intended network restriction.

So: Use this as a diagnostic/workaround step, not as the preferred permanent production configuration.

Oracle’s documented security model is to allow the required sources and retain a final deny rule.

If Manually Editing config.xml

If you are manually modifying the domain configuration rather than using the WebLogic Administration Console, perform the change under your environment’s standard configuration-management procedure and ensure the Administration Server is not concurrently modifying the file.

For a controlled manual change, the practical sequence is:

Stop AdminServer
      |
      v
Backup config.xml
      |
      v
Review current connection-filter rules
      |
      v
Make the required change
      |
      v
Validate config.xml
      |
      v
Start AdminServer
      |
      v
Monitor logs
      |
      v
Retest the connection

Oracle also supports configuring connection filters through the WebLogic Administration Console and then activating the configuration and restarting as required.

Troubleshooting Decision Tree

When you encounter:

[Socket:000445]Connection rejected, filter blocked Socket
weblogic.security.net.FilterException
[Security:090220]rule N

use this approach:

                 WebLogic Request
                       |
                       v
              WebLogic reachable?
                       |
                      YES
                       |
                       v
             Check exact exception
                       |
                       v
          weblogic.security.net
             FilterException?
                       |
                      YES
                       |
                       v
              Security:090220?
                       |
                      YES
                       |
                       v
       Review connection-filter rules
                       |
                       v
          Identify rule N
                       |
                       v
        Identify source IP/port/protocol
                       |
                       v
          Does the rule allow it?
                 /          \
               YES          NO
                |            |
                v            v
        Investigate next   Correct the
             layer          filter rule

Key Takeaways

1. Read the exception literally — FilterException is a major clue.
2. Security:090220 means a connection-filter rule denied access — Oracle explicitly documents BEA-090220 this way.
3. Rule ordering matters — The first matching rule determines the result.
4. rule 2 is not automatically the catch-all deny — Check the actual rule list before making assumptions.
5. 0.0.0.0/0 * * deny is normally a catch-all restriction — It should generally come after the required allow rules.
6. Don’t use a global allow as the permanent fix — If the issue is caused by a missing source IP rule, add the required source rather than permanently opening the filter.

Final Thought

One of the most useful troubleshooting skills in middleware administration is learning to read the error as a diagnostic path.

Consider the original message:

[Socket:000445]
Connection rejected,
filter blocked Socket,
weblogic.security.net.FilterException:
[Security:090220]rule 2

Break it down:

Connection rejected
        ↓
Filter blocked Socket
        ↓
WebLogic Connection Filter
        ↓
BEA/Security 090220
        ↓
Connection-filter rule denied access
        ↓
Check the actual rule identified by the error

Instead of treating it as another generic WebLogic failure, the error points us directly toward the connection-filter configuration.

Read the error carefully. Sometimes the error message has already told you where the problem is.