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 126.96.36.199 255.255.255.240 in the subnet 188.8.131.52/28. Interface GE0/1 is configured with IP 184.108.40.206 255.255.255.240 in the subnet 220.127.116.11/28. Behind this router is our ASA 5510 firewall. The ASA Interface E0/0 (Public) is configured with IP 18.104.22.168 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 22.214.171.124 255.255.255.248 in the subnet 126.96.36.199/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.
You don't need the 2nd Public IP block for NATting. You can use 188.8.131.52 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 184.108.40.206 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 220.127.116.11 255.255.255.248 1
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 (18.104.22.168 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.
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,
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.
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.
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?