SeguraY
asked on
How support two SMTP with two distint ISP for distinct MX records
Puzzle! smtp return traffic to internet gets dropped due to no adjacent traffic found (guess NAT).
We have two distinct internal smart host appliance providing SMTP services (smtp1 & smtp2).
We also have two (2) distinct ISP providers behind Cisco ASA 5510 (isp1 & isp2)
smtp1 is successfully exchanging emails via ISP1, as this also correspond to default route on ASA: route outside 0.0.0.0 0.0.0.0 1.1.1.99
but smtp2 failed while trying to exchange smtp traffic.
Mainly, the return smtp traffic from smtp1 back to isp2 is actually being divert by the default route at the ASA.
We understand Cisco ASA 5510 do not support PBR (Policy Based Routing), which would have allow to detect the return smtp traffic coming from source smtp2 (192.168.1.5) and force it to get out via E0/2 using static route.
Is there a way to overcome this problem/limitation?
The idea is to be able to offer SMTP redundancy by dedicating each MX pointer to one dedicated set of SMTP host and ISP provider.
Some sites mention using two distinct ASA and one (1) router for PBR.
Ideas?
We have two distinct internal smart host appliance providing SMTP services (smtp1 & smtp2).
We also have two (2) distinct ISP providers behind Cisco ASA 5510 (isp1 & isp2)
smtp1 is successfully exchanging emails via ISP1, as this also correspond to default route on ASA: route outside 0.0.0.0 0.0.0.0 1.1.1.99
but smtp2 failed while trying to exchange smtp traffic.
Mainly, the return smtp traffic from smtp1 back to isp2 is actually being divert by the default route at the ASA.
We understand Cisco ASA 5510 do not support PBR (Policy Based Routing), which would have allow to detect the return smtp traffic coming from source smtp2 (192.168.1.5) and force it to get out via E0/2 using static route.
Is there a way to overcome this problem/limitation?
The idea is to be able to offer SMTP redundancy by dedicating each MX pointer to one dedicated set of SMTP host and ISP provider.
Some sites mention using two distinct ASA and one (1) router for PBR.
Ideas?
gheist
Go to netalyzr.icsi.berkeley.edu
Unfortunately as you have already discovered you have to use a router to terminate the ISP links. This will let you use PBR to send the SMTP traffic from back through the ASA via the correct ISP.
It's very simple to do with an additional router but what you have to remember is that the ASA isn't distinctly a router - it is just a firewall with 'some' routing capability.
It's very simple to do with an additional router but what you have to remember is that the ASA isn't distinctly a router - it is just a firewall with 'some' routing capability.
According to internet standards ASA and Catalyst with their rudimentary IP forwarding capabilities are full-fledged routers, just like Windows 95 or 7
Hmmmm apologies if I'm being stupid here but I don't know whether to actually take what you just said as a joke...
The Cisco ASA is a firewall and although it has routing capabilities it is not a fully-fledged router by any stretch. Similarly, Layer 3 switches such as the 3750 can obviously route (as they're Layer-3), but they can't do some things such as NAT or routing via two default routes at the same time. Furthermore some features are restricted either by the software features contained within IOS, or simply the hardware they run on, and some features just aren't included in the software for that specific platform.
Cisco continue to make separate products such as routers, multilayer switches and firewalls for a good reason.
The Cisco ASA is a firewall and although it has routing capabilities it is not a fully-fledged router by any stretch. Similarly, Layer 3 switches such as the 3750 can obviously route (as they're Layer-3), but they can't do some things such as NAT or routing via two default routes at the same time. Furthermore some features are restricted either by the software features contained within IOS, or simply the hardware they run on, and some features just aren't included in the software for that specific platform.
Cisco continue to make separate products such as routers, multilayer switches and firewalls for a good reason.
can you source nat the traffic on the asa? Not sure if its a valid config for the asa, but it will help keep the traffic flow from ISP2 symmetric. This is how it'd be done if it were a loadbalancer instead of a firewall.
I am serious. An internetwork router is a very simple thing. NAT capable router is called A stub router WITH NAT.
Well unfortunately I don't think the rest of the Cisco networking community would agree with you there.
As I said, a layer-3 switch is routing-capable, yet it can't do NAT, even when configured as a stub router.
A router which can do NAT is called a 'router'. A router is defined as a stub when defined as a stub within a routing process. A router can be a stub and a non-stub at the same time, depending on its configuration, and it can also run NAT with or without a routing process running.
As I said, a layer-3 switch is routing-capable, yet it can't do NAT, even when configured as a stub router.
A router which can do NAT is called a 'router'. A router is defined as a stub when defined as a stub within a routing process. A router can be a stub and a non-stub at the same time, depending on its configuration, and it can also run NAT with or without a routing process running.
@unfragmented - you can use policy NAT to tell the traffic which IP address to use as the source when it leaves the ASA, but unless the traffic can route via the appropriate upstream router this won't work. The ASA can't use more than one default gateway at a time, so if you set specific static routes via different circuits you could get it to do what you want, but with a default route this won't work.
You dont need nat policy. You need static NAT for broken path.
If possible can you post a cleaned up version of your config?
What should occur is that since there should be a XLATE entry showing the traffic coming in from E0/2, the traffic should go out that interfaces.
At least according to:
http://www.packetu.com/2011/11/28/egress-interface-selection-on-the-cisco-asa/
Which references:
http://www.cisco.com/en/US/docs/security/asa/asa82/configuration/guide/route_overview.html#wp1095480
What should occur is that since there should be a XLATE entry showing the traffic coming in from E0/2, the traffic should go out that interfaces.
At least according to:
http://www.packetu.com/2011/11/28/egress-interface-selection-on-the-cisco-asa/
Which references:
http://www.cisco.com/en/US/docs/security/asa/asa82/configuration/guide/route_overview.html#wp1095480
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
@giltjr - if there is no outbound route the traffic won't go anywhere. It's only good for connected subnets.
From the first link...
From the first link...
At this point, packets destined to 0-127.x.x.x will go to isp1. Packets with a destination of 128-255.x.x.x will go to ISP2. That still is not too interesting. This could actually be accomplished with two routes in the route table.That's half the issue - you would only be able to 'return' traffic down specific ISP links, so the same problem would likely exist depending on the link which the traffic originates from.
You need to add static NAT runle for other mailserver to use other link...
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
fun to see how the cisco world can't handle stuff that many software firewalls have been handling elegantly for years : they implement reply-to and will answer to the original router if you just set reply-to "interface_name"
source nat would work but is a no-go if you expect proper antispam downstream
a single cisco can usually handle it by PATing each connection to a specific set of ports and setting up the required policy routes so the answers from each set of port is sent to the proper router.
if policy routes are not supported, you can duplicate the traffic that should reach the non-default router to that router in the same way you'd setup a sniffer... and block the corresponding traffic so you don't hammer the default router with traffic it is not supposed to receive. undoubtedly this is overly complicated
source nat would work but is a no-go if you expect proper antispam downstream
a single cisco can usually handle it by PATing each connection to a specific set of ports and setting up the required policy routes so the answers from each set of port is sent to the proper router.
if policy routes are not supported, you can duplicate the traffic that should reach the non-default router to that router in the same way you'd setup a sniffer... and block the corresponding traffic so you don't hammer the default router with traffic it is not supposed to receive. undoubtedly this is overly complicated