As promised here’s the second issue we ran in to when trying to resolve the first.

To recap the last post, responses to the traffic coming in to the Tidziwe network through the secondary connection, were being sent back out through the primary connection, because of the default gateway. This wasn’t working, because the response traffic was being NAT’ed to a different address as it went back out through the primary connection. We were able to partially get around that by adding NAT entries on the primary router to NAT the source address on that traffic to the correct address for the secondary connection, even though it was really egressing through the primary connection.

This ugly fix appeared to work pretty well at first. From where I’m located, I was able to get to the publically accessible services through both the primary and secondary connections. Unfortunately, some of the people located in Malawi weren’t so lucky. In fact, anyone that used Tonse (the provider of the secondary connection at Tidziwe) as their ISP in Malawi was unable to access the webmail and other services through the secondary connection. This at first didn’t make sense - if anything it would seem logical that accessing it from the same ISP would have fewer problems, not more.

Long story short, Tonse was dropping the response traffic as is entered their network, which is a reasonable thing to do given the circumstances. The packets said they were coming from an address inside of Tonse’s network (2.2.2.2 in our example below). Yet, how could this be given that the packet was coming from Tonse’s upstream provider?

NAT Issues2-Clean IPs

Unfortunately in the short term, we don’t have many options besides our current ugly hack. To get around this additional issue, I added a route map on the Cisco router (the default gateway). The route map routes outgoing traffic through the DLink if it is:

  1. Going to Tonse’s network, and
  2. Coming from one of the services that can be accessed through the Tonse connection

Here’s what the configuration looks like:

int _LAN-Interface_        
ip policy route-map Tonse_Services

access-list 185 remark Used for Tonse_Services route map       
access-list 185 permit tcp host 10.1.1.1 eq 443 41.76.0.0 0.0.255.255

 
route-map Tonse_Services permit 10       
match ip address 185       
set ip next-hop _IP-Of-DLink_

So far, no major problems with this. Hopefully we’ll be able to use both connections through a single device in the future, helping us avoid these sort of issues altogether.