cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
628
Views
0
Helpful
7
Replies

Requesting Information on Cisco 3945E Router and ASA 5510 Implementation

ramadori1
Level 1
Level 1

We are preparing to migrate from our managed DS3 to (new carrier) managed IPFlex link. Currently, we have a Cisco 3845 router which is managed by our current provider. Interface GE0/0 is configured with IP 65.125.185.193 255.255.255.240 in the subnet 65.125.185.192/28.  Interface GE0/1 is configured with IP 65.125.185.209 255.255.255.240 in the subnet 65.125.185.208/28. Behind this router is our ASA 5510 firewall.  The ASA Interface E0/0 (Public) is configured with IP 65.125.185.194 255.255.255.240 and this interface communicates with the 3845 GE0/0 interface.  The ASA Interface E0/1 (Private) is configured IP 192.168.1.6 255.255.255.0. Our ASA provides VPN access and NAT translations via the public interface. Our current provider has given us two public subnets/IP blocks to make this all work.

Now our new provider has given us only one public subnet/IP block but we still need to have our VPN access and NAT translations.  Their Cisco 3945E is configured with GE0/0 (Public) having IP 12.35.25.233 255.255.255.248 in the subnet 12.35.25.232/29.  GE0/1 (Private) is configured with IP 10.10.10.10 255.255.255.0. My question is: how can we still provide VPN access and NAT translations with only one public IP block?  Also note that we have a Cisco C3750G-48TS switch that we can create VLANs with as needed. The conclusions I come to are: 1. Get a second public IP block or 2. Have our provider configure a NAT to the ASA "public" interface with a new IP in the 10.10.10.x subnet and also configure the other NAT translations on the router that we currently have on our ASA. I'd like to reach out to the community to see if there are other solutions available that I have not considered.  I look forward to hearing from you with your input.

Regards,

RA

 

7 Replies 7

allen mert
Level 1
Level 1

Hi Ramadori1,

You don't need the 2nd Public IP block for NATting. You can use 12.35.25.234 255.255.255.248(IP on your ASA facing to 3945E) on your ASA. Dynamic NAT translates a group of private addresses to a pool of mapped addresses that are routable on the destination network. Create dynamic NAT/PAT on ASA:

 

--- Configure the outside interface.
!

interface Ethernet0/1
 nameif outside
 security-level 0
 ip address 12.35.25.234 255.255.255.248 

!--- Configure the inside interface.
!

interface Ethernet0/2
 nameif private
 security-level 100
 ip address 10.10.10.1 255.255.255.0 




!-- Output suppressed
!

passwd 2KFQnbNIdI.2KYOU encrypted
ftp mode passive
dns server-group DefaultDNS
 domain-name default.domain.invalid

access-list 100 extended permit ip any any
access-list inside_nat0_outbound extended permit ip 10.10.10.0 255.255.255.0 
any 


!--- This access list (inside_nat0_outbound) is used 
!--- with the nat zero command. This prevents traffic which 
!--- matches the access list from undergoing network address translation (NAT).
!--- The traffic specified by this ACL is traffic that is to be encrypted and
!--- sent across the VPN tunnel.  This ACL is intentionally 
!--- the same as (outside_1_cryptomap).
!--- Two separate access lists should always be used in this configuration.

access-list outside_1_cryptomap extended permit ip 10.10.10.0 255.255.255.0 
any

!--- This access list (outside_cryptomap) is used 
!--- with the crypto map outside_map 
!--- to determine which traffic should be encrypted and sent 
!--- across the tunnel.
!--- This ACL is intentionally the same as (inside_nat0_outbound).  
!--- Two separate access lists should always be used in this configuration.

pager lines 24
mtu inside 1500
mtu outside 1500
no failover
asdm image disk0:/asdm-613.bin
asdm history enable
arp timeout 14400
global (outside) 1 interface
nat (inside) 1 10.10.10.0 255.255.255.0

nat (inside) 0 access-list inside_nat0_outbound

!--- NAT 0 prevents NAT for networks specified in 
!--- the ACL inside_nat0_outbound.


access-group 100 in interface outside
route outside 0.0.0.0 0.0.0.0 12.35.25.233 255.255.255.248 1
Please rate if this helps..
 
Thanks,
Allen

Allen,

Thanks for your response.  Given your suggestion, how does our existing private network of 192.168.1.x fit into all of this?  Currently our ASA's private interface is on this subnet and the public interface would be on the 12.35.25.x subnet.  Users would access the VPN on the ASA's public IP address (12.35.25.234 as in your suggestion).  Are you suggesting that we have three subnets when all is said and done?  192.168.1.x, 10.10.10.x, and 12.35.25.x?  I was kind of leaning toward doing away with the 10.10.10.x subnet and only making this work with one public IP block and our existing private subnet.  Please advise.

Regards,

Richard

 

Hi Richard,

If we are talking about Remote access VPNs, i think one of your private ip range(192.168.1.x or 10.10.10.x) is designed for the IP address pool for these Remote access clients. So, briefly 1 subnet is for Remote access pool(when Remote User connects to ASA and gets an internal IP from this pool), 2nd subnet is for your internal Network(Servers,Data center,etc.) and 3rd subnet is for public(outbound) ip range which you need to translate traffic between public<->private. Please post your config on your ASA which may shed some light on this. 

 

Please rate if you find this helpful,

Thanks,

Allen

 

The suggestions from Allen are based on the assumption that Richard can use the Public IP block on the interface of the ASA. And if this is correct then most of his suggestions make sense. But my understanding of what Richard has described is quite different from that. I believe that Richard said pretty clearly that there was one Public IP block and that the ISP assigned it on the Internet router and not on the ASA. If that is the case then the suggestions from Allen do not work.

 

I also think that the responses from Allen about 192.168.1.0 miss the mark. Richard's description was pretty clear that the ASA inside interface had been in 192.168.1.0. In his suggestion about configuration Allen discards 192.168.1.0 and replaces it with 10.10.10.0 (which had appeared in the network description as a suggestion from the new ISP).  I see no reason to discard 192.168.1.0. And neither of these addresses have anything to do with the address pool for VPN.

 

HTH

 

Rick

HTH

Rick

Richard Burts,

This is correct.  So I'm still trying to find a solution on this.  Thank you!

RA

 

Ra

 

I believe that you are correct that essentially you have two options. I agree that the first option is most preferable which is to negotiate with the new provider to get a second block of public addresses.

 

The second option would be for operate the ASA with the 10.10.10 address on its outside interface. The provider would need to configure address translation such that traffic intended for the ASA would be forwarded to the ASA. They might configure address translation for traffic initiated from inside or perhaps the ASA might translate that traffic and then the provider would do a second translation.

 

HTH

 

Rick

HTH

Rick

RA

 

In thinking about this I believe that there might be a third alternative which you could consider. Clearly in your previous environment the outside router was required because of the DS3 since the ASA does not have the proper interface type or protocol handling. But with your new IPFlex link is it delivered using an Ethernet handoff? In that case perhaps you do not need the outside router and could put the public IP on the ASA?

 

HTH

 

Rick

HTH

Rick
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco