inbound SMTP issue

[fredmaine]

I have a specific need on our ASA 5510 and could use some guidance.

Currently our outside interface accepts SMTP from any source, via an access rule. NAT then forwards the inbound SMTP to an internal email gateway.

I now have a situation where I have two internal email gateways. I need inbound SMTP from a -specific- network, to be forwarded to internal gateway1, and all the rest of inbound SMTP traffic forwarded to internal gateway2.

I can't seem to find a way to do this with any combination of typical access rules or NAT rules. I can define an access rule for the specific network OK, but NAT can't inspect the source IP of the traffic.

I'm wondering if I'm just missing something simple or if I need to configure something more complex such as Modular Policy Framework (MPF) or perhaps go to multiple firewall contexts.

My networking vendors are saying I should just configure a second outside interface for the unique network out there, so that normal access rules and NAT -would- work.

But with SMTP, I'm not sure that's feasible. If it is, I'd need assistance there.

Fred

 

[fredmaine]

By the way I can think of a similar example that should have a similar solution.

Let's say I have two internal unix servers. Each is supported by a different vendor.

I might want to allow inbound telnet from Vender1's network, and forward that telnet session to Unix1 host. Inbound telnet from Vendor2's network would be allowed, but I want that telnet session forwarded to Unix2 host. All other inbound telnet would be denied.

That should be a similar exercise as the SMTP issue that I have (the SMTP issue is a real-word problem though - not hypothetical).

Fred

 

[unclerico]

- Define a second static NAT entry (this is assuming a /29 CIDR block):

static (inside,outside) tcp 208.158.43.10 smtp 192.168.1.25 smtp
static (inside,outside) tcp 208.158.43.11 smtp 192.168.1.26 smtp

- Add a second ACE to your outside ACL specifying the more specific rule first

access-list outside_access_in extended permit tcp host 1.1.1.1 host 208.158.43.10 eq smtp
access-list outside_access_in extended permit tcp any host 208.158.43.11 eq smtp

I hate all Uppercase... I don't want my groups to seem angry at me all the time! =)
- ColdFlame (vbscript forum)

 

[fredmaine]

Thanks for the quick reply. Yeah I'm on a deadline

I can see where your solution would work for my hypothetical telnet example. I could have the two vendors each telnet to a different IP address. I can see that working perfectly.

For smtp though, the inbound email - whether from the specific network or the "all other" internet stuff - it's all coming to the same domain/public IP.

That is, any email inbound to my domain comes to mydomain.com, which resolves to one public IP, not two.

I guess that's the bit I'm having trouble with.

Fred

 

[unclerico]

That is, any email inbound to my domain comes to mydomain.com, which resolves to one public IP, not two.

Would the organization that needs the special handling be willing to use an smtp connector for your domain?? If they would be willing to set one up specifying that any mail destined for mydomain.com would be smart hosted to 208.158.43.10 (as specified in my example) then this would work fine. Other than that there's not much other alternative that I can think of.

I hate all Uppercase... I don't want my groups to seem angry at me all the time! =)
- ColdFlame (vbscript forum)

 

[brianinms]

So you have the same domain served by 2 mail servers?

 

[fredmaine]

unclerico: Thanks. Unfortunately I don't think they can help me, although I wasn't sure what to ask for precisely. I will talk to them again now that you've stated it. But they're a large provider and I have no control or connection with them, other than I'm a customer and we use their wireless phones.

brianinms: Well, not exactly. I've oversimplified the problem. Grab a cup of coffee

Actually one host is an anti-spam gateway, the other is a protected mail server.

For all inbound SMTP, the normal route is that it shows up at the firewall, and is forwarded by the ASA to the anti-spam gateway. That host then relays acceptable email to the protected mail server, and drops the junk.

Here's the thing - the anti-spam gateway simply can't handle our own wireless phone emails inbound to our own domain.

I think you'll see why -

The wireless phones POP into our server to get email, but send email through the provider's SMTP servers.

The phone user configures the "from" address as being john@mydomain.com. The email is physically relayed by the wireless provider, we can't change that.

So here's my anti-spam gateway, receiving email relayed by the wireless smtp servers, coming from john@mydomain.com, bound for fred@mydomain.com ....

The anti-spam gateway sees that as forged, and drops it.

In fact, the best practice for the anti-spam gateway is to block my own domain - but I can't due to the wireless phones.

I've spoken to the anti-spam gateway folks too, they can't change anything. They're suggestion was that, if I could just get that specific wireless SMTP traffic to bypass the anti-spam gateway, I'd be in good shape. They reason that the chances of spam coming from the wireless smtp servers is slim to none.

The anti-spam gateway is otherwise a very good product. I'd love to know how others might deal with a similar situation.

Fred

 

[fredmaine]

Also is there anyone out there that is very familiar with Modular Policy Framework (MPF), on the ASA?

I was rather hopeful that I could define a class of traffic for SMTP inbound from the wireless servers, then create an action that would apply a different NAT policy, thereby allowing me to forward it to the other server as described above.

 

[brianinms]

The problem is that you can't have the same external address natd to two different internal ip addresses. I am not sure that it can even be done with policy nat.

That is a really odd wireless phone setup to say the least. Can your wireless provider change the relay setting?

 

[fredmaine]

Yeah after unclerico's post I sent another email to the wireless provider, asking if they could smarthost email bound for my network to a different IP address in my IP space. That would allow me to use a standard NAT arrangement at the firewall, as described above.

I haven't heard back yet. I'm guessing they'll decline, mostly because they've already said that they think the real issue is the anti-spam gateway's inability to deal with this.

Fred

 

[fredmaine]

I'm also considering a solution using multiple security contexts. I wrote this up in the PIX forum for another reason but I'll repeat the detail here for convenience.

In a nutshell, I want any inbound SMTP to be forwarded to an internal SMTP server A, except inbound SMTP from a specific network, which I want forwarded to a second internal SMTP server B.

My idea to solve this with multiple contexts would be:

Security context A:
Access List:
1. Deny SMTP packets from Specific_Network
2. Permit SMTP packets from anywhere else
3. all other non-SMTP access rules go here
NAT:
1. Route all SMTP packets to server A
2. other non-SMTP NAT rules go here

Security context B:
Access List:
1. Permit SMTP packets from Specific_Network
2. Deny SMTP packets from anywhere else
NAT:
1. Route all SMTP packets to server B

Both contexts share the same interface and the same outside network, but have unique MAC addresses, which can be done according to David Huckaby/Cisco Press.

I'm making a broad assumption here, and that is that both contexts see all of the same packets arriving on the interface that they share.

In other words, for our email problem, both contexts get the same SMTP packets but each deals with one condition or other, in an un-ambiguous way. One context denies what the other context permits.

I've no idea if this would work.

 

[fredmaine]

I did not hear back from the wireless provider today.

I guess I'm giving up on Modular Policy Framework (MPF) as a possible solution, I've spent some time looking at this. You can create a policy map that can identify the inbound SMTP traffic well enough, but the actions that can be performed don't allow anything with NAT.

So, I'm still looking at the multiple security context idea. Whether or not this would work depends on whether or not both contexts, although separate, do in fact both see the same packets when sharing an outside interface and outside network, as David Huckaby seems to imply in his video/book.

If anyone works with mutliple contexts and knows if this is the case, please jump in.

Fred