cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2487
Views
0
Helpful
4
Replies

Interface used for connection to external quarantine

dbucher
Level 1
Level 1

Hi all,

I have a setup with 3 C6xx and a M1070 used as an external quarantine.

On each C6xx there are a couple of interface defined for different mail domain, as relaying interfaces etc.

I defined the three C6xx with ssh-enabled interfaces in the management appliance. As long as I choose this interface as the default mail delivery interface on the C6xx machines (using the CLI and the deliveryconfig command) all is fine.

But if I change the mail delivery interface on the mail appliances, I get errors because the appliances cannot connect to the external quarantine anymore (which sound plausible to me, since the connection occurs now from the wrong IP).

Two solutions might possibly solve this (beside from changing the IP of the mail security aplliances on the mangement appliance each time I change the delivery interface):

a) add additional IP-adresses to the defined mail security appliances on the M1070. Is that possible ? I couldn't find anything on that (maybe this should end up in a feature request).

b) configure an different delivery interface for sending mails to the external quarantine on the C6xx appliances. This could possibly be done via message filters and the alt-src-host action.  Any idea of how to do this ?

Thanx in advance,

Damian

4 Replies 4

Andreas Mueller
Level 4
Level 4

Hi Daiman,

easiest way you can do that is with the altsrchost command on the CLI, where you can specify an interface for any specific destination IP - in your case the IP of your quarantine

> altsrchost

Choose the operation you want to perform:

- NEW - Create a new mapping.

- IMPORT - Load new mappings from a file.

[]> new

Enter the Envelope From address or client IP address for which you want to set up a Virtual Gateway(tm) mapping.  Partial

addresses such as "@example.com", "@.com", "user@", or "user@.com" are allowed.

[]> 192.168.1.2

Which interface do you want to send messages for 192.168.1.2 from?

1. Management (10.10.10.10/26)

2. Data 1 (10.10.20.10/24)

[1]>

Hope that helps,

Andreas

Hi Andreas,

unfortunately this is not working as expected since it uses the source IP address and not the destination (at least that's what the documentation under "Using Virtual Gateway Technology" says:

The system can match any of the following keys and take preference in the following order:

Sender’s IP address

The IP address of the sender must match exactly.

Example: 192.168.1.5

Fully-formedEnvelope Sender

The Envelope Sender must match the entire address exactly.

Example: username@example.com

Username

The system will match username syntax against theEnvelope Sender address up to the @ sign. The @ sign must be included. Example: username@

Domain

The system will match domain name syntax against theEnvelope Sender address starting with the @ sign. The @sign must be included. Example: @example.com

).

Irritatingly from the CLI dialog one would expect that it uses the destination IP ("Which interface do you want to send messages for  192.168.1.2").

My tests showed that the documentation in this case is correct (aka the source IP is used).

Best regards,

Damian

gregskigregski
Level 1
Level 1

Damian Bucher wrote:


a) add additional IP-adresses to the defined mail security appliances on the M1070. Is that possible ?

Not possible to have multiple IP addresses added for a C series on the M Series under Security Appliances, we ran into this earlier this week and had an Iron Port engineer on the phone with us when we tried and it would not allow it.

We have the same setup, where our ESAs have multiple IP addresses, and the IP addresses used for transferring tracking/reporting/SLBL data are not the same as the addresses used for spam deliveries to the centralized EUQ.

 

Through quite a bit of trial-and-error, we discovered that you *can* work around the issues this causes by tweaking the XML config on the SMA, and manually adding the extra ESA IP addresses in the right place.  Whether or not this workaround is supported by Cisco is another question, so read on at your own risk...

 

To start, download the XML config from your SMA to a file (don't mask passwords so you can re-import later), and make a backup copy of it before changing anything.  Then, look for a section like the following:

 

<euq_quarantine_from_appliances>
  <ip_address>10.0.0.1</ip_address>
  <ip_address>10.0.0.2</ip_address>
  <ip_address>10.0.0.3</ip_address>
</euq_quarantine_from_appliances>

 

where the 10.0.0.x addresses are the addresses on your ESAs the SMA already knows about, but aren't the addresses where their EUQ deliveries come from.  Add extra <ip_address>...</ip_address> elements to this section for all the *other* addresses on your ESAs.  This section will then look like (changes in bold):

 

<euq_quarantine_from_appliances>
  <ip_address>10.0.0.1</ip_address>
  <ip_address>10.0.0.2</ip_address>
  <ip_address>10.0.0.3</ip_address>
  <ip_address>10.0.100.1</ip_address>
  <ip_address>10.0.100.2</ip_address>
  <ip_address>10.0.100.3</ip_address>

</euq_quarantine_from_appliances>

 

If your SMA is running AsyncOS >= 8.0, then there's one more section to fix up.  Look for the <listeners> section, find the configuration for the listener named euq_listener, and add the extra ESA addresses to its RELAYLIST definition (changes in bold, other elements omitted for brevity):

 

<listeners>
  <listener>
    <listener_name>euq_listener</listener_name>
    ...
    <hat>
$RELAYED
    RELAY {}
$BLOCKED
    REJECT {}
RELAYLIST:
        10.0.0.1
        10.0.0.2
        10.0.0.3
        10.0.100.1
        10.0.100.2
        10.0.100.3

        $RELAYED (Only select hosts can relay from this box)
ALL
    $BLOCKED (Everyone else)
    </hat>
    ...
  </listener>
</listeners>

 

If your ESAs are also running AsyncOS >= 8.0 and you use centralized policy quarantines, you'll probably also want to make the same change to the other listener named cpq_listener.

 

Once you've saved the above changes, just upload the modified config file back to your SMA.  If anything goes wrong, you can always re-upload the unmodified version (you did make a backup copy, right?).  For what it's worth, we haven't yet had anything go wrong with this method, and we've been using it for about 5 years now (sorry, didn't see this thread until now!).

 

BIG CAVEAT: As with all things, this workaround isn't without its drawbacks.  If you ever go back and modify the list of appliances through the SMA's GUI/CLI, it regenerates these config sections and omits the addresses you added manually.  Your ESAs won't be able to submit spam to the centralized EUQ again until you repeat this process.  If you add/remove ESAs from your SMA on a regular basis, then this workaround might be too cumbersome for you.

 

Hopefully this helps somebody out there!

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: