cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
285
Views
0
Helpful
3
Replies

Public Server on 2 external interfaces

Jeff Mitchell
Level 1
Level 1

I suspect this is relatively simple, but I'm brand new to the Cisco line (and to the forums), so my apologies if I'm unclear or in violation of forum etiquette.

I have an ASA5515 which will be using 2 external interfaces, and I need to make a single internal server available to the outside world on both interfaces.  I can accomplish this easily for the main external interface (the faster circuit), but I'm running into issues getting connections through on the backup circuit.  Here's the interface configuration:

interface GigabitEthernet0/0
 description ISP-2
 nameif backup
 security-level 0
 ip address 10.177.188.22 255.255.255.248
!
interface GigabitEthernet0/1
 description ISP-1
 nameif outside
 security-level 0
 ip address 10.131.225.158 255.255.255.240 
!
interface GigabitEthernet0/2
 description LAN
 nameif inside
 security-level 100
 ip address 192.168.2.250 255.255.255.0 

I'd like outside (internet) users to be able to make an HTTP request on port 80 to 10.131.225.146, which comes in GigabitEthernet 0/1, gets translated to the internal web server at 192.168.2.1:80, and then any response traffic leaves GigabitEthernet 0/1, looking to the user like it originated form 10.131.225.146.

Additionally, I'd like the same user to be able to make an HTTP request on port 80 to 10.177.188.18, which comes in GigabitEthernet0/0, goes through the above translation, and then response packets exit via GigabitEthernet0/0.

I've been able to get most of the above working, but when working on the NAT rule for the backup side, packet-tracer tells me that my NAT is fine (it NATs the packet from 192.168.2.1:80 to 10.177.188.18:80, but it wants to then route that packet through the outside interface (GigabitEthernet0/1)

While I've been able to find many references to this on-line (such as this blog post), they all appear to be outdated, using pre-8.3 syntax.

I suspect I'm close on this, but I can't seem to get that last piece to make everything 'click'.  Any help would be greatly appreciated.

1 Accepted Solution

Accepted Solutions

Basically you need three elements in your config:

  1. An ACL-Entry on both interfaces allowing the needed traffic.
  2. Two NAT-statements, one for each external interface.
  3. A route to the Backup-NH with a higher AD.
object network SERVER-VIA-OUTSIDE
 host 192.168.2.1
 nat (inside,outside) static 10.131.225.146 service tcp 80 80
object network SERVER-VIA-BACKUP
 host 192.168.2.1
 nat (inside,backup) static 10.177.188.18 service tcp 80 80
!
access-list OUTSIDE-IN extended permit tcp any object SERVER-VIA-OUTSIDE eq 80
access-list BACKUP-IN extended permit tcp any object SERVER-VIA-BACKUP eq 80
!
access-group OUTSIDE-IN in interface outside
access-group BACKUP-IN in interface outside
!
route outside 0.0.0.0 0.0.0.0 NH-ON-OUTSIDE 1
route backup  0.0.0.0 0.0.0.0 NH-ON-BACKUP 100

 

 

View solution in original post

3 Replies 3

Basically you need three elements in your config:

  1. An ACL-Entry on both interfaces allowing the needed traffic.
  2. Two NAT-statements, one for each external interface.
  3. A route to the Backup-NH with a higher AD.
object network SERVER-VIA-OUTSIDE
 host 192.168.2.1
 nat (inside,outside) static 10.131.225.146 service tcp 80 80
object network SERVER-VIA-BACKUP
 host 192.168.2.1
 nat (inside,backup) static 10.177.188.18 service tcp 80 80
!
access-list OUTSIDE-IN extended permit tcp any object SERVER-VIA-OUTSIDE eq 80
access-list BACKUP-IN extended permit tcp any object SERVER-VIA-BACKUP eq 80
!
access-group OUTSIDE-IN in interface outside
access-group BACKUP-IN in interface outside
!
route outside 0.0.0.0 0.0.0.0 NH-ON-OUTSIDE 1
route backup  0.0.0.0 0.0.0.0 NH-ON-BACKUP 100

 

 

Karsten, thank you for your quick response.  I did have an opportunity to try the settings above and while they appeared to work for requests originating from a laptop acting as the gateway on the backup interface, I lost that connectivity when I connected that interface to the connection from our ISP and tried the same requests from a true, public IP.

I've currently got the server in question responding to requests from both public IPs through a combination of separate firewalls and segregated VLANs.  I plan to make some DNS changes and let them propagate to get all traffic over to the outside interface, allowing me to play with the backup interface without taking services down.

I'll follow up once I have a little more freedom to do real testing.

I finally had a chance to complete this migration, and Karsten's answer above was exactly what I needed.  Thanks again!

Review Cisco Networking products for a $25 gift card