Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
New Member

Routing Email to PGP and receiving it back

Our Environment:
Email: Lotus Notes
Content Scanner: Vontu
Encryption: PGP

Currently, our email goes from Lotus Notes to IronPort which then sends it to Vontu to scan for content. Vontu sends it back to IronPort.

IronPort then checks to see if the message has been marked for encryption from Vontu and if it does it sends it to PGP. If not it sends it to the Internet.

Currently, PGP sends the message it receives to the Internet. I would like to send the message back to IronPort and let IronPort send it out just in case we decide at a later date to add another process in there.

First question: In PGP, do I just give the Host name of Outbound mail back to IronPort on a separate port or can it go back on port 25?

Second question: In IronPort, what rule set do I put in to receive the email back from PGP? When I send an email out through PGP currently, I do not see a Source X-Header in the Email I receive. Has anyone tried to do this and use PGP as a policy server?

Zeff Wheelock

10 REPLIES
New Member

Re: Routing Email to PGP and receiving it back



First question: In PGP, do I just give the Host name of Outbound mail back to IronPort on a separate port or can it go back on port 25?

Second question: In IronPort, what rule set do I put in to receive the email back from PGP? When I send an email out through PGP currently, I do not see a Source X-Header in the Email I receive. Has anyone tried to do this and use PGP as a policy server?

Zeff Wheelock



1. You can relay the mail from the PGP server back to the Ironport appliance on port 25.


2. Is it correct that the only time the PGP server connects to the Ironport appliance is to relay "encrypted" mail that is to be relayed out to the Internet? If this is the case, you can add the IP address of the PGP server to a RELAYLIST sendergroup in the "Mail Policies > HAT Overview" and have the Ironport relay those messages out to the Internet.

If the PGP server doesn't add a customer X-header, the Ironport has a message filter that can detect if a message is encrypted.

detect_encryption:
if (encrypted) {
// action
// action
}

The message filter may not be needed if all the msgs the Ironport appliance receives from the PGP server is already encrypted though. In this case, we simply relay the mail on behalf of the PGP server.

If this doesn't address the question, please elaborate on the scenario/environment(inbound/outbound).

New Member

Here's how we handled our PGP Inbound/Outbound...

Of course the IP addresses have been changed to protect the innocent company.

As you we wanted IronPort to receive email from the internet if it required encryption then handoff to the PGP server and then have the PGP server send it back to IronPort for Internal Delivery. This required 3 filters and also creation of a relay group. Order of filters is important.

First Filter:

this filters states if IronPort receives a message from any pgp ip address then deliver as it has been processed by pgp to avoid any looping I have implemented 50 for inbound from the internet and 51 virtual or internet destined email (Thus on the same PGP Uni server inbound and outbound connector:

been-pgpd: if (remote-ip == "209.152.183.50") OR (remote-ip == "205.156.183.51") {
deliver();
}

Second Filter:

this filter states if a message has been received from the outbound listener and the sender is a member of the group "PGP" (the group member is specific to my organization we've created an ldap directory and given people authorized to use PGP an attribute stating such IronPort does a lookup to see if they are a member of this group and if so ships to PGP to see if processing is required for the destination domain)

PGP_filter: if recv-listener == "outgoingaigmail" {
if mail-from-group == "PGP" {
alt-mailhost ("209.152.183.51");
}
}

Third Filter:

this filter looks at attachments and determine if there is an encryption within the email content originating on the internet and then sends to PGP Uni server for processing after processed PGP Uni server sends back to IronPort and first filter tells IronPort to deliver.

PGP_Inboundfilter: if recv-listener == "IncomingaigMail" {
if (encrypted) OR (attachment-filename == "\\.pgp$") {
alt-mailhost ("209.152.183.50");
}

Hope this helps

New Member

Re: Routing Email to PGP and receiving it back

Sorry to take so long to respond to this. I was waiting to take the IronPort classes so I understand it better. Now that I have taken the classes, I can better explain/understand what is being said.

OK, here is what I have found. We have enabled port pairing on our C350. We have 3 listeners defined. One that listens on port 25 to receive email from our Lotus Domino servers. One that listens on port 10026 to receive email from our Vontu content scanning system. One that listens to port 10025 to receive messages from PGP (as I cannot redefine port 25 again).

I have 3 filters, one that receives from Domino, one that receives from Vontu and one that receives from PGP that all put in an X-Header stating where it is coming from and the Content filters that direct it to the next place in the hop.

1) Are we limited going one way with port pairing?
2) Are we only able to define one port number per NIC in the listeners?

New Member

Re: Routing Email to PGP and receiving it back

Hi!

I might be missing the point of why you have set up NIC pairing in order to be able to get your PGP scenario to work.

The only thing NIC pairing does is to logically combine two otherwise physically separated network interfaces into a single one, so in case one interface / cable / switch dies your appliance still stays connected to your network and you can fix the problem while the appliance is still working the way it should.

As far as your second question goes, that is not really an Ironport limitation, but rather a networking one. On no network device that exists you will be able to run two different appliations (or listeners) on the same port on the same ip. The appliance would never be able to tell which listener the incoming connection is meant for. Just imagine you would like to deliver a package to someone living in a housing estate, door no. 25 and when you reach the front door you find 3 doorbells for room no. 25, but no names - can't work.

What we usually do is define two IP interfaces for the incoming / outgoing connections with a listener on port 25 each, and then another "Encryption" interface that handles all the communication coming from / going to the PGP Universal GW (one listener on 25, another on 8025). Works like a charm and gives us all the high flexibility we need.

On a side note, we had to find out through a lot of trial-and-error testing that the "encrypted" rule in the filters wouldn't catch all the encrypted incoming messages for various reasons, so we had to set up our own. You might want to take a closer look into this.

Cheers.
Torsten

New Member

Re: Routing Email to PGP and receiving it back


I might be missing the point of why you have set up NIC pairing in order to be able to get your PGP scenario to work.

The only thing NIC pairing does is to logically combine two otherwise physically separated network interfaces into a single one, so in case one interface / cable / switch dies your appliance still stays connected to your network and you can fix the problem while the appliance is still working the way it should.


Actually, the NIC pairing was initially set up when we first configured the box. I am now trying to set up PGP as a policy server so when it does it thing, it sends the message back to IronPort instead of sending it to the next hop.


As far as your second question goes, that is not really an Ironport limitation, but rather a networking one. On no network device that exists you will be able to run two different appliations (or listeners) on the same port on the same ip. The appliance would never be able to tell which listener the incoming connection is meant for. Just imagine you would like to deliver a package to someone living in a housing estate, door no. 25 and when you reach the front door you find 3 doorbells for room no. 25, but no names - can't work.

What we usually do is define two IP interfaces for the incoming / outgoing connections with a listener on port 25 each, and then another "Encryption" interface that handles all the communication coming from / going to the PGP Universal GW (one listener on 25, another on 8025). Works like a charm and gives us all the high flexibility we need.

On a side note, we had to find out through a lot of trial-and-error testing that the "encrypted" rule in the filters wouldn't catch all the encrypted incoming messages for various reasons, so we had to set up our own. You might want to take a closer look into this.

Cheers.
Torsten


Thanks for the feedback. I have been testing configuring a backup IronPort and have found that for each Interface you have, you can only configure a listener and a port. You cannot configure the same port number for different listeners on the same interface.

I have also read that you can configure paired data ports as both inbound and outbound. You define the Inbound through the RAT and the Outbound through the HAT. When an email comes into the listener, what would distinguish an inbound from an outbound email? How can you write a message filter to act upon an outbound email and another filter to act upon an inbound email? Currently, I have configured port 25 for receiving email from our mail systems, port 10026 to receive from our content filtering system (Vontu) and port 10025 to receive from PGP. How can I configure a listener for mail coming from outside and use a filter to act upon it? Do most people use each data port as a separate interface and if a NIC goes down, fail over to another box?

New Member

Re: Routing Email to PGP and receiving it back

I have also read that you can configure paired data ports as both inbound and outbound. You define the Inbound through the RAT and the Outbound through the HAT.


While this does indeed work I'd advice against doing so (I am asuming you are talking about using one interface, one listener to handle all your connections - single homed). We have stopped setting up MTAs this way a long time ago since working with dedicated interfaces / listeners (multi-homed) saves you sooo much headache in the long run it's worth investing the extra time (around 5 minutes) to set it up.

In short:

1) One Incoming IP interface, one Incoming Listener (Port 25)
2) One Ougoing IP interface, one Outgoing Listener (Port 25)
3) One Encryption IP interface, two Listeners (In Port 25, Out Port 8025)
4) One Management IP interface running all the management services (ssh, ftp, https)

Keep in mind that nothing stops you from setting up several IP interfaces on the same physical ethernet interface! So configure them all to run on Data1 or your Pair1 (depending on how you named them) and you will be fine.

EDIT: On a side note, I'd go with dedicated proxies for incoming and outgoing mails on the PGP Universal as well! Move the proxy from "unified" to two dedicated versions and you should be fine.

How can you write a message filter to act upon an outbound email and another filter to act upon an inbound email?


After you have taken the steps above simple check the listener the connection is going to and maybe add another filter to look for the mail-from / rcpt-to. Use the dictionaries to be able to add / remove domains easily.

Also keep in mind to:

a) Understand how Message Filter work! There are many details you should know.
b) Understand the difference between Message Filters and Content Filters!

Most of the informatin you seek can be found in the Adv. User Guide Chapter 4: Policy Enforcement.

Please keep in mind that these are only a few basic suggestions and my vary greatly depending on your actual wants and needs!


Do most people use each data port as a separate interface and if a NIC goes down, fail over to another box?


Highly depends on the environment and the requirements we need to meet. Usually the "fail-over" is done by DNS anyhow, since the clustering for the Ironports really is only a config-cluster anyhow that doesn't do much more than exchange the running configs between the different members.

NIC Pairing we usually use in those environments where any sort of HA functionality is a MUST and any downtime spawns unwanted questions. But we don't mind switching it on in other scenarios either.

Torsten

New Member

Re: Routing Email to PGP and receiving it back


1) One Incoming IP interface, one Incoming Listener (Port 25)
2) One Ougoing IP interface, one Outgoing Listener (Port 25)
3) One Encryption IP interface, two Listeners (In Port 25, Out Port 8025)
4) One Management IP interface running all the management services (ssh, ftp, https)


We have the C350 so I do not think we have that extra port for #3 to be set up. I am going to plan on splitting the pairing into two interfaces and having one be inbound (Public) and the other be outbound (Private) and create message filters to route the emails to their different destinations before IronPort has a chance to process them to send them on their final destination.

How would #3 be used in any case? Would this be the interface to send to PGP in your scenerio?

Zeff Wheelock

New Member

Re: Routing Email to PGP and receiving it back

You need to be careful when you are talking about interfaces.

The C350 has, by default, 3 physical interfaces. Data1, Data2, Management.

But there are also LOGICAL IP interfaces that are technically in no way limited, only by "license". On the C150 for example you can have a maximum of 4 IP interfaces. I am note sure about the C350/C650. I think it used to be something like 16/32 or 32/64, but I am not 100% sure anymore and too lazy to look it up.

Now what you want to do is:

1) Set up NIC Pairing on the device (through the CLI) and name your pair PAIR01. Hook up both NICs to your switch(es).

2) Configure your first IP interface (Network -> IP Interface -> New) and set your IP, Netmask, Hostname AND... the ethernet port to PAIR01

3) Configure your second IP interface (Network -> IP Interface -> New) and set your IP, Netmask, Hostname AND... the ethernet port to PAIR01

4) Configure your third IP interface (Network -> IP Interface -> New) and set your IP, Netmask, Hostname AND... the ethernet port to PAIR01

Do you notice a pattern? That way all IP interfaces will be bound to the same NIC pair you created before and all communication to the unit will use a single ethernet port (or pair).

Again, this is only an example and may be different on your side.

Torsten

New Member

Re: Routing Email to PGP and receiving it back


1) Set up NIC Pairing on the device (through the CLI) and name your pair PAIR01. Hook up both NICs to your switch(es).

2) Configure your first IP interface (Network -> IP Interface -> New) and set your IP, Netmask, Hostname AND... the ethernet port to PAIR01

3) Configure your second IP interface (Network -> IP Interface -> New) and set your IP, Netmask, Hostname AND... the ethernet port to PAIR01

4) Configure your third IP interface (Network -> IP Interface -> New) and set your IP, Netmask, Hostname AND... the ethernet port to PAIR01


...and name them Data1, Data2 and Data3. Each IP interface would have a separate IP address associated with it.

Data1 could be the outbound connector from Domino
Data2 could be the PGP connector
Data3 could be the inbound connector from the Internet

Each of those could have port 25 defined if I am understanding you correctly.

Zeff Wheelock

New Member

Re: Routing Email to PGP and receiving it back


Data1 could be the outbound connector from Domino
Data2 could be the PGP connector
Data3 could be the inbound connector from the Internet


I'd try to use names that reflect what the Interface is being used for. Something like IntInbound, IntOutbound,IntEnc and IntMgt for example.

Each of those could have port 25 defined if I am understanding you correctly.


Keep in mind this setting is Listener specific and doesn't have to do anything with the Interface configuration.

-T

369
Views
0
Helpful
10
Replies
CreatePlease to create content