03-22-2020 08:08 PM
I'm trying to split VPN traffic for our phones and remote users into different ASA's. This is due to the cert assigned on the outside interface of ASA1. Currently, ASA1 outside interface has the cert for the VPN phones and when users tried to VPN they will get a prompt about "untrusted servers" or the invalid cert. I usually advised users to ignore the prompt and continue with their remote sessions. I want to know if it's possible to route different public IP into 2-different ASA's.
Any feedback with the config is highly appreciated. Thanks
Solved! Go to Solution.
03-24-2020 12:39 PM
The static translation is the right kind of thing. The dynamic translation is not right. It does not work with access list 1 and access list 2 both applied to the same interface. What you need is a single access list with an entry for 192.168.5.0 and another entry in the same acl for 192.168.7.0. Also the mask you use is int acl is wrong. Instead of 0.255.255.255 use 0.0.0.255. (although technically speaking there is an argument that you acl mask would probably produce the desired result - with mask of 0.255.255.255 it would match any IP that had 192 in the first octet and would ignore the other parts of the address)
03-23-2020 08:21 AM
If we look at the question of whether the 2901 can split traffic for ASA1 and ASA2 from a high level the answer is that yes the 2901 could send the traffic for phone vpn to one ASA and traffic for user vpn to the other ASA. It is when we start looking at the details that it gets tricky.
The simple solution would be if the 2901 had 2 subnets with public IP in both subnets. The 2901 would need a subnet (could be a /30) for its Internet facing interface and would need a second subnet (would need to be at least /29) for its interface connecting to the ASAs. In that case each ASA would have a public IP on its outside interface and phone vpn would be configured to access the IP of the phone ASA while user vpn would be configured to use the IP of the user ASA. In this solution the 2901 does not need to do any address translation.
If it is not feasible to have 2 subnets with public IPs then there is a possible solution if the 2901 has a subnet with public IPs that is /29. In that case the 2901 would be configured with one of the public IP on its Internet facing interface and that address would be used for any non vpn traffic. The 2901 would have a static translation for one of the other public IP and translate to a private address which would be configured on the outside interface of the phone ASA. The 2901 would have another static translation for another of the public IP and translate it to a private address which would be configured on the outside interface of the use vpn ASA. So the 2901 would be doing static address translation for both the phone and user vpn traffic and would be doing dynamic address translation for non vpn traffic.
03-23-2020 03:06 PM - edited 03-24-2020 01:07 PM
EDITED
Hi Rick,
Thanks for the quick response. We only have 1 subnet so we're stuck with the static NAT. Assuming I have a private IP for the ASA outside interface, let's say ASA1 4.4.4.1 & ASA 2 5.5.5.1. Will the config below work?
ip nat inside source static 4.4.4.1 1.2.3.1 (ASA 1)
ip nat inside
ip nat inside source static 5.5.5.1 1.2.3.2 (ASA 2)
ip nat inside
access list 1 permit 192.168.5.0 0.0.0.255
access list 1 permit 192.168.7.0 0.0.0.255
ip nat inside source list 1 interface GigabitEthernet 0/0/0 overload
interface GigabitEthernet 0/0/1
ip nat inside
interface GigabitEthernet 0/0/0
ip nat outside
ip route 0.0.0.0 0.0.0.0 1.2.3.0 (assuming 1.2.3.0 is the provider GW IP)
03-24-2020 12:39 PM
The static translation is the right kind of thing. The dynamic translation is not right. It does not work with access list 1 and access list 2 both applied to the same interface. What you need is a single access list with an entry for 192.168.5.0 and another entry in the same acl for 192.168.7.0. Also the mask you use is int acl is wrong. Instead of 0.255.255.255 use 0.0.0.255. (although technically speaking there is an argument that you acl mask would probably produce the desired result - with mask of 0.255.255.255 it would match any IP that had 192 in the first octet and would ignore the other parts of the address)
03-24-2020 12:52 PM
03-24-2020 01:01 PM
03-24-2020 02:03 PM
NAT should suffice.
03-24-2020 02:05 PM - edited 03-24-2020 02:05 PM
Much appreciated, Rick
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide