cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2248
Views
15
Helpful
6
Replies

Dual ISP NAT Statement for One Server

chris_funa
Level 1
Level 1

Hello all, 

 

I have a single ASA 5512-x Firepower Edition running firewall IOS 9.6(3)1.

 

We have dual ISPs. ISP1 and ISP2. These links are not setup in an active\standby failover config. 

ISP1 is the default route out. Everything uses this as its internet connection.

ISP2 is used for our guest wireless (guest has it's own interface) only. I have a policy based route to forward all traffic incoming on the Guest inside interface to use ISP2 as the the next hop. This is working great. 

 

What I need to do is see if I can have one server with two NATed address on two different outside interfaces.

 

In testing, I added a secondary IP address to the test server. I created my two object NAT statements and made the necessary access-list configs (testing with ICMP Echo). The NAT statement using ISP2 does not appear to be working. I can see the request making it to the ASA, but the request times out on the sending device.

 

I believe the request is making it to the server, but the server isn't returning out of the ISP2 interface. I figured NAT would do the trick of getting the return packet out the correct interface. 

 

Is there something I'm missing? Should I try with a different protocol other than Echo and see if that works any better?

 

If configs are needed, I can try posting sanitized snippets of routes, NAT, and interface configs. 

 

Thanks for looking!

1 Accepted Solution

Accepted Solutions

Hi @chris_funa

 

 Ping is not the best way to test this although is possible. I'd  try with telnet first. Looking for your description, I was wondering if when the connection comes through ISP2 the server is not replying to ISP1 which is the default. This would cause asymmetric routing and traffic wouldn't flow.

 How the server routing looks like? 

To test with ICMP you should have ICMP inspection on ASA and an ACL permitting icmp on outside interface inbound.

 

-If I helped you somehow, please, rate it as useful.- 

  

 

 

 

-If I helped you somehow, please, rate it as useful.-

View solution in original post

6 Replies 6

Hi @chris_funa

 

 Ping is not the best way to test this although is possible. I'd  try with telnet first. Looking for your description, I was wondering if when the connection comes through ISP2 the server is not replying to ISP1 which is the default. This would cause asymmetric routing and traffic wouldn't flow.

 How the server routing looks like? 

To test with ICMP you should have ICMP inspection on ASA and an ACL permitting icmp on outside interface inbound.

 

-If I helped you somehow, please, rate it as useful.- 

  

 

 

 

-If I helped you somehow, please, rate it as useful.-

Flavio and Bogdan, 

 

First, I want to thank you for your input. Yes, ISP1 NAT statement works fine. 

 

I understand that it's not going to work because of asymmetric routing, if the source packet arrives at ISP2 interface, I want it the return traffic to go back through the same interface it arrived on. I figured NAT would tell a packet received on ISP2 to go back out ISP2 interface, but this isn't the case. 

 

This is what I was aiming for:

Packets received on ISP1 to the server - Return traffic to go back out ISP1.

Packets received on ISP2 to the server - Return traffic to go back out ISP2.

Hopefully this is possible without a second firewall device. 

 

I'll test with telnet or ssh and return with my findings!

I can't think of a configuration on the ASA to make that happen.

If you can get the server to have 2 interfaces with 2 IPs and respond to the packets on the interface they came in then, you just need to configure a policy based route for the second IP (similar to the guest network).

 

So I got it to work.

I think my problem was the protocol I was testing with. I figure because ICMP is connectionless.

 

I used SFTP/SSH for testing. 

 

On the server, I have an IP set at the interface. Then a secondary IP assigned to the same int.

 

I made two separate Object-NAT statements which reflected each inside IP and the corresponding public IP. Then created an entry for each one on the corresponding outside interface on the ASA. 

 

Both connections worked. So I tried testing with what is essentially a 2:1(2 public:1 private) mapping. I changed the inside address of the second object-NAT to the same as the first. So, one inside IP. I left the outside addresses as they were. Connections made it through just fine! 

 

I figured NAT would get the return traffic back out of the originating interface, (so long as the protocol used is stateful) 

 

I don't have ICMP inspection on, but I think it would resolve the issue of ICMP not working if I enabled it. 

*I hope my understanding of stateless and stateful is correct!

I've accepted your reply as the solution because the issue wasn't with my configs, but with the protocol I was using to test.

Flavio and Bogdan, big thanks for helping me out!

Bogdan Nita
VIP Alumni
VIP Alumni

Hi Chris,

I agree with Flavio, but I just wanted to detail why your setup will not work.

I presume the NAT statement on the ISP1 is working, so lets have a deeper look with what happens with the packets coming in on the ISP2 interface.

First, if you have verify reverse-path enabled, the incoming packet will be dropped by the ASA.

Lets assume verify reverse-path is disabled (default behavior) and see what happens next.

Because the destination IP matches the IPS2 NAT statement the packet will be NATed and sent to the server. The server will send back a response to the ASA. At this point the ASA will have do to a route lookup to see which interface will be used, and it is going to get the ISP1 interface. The packet will be drooped at this point because the ASA requires by default for the packet to be received on the same interface it is going to be sent out.

This kind of asymmetry can be allowed through the ASA for tcp traffic by using tcp state-bypass.

Lets say you configured tcp state-bypass and traffic is allowed, then the the packet will not be NATed to the ISP2 IP, but instead to the ISP1 IP. As you can imagine the tcp session can't be established in this case.

packet-tracer and captures are very helpful in troubleshooting and understanding this type of situations.

Review Cisco Networking for a $25 gift card