Buy or Renew
Buy or Renew
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
cancel
Start a conversation
862
Views
5
Helpful
3
Replies

Setup of Ironports - changing configuration

damian.fawkner
Level 1
Level 1

‎03-09-2016 05:08 AM

Hi everyone,

It doesnt help that we are still on 7.5.x or 7.6.x I think from memory, however running C670's

I see that 9.7.1 is the latest - would prefer to upgrade to a more current version before doing the below.

Just after some information on best way to approach this problem.

Currently the setup is two external (DMZ) facing interfaces and then two internal interfaces - therefore four interfaces.

External routes traffic to internal - the external facing does the content filtering, etc before passing off to the internals to complete the processing of the Email to exchange servers.

Internal allow certain allowed/whitelisted IP addresses to send Email directly outbound from the network, if it doesnt exist, its rejected.

So currently they are in parralell and we are looking to move them into series - all four will be the external/DMZ interfaces and internal ones will no longer exist.

So my question is - what is the best way to achieve that goal, I assume that rules will need to be exported from internal and added to the external ones and other configurations, interfaces changed.

Anyone done this before?  Instructions on what to do/check to make it work with minimal chance of issues?

Labels:
0 Helpful
3 Replies 3

Notes Administrator
Level 1
Level 1

‎03-09-2016 07:47 AM

I may be looking to do this shortly. 

What we have already in the DMZ appliances are separate IP Interfaces for Private and Public.

  • These are in separate DMZ VLANs, so the FW configuration from the external facing VLAN is not inter-mixed with the FW configuration for the internal facing VLAN. 
  • The DMZ appliances are also in a cluster configuration.

As a quick thought...

  • The FW will be updated to allow all internal devices to connect to the Private IP of DMZ boxes
  • The FW will be updated to include pre-prepared Private IPs for the internal appliances to the existing group to allow the new boxes to connect inbound to the Exchange / DNS / LDAP / User Access etc
  • The FW will be updated to include the external IPs and added to the external FW group to allow SMTP to/from internet etc.
  • The HAT for the Private Listener on the DMZ boxes will be updated to include the various internal IP ranges.  This is where you may want to create numerous Sender Groups and apply various Mail Flow Policies (but this is what is already in place on the internal IronPorts)
  • As these will no doubt be using Relay Mail Flow policies, then the Outbound Policies and Content Filters need to be added to the external appliances (with care not to conflict with existing policies)
  • You would also need to check there are no advanced / CLI based settings, such as LDAP Routing, Aliasconfig, Listener Masquerading, Message Filters etc.
  • At this point you can then verify one internal system by pointing at one of the existing DMZ boxes, track and see if there are any connectivity or policy related issues.
  • Continue testing until ready to update the internal DNS MX records to point at the existing DMZ appliances.
  • Check with the Internal Appliances for any mail being processed by systems hardcoded with one or other IP address rather than the internal DNS MX records.
  • Lastly - except for any physical cabling and switch configurations - the internal appliances will be reset, built up with the base IP configuration, then simply added to the cluster to inherit the already tested and working configuration.  
  • Well not lastly - you still need to allocate Public IP with NAT on FW, Add SSL certificate, A records in public DNS, Update SPF records, Update MX records

Capacity planning during this cut-over may mean at some point losing high availability to migrate one box to assist with DMZ capacity. 

Your choice whether the internal DNS MX records actually use all the DMZ appliances for outbound.  Think about topology and throughput to determine best layout.

damian.fawkner
Level 1
Level 1
In response to Notes Administrator

‎03-09-2016 08:55 PM

Basically sounds like our setup that you have listed there - we are looking at using the F5 as the entry points to the mail servers for future work, internal and external.

Unfortunately was tired late last night and I didnt go into alot of detail - however your comments have certainly given me information to work with, so thank you for that.

0 Helpful

Notes Administrator
Level 1
Level 1
In response to damian.fawkner

‎03-10-2016 05:54 AM

Lots of testing when using an LB.  For both the inbound and outbound configuration as some people are blocking emails due to enhanced checks that are not entirely in-line with RFCs

Most of the issues are around transparency, subnets and how the IronPort hostname / NAT IP is presented to the outside world.

  • Inbound Source IP - to perform reputation checks and reverse dns you don't want this to be the LB
  • TLS certificate hostname - will it match the advertised Public IP PTR record
  • HELO hostname - will it match the advertised Public IP PTR record
  • HELO hostname - will the A record match the advertised Public IP

When there is a problem, is both the LB team and Email team woken and point fingers at each other.  We have moved to a more simplistic MX arrangement rather than the extra layer of technology due to lack of understanding from LB team over SMTP and delays in resourcing for enhancements to routing paths.

0 Helpful
Customers Also Viewed These Support Documents