Mystical_Ice
asked on
Advanced ASA config across multiple connections/routes
Hi,
Here's our setup: Â We have a Cisco ASA 5510 at our main facility. Â Until now, we've had a single internet connection. Â We have two site-to-site tunnels set up, three "easy-VPN"s set up, and multiple client VPNs coming in from the outside as well. Â We also have a dozen or so static NATs for other services (email, etc)
In an attempt to save our bandwidth, we got a second, cheaper internet connection, with a high downstream. Â
The goal is to allow all INTERNET traffic from the facilty to go over the second ('comcast' interface) connection, while all inter-site (VPN site to site, client VPN) and static NAT traffic (exchange, spam filter, etc) to continue to traverse the first ('outside' interface on the ASA).
I'm attaching the ASA5510 config, with sections changed to preserve confidentiality (all public IPs have been replaced with generic "1.2.3.4", "5.6.7.8", etc)
Internally, (just to help decifer the config), our IPs are the following:
At the main site (where the 5510 resides): 172.30.0.0
At our two site to sites: 172.31.0.0 and 172.32.0.0
Our client VPNs: 192.168.254.0
Our 3x easy VPNs: 192.168.12.0, 192.168.13.0, 172.17.2.0
The problem we're having, is when I make the changes in this config (basically just adding the route for the comcast, and making the 'outside' interface a lower metric, as you can see in the config) internet traffic inside the office works just fine over the other connection, but none of the VPN tunnels establish - easy vpn or site to site.
putty.log
Here's our setup: Â We have a Cisco ASA 5510 at our main facility. Â Until now, we've had a single internet connection. Â We have two site-to-site tunnels set up, three "easy-VPN"s set up, and multiple client VPNs coming in from the outside as well. Â We also have a dozen or so static NATs for other services (email, etc)
In an attempt to save our bandwidth, we got a second, cheaper internet connection, with a high downstream. Â
The goal is to allow all INTERNET traffic from the facilty to go over the second ('comcast' interface) connection, while all inter-site (VPN site to site, client VPN) and static NAT traffic (exchange, spam filter, etc) to continue to traverse the first ('outside' interface on the ASA).
I'm attaching the ASA5510 config, with sections changed to preserve confidentiality (all public IPs have been replaced with generic "1.2.3.4", "5.6.7.8", etc)
Internally, (just to help decifer the config), our IPs are the following:
At the main site (where the 5510 resides): 172.30.0.0
At our two site to sites: 172.31.0.0 and 172.32.0.0
Our client VPNs: 192.168.254.0
Our 3x easy VPNs: 192.168.12.0, 192.168.13.0, 172.17.2.0
The problem we're having, is when I make the changes in this config (basically just adding the route for the comcast, and making the 'outside' interface a lower metric, as you can see in the config) internet traffic inside the office works just fine over the other connection, but none of the VPN tunnels establish - easy vpn or site to site.
putty.log
Have you done a traceroute to verify that the comcast is being used for internet?
The problem with ASAs is that they do not support 2 active default routes. Â So only the one default route will be used, meaning that you will need to configure static routes for not only the remote site VPNs but also the remote site public IPs. I do not see static routes for the remote Public IPs and I think that that could be the issue.
The problem with ASAs is that they do not support 2 active default routes. Â So only the one default route will be used, meaning that you will need to configure static routes for not only the remote site VPNs but also the remote site public IPs. I do not see static routes for the remote Public IPs and I think that that could be the issue.
ASKER
Yes comcast is definitely being used for internet.
We can set static routes for the remote public IPs for the site to site tunnels, but not for the easy VPNs and client VPNs.
Routes we have are:
route outside 0.0.0.0 0.0.0.0 REGULAR_OUTSIDE_IP 200
route outside 0.0.0.0 0.0.0.0 COMCAST_OUTSIDE_IP 20
route outside 172.17.2.0 255.255.255.0 REGULAR_OUTSIDE_IP 1
route outside 192.168.12.0 255.255.255.0 REGULAR_OUTSIDE_IP 1
route outside 192.168.13.0 255.255.255.0 REGULAR_OUTSIDE_IP 1
route outside 192.168.254.0 255.255.255.0 REGULAR_OUTSIDE_IP 1
route outside SITE_1_OUTSIDEIP 255.255.255.255 REGULAR_OUTSIDE_IP 1
route outside SITE_2_OUTSIDEIP 255.255.255.255 REGULAR_OUTSIDE_IP 1
We can set static routes for the remote public IPs for the site to site tunnels, but not for the easy VPNs and client VPNs.
Routes we have are:
route outside 0.0.0.0 0.0.0.0 REGULAR_OUTSIDE_IP 200
route outside 0.0.0.0 0.0.0.0 COMCAST_OUTSIDE_IP 20
route outside 172.17.2.0 255.255.255.0 REGULAR_OUTSIDE_IP 1
route outside 192.168.12.0 255.255.255.0 REGULAR_OUTSIDE_IP 1
route outside 192.168.13.0 255.255.255.0 REGULAR_OUTSIDE_IP 1
route outside 192.168.254.0 255.255.255.0 REGULAR_OUTSIDE_IP 1
route outside SITE_1_OUTSIDEIP 255.255.255.255 REGULAR_OUTSIDE_IP 1
route outside SITE_2_OUTSIDEIP 255.255.255.255 REGULAR_OUTSIDE_IP 1
Then you will need to move them to the comcast interface...or they will not work.
ASKER
But that doesn't explain why the site to sites, which have static routes, aren't working.
What would our alternative be, if we wanted to keep all VPNs (site to site, easy vpn, and client vpns) on the one connection, along with our current static NATs, and then have the second connection just for outside internet traffic.
If it means having to buy a cheap router or something, we can consider that.
What would our alternative be, if we wanted to keep all VPNs (site to site, easy vpn, and client vpns) on the one connection, along with our current static NATs, and then have the second connection just for outside internet traffic.
If it means having to buy a cheap router or something, we can consider that.
Well, buying a cheap router is a possibility. But your setup, though not optimal, should work.
Have you tried rebuilding the connection at both ends, ie.done a clear crypto isakmp sa and clear crypto ipsec sa on both ends. Â Could be that the remote end is just out of synch with your ASA.
Have you tried rebuilding the connection at both ends, ie.done a clear crypto isakmp sa and clear crypto ipsec sa on both ends. Â Could be that the remote end is just out of synch with your ASA.
ASKER
I've tried doing a full reload on both ASAs
So here's where i am at the moment...
Client VPNs work fine
The site to site tunnels work fine (after making sure we have static routes for both their external and internal IP)
The only thing we don't have is easy VPNs working. Â On one of them, i created a route for their public IP (similar to:
route outside PUBLIC_EASYVPN_SITE1_IP 255.255.255.0 REGULAR_OUTSIDE_IP 1 )
and immediately traffic started flowing between them, so that worked.
Not sure how to make it work for the other easy VPN sites, which have dynamic IPs.
I would have thought since they initiate the connection, to the first connection we have, that it would work, but apparently not.
So here's where i am at the moment...
Client VPNs work fine
The site to site tunnels work fine (after making sure we have static routes for both their external and internal IP)
The only thing we don't have is easy VPNs working. Â On one of them, i created a route for their public IP (similar to:
route outside PUBLIC_EASYVPN_SITE1_IP 255.255.255.0 REGULAR_OUTSIDE_IP 1 )
and immediately traffic started flowing between them, so that worked.
Not sure how to make it work for the other easy VPN sites, which have dynamic IPs.
I would have thought since they initiate the connection, to the first connection we have, that it would work, but apparently not.
You need to move the connection point to the comcast interface as that is the default route. Â Right now you have the connection coming in on the old ISP interface but the return traffic is being sent back out the Comcast interface, thereby creating an asynchronous route which is not allowed on the ASA.
ASKER
You mean move the Easy VPNs in on the Comcast interface?
If they had a static IP, we could get by keeping them on the old interface/connection, since we could have a route pointing them back out that connection, but because they're all DHCP addresses, we have to have them come in on the comcast, right?
How is it that regular Client VPNs seem to work fine, but the easy VPNs don't :/
Also, some of our static NATs (for email, etc) work fine, but i'd like all of their traffic (not just their NATted ports) to go out the old connection. Â How do i do a static NAT in the ASA to designate any outgoing traffic from a specific internal IP needs to go out the old connection? Â That way i won't have to change reverse DNS records for mail, etc.
If they had a static IP, we could get by keeping them on the old interface/connection, since we could have a route pointing them back out that connection, but because they're all DHCP addresses, we have to have them come in on the comcast, right?
How is it that regular Client VPNs seem to work fine, but the easy VPNs don't :/
Also, some of our static NATs (for email, etc) work fine, but i'd like all of their traffic (not just their NATted ports) to go out the old connection. Â How do i do a static NAT in the ASA to designate any outgoing traffic from a specific internal IP needs to go out the old connection? Â That way i won't have to change reverse DNS records for mail, etc.
I am a little suprised that the remote access vpn works and easyvpn doesn't, however I just came across this link for easyvpn. Â https://supportforums.cisco.com/thread/2065400
As for static NATs, where x.x.x.x is your public IP:
static (inside,outside) x.x.x.x 172.30.140.3
I would suggest removing the static PAT statements and regulate connectivity using access-lists in this scenario.
As for static NATs, where x.x.x.x is your public IP:
static (inside,outside) x.x.x.x 172.30.140.3
I would suggest removing the static PAT statements and regulate connectivity using access-lists in this scenario.
ASKER
well we use the access lists in addition to the PAT
ASKER
Thanks for that link - I will attempt to change the comcast interface to the 'backup' interface, with a slightly higher security level, and see if that works
ASKER
Actually, reading through the article, looks like the 'backup interface' only allows the interface to be used if the primary goes down, so that wouldn't help me.
:(
:(
Could you double check and make sure that the Cisco VPN clients are working.
ASKER
Yeah will do; you're right it doesn't make sense that they're working. Â Will check on Wednesday evening and keep you informed.
If they don't work, could i perhaps just point them at the comcast public interface IP?
If they don't work, could i perhaps just point them at the comcast public interface IP?
Yes, if they do not work then the issue is the default route. Â just move the tunnels to the comcast interface and things should be good again.
ASKER
And i would only need to move tunnels that are from sites with dynamic IPs, right? Â If they have a static IP, i can set a static route for the tunnel over the primary connection?
correct, only the sites with dynamic IPs will need to be moved.
ASKER
i'm thinking - shouldn't the client VPNs continue to work? Â The ASA is assigning them their IP address (192.168.254.x), so it would know what interface to route traffic to/from them, right? Â Could that be the reason it worked?
It may not work; i may be incorrect, but it will be Wednesday until i get to test it again. Â Just thinking.
It may not work; i may be incorrect, but it will be Wednesday until i get to test it again. Â Just thinking.
ASKER
Also, regarding removing the static PAT statements and regulating access using access lists - how would that work when we have more than one internal server sharing the same public IP address? Â We may have port 25 going to one server, and port 8000 on the same public IP going to a different server.
That command static (inside,outside) x.x.x.x 172.30.140.3
wouldn't that make ALL traffic from the public IP mapped to the internal IP - back and forward?
That command static (inside,outside) x.x.x.x 172.30.140.3
wouldn't that make ALL traffic from the public IP mapped to the internal IP - back and forward?
If you have several servers using 1 public IP then you can not use the NAT suggestion i mentioned above. Â You would need to stick with the individual PAT statements.
So you confirmed that the VPN clients work? Â It is possible that this is the reason they continue to work. Â But the ASA would still need a route back to the VPN clients that are on the internet, so a default route would be needed. Â I would need to set this up in a lab and test it to find out for sure, and I do not have the time to do that today.
i'm thinking - shouldn't the client VPNs continue to work? Â The ASA is assigning them their IP address (192.168.254.x), so it would know what interface to route traffic to/from them, right? Â Could that be the reason it worked?
So you confirmed that the VPN clients work? Â It is possible that this is the reason they continue to work. Â But the ASA would still need a route back to the VPN clients that are on the internet, so a default route would be needed. Â I would need to set this up in a lab and test it to find out for sure, and I do not have the time to do that today.
ASKER
The individual PAT statements are what I figured I'd need to do; that's why I set them up initially; because of having several to one public IP.
However, how would I set up that all OUTBOUND traffic from a server should go over a particular public IP, instead of the default route?
For instance, even though we have a PAT for our Exchange server port 25 SMTP traffic on connection #1, when the Exchange server sends any outbound traffic, it's going over the default route (Comcast)
However, how would I set up that all OUTBOUND traffic from a server should go over a particular public IP, instead of the default route?
For instance, even though we have a PAT for our Exchange server port 25 SMTP traffic on connection #1, when the Exchange server sends any outbound traffic, it's going over the default route (Comcast)
You may want to try policy NAT to get this working.where 172.30.140.x are your servers.
access-list ACL permit ip 172.30.140.2 any
access-list ACL permit ip 172.30.140.3 any
global (outside) 3 interface
nat (inside) 3 access-list ACL
access-list ACL permit ip 172.30.140.2 any
access-list ACL permit ip 172.30.140.3 any
global (outside) 3 interface
nat (inside) 3 access-list ACL
ASKER
OK tested it and actually client VPNs do NOT work. Â not sure what i was thinking.
So what i'd like to do is be able to point client VPNs at the Comcast interface, and have them work. Â I would think it's that easy, but apparently there are commands I have to run for that.
I'd like to be able to point client and easy VPNs (that don't have static IP addresses) at the comcast connection and have it work. Â Some of the easy VPNs that have a static IP (and thus have a route in the ASA), and the site to sites, i'd still like to work over the first connection.
What am i missing?
So what i'd like to do is be able to point client VPNs at the Comcast interface, and have them work. Â I would think it's that easy, but apparently there are commands I have to run for that.
I'd like to be able to point client and easy VPNs (that don't have static IP addresses) at the comcast connection and have it work. Â Some of the easy VPNs that have a static IP (and thus have a route in the ASA), and the site to sites, i'd still like to work over the first connection.
What am i missing?
If you want to keep the site to site vpns on the original interface you would need to create a new crypto map for the dynamic vpn configuration.
crypto map comcast_map 65535 ipsec-isakmp dynamic outside_dyn_map
crypto map comcast_map interface comcast
crypto isakmp enable comcast
then point all the remote access VPNs at the comcast IP.
crypto map comcast_map 65535 ipsec-isakmp dynamic outside_dyn_map
crypto map comcast_map interface comcast
crypto isakmp enable comcast
then point all the remote access VPNs at the comcast IP.
ASKER
So that way we could receive VPN connections on either interface; however the primary (outside) interface wouldn't be able to establish them unless it had a static route to the internal and external IP of the client originating the connection, right?
Correct, the primary would need a static route to be able to send traffic out that interface...otherwise the default gateway takes over.
ASKER
It's a shame that it's not possible to set the static route based on the INTERNAL/PRIVATE ip address.
For example.... assume a firewall at 11.23.14.15 establishes a VPN connection to our firewall, and its internal IP is 192.168.16.222... why can't we do a static route that anything to 192.168.16.222 goes over the 'outside' connection on our firewall. Â Surely the firewall knows that 192.168.16.222 is mapped to 11.23.14.15, right??
Why do we have to have a static route for 11.23.14.15...
For example.... assume a firewall at 11.23.14.15 establishes a VPN connection to our firewall, and its internal IP is 192.168.16.222... why can't we do a static route that anything to 192.168.16.222 goes over the 'outside' connection on our firewall. Â Surely the firewall knows that 192.168.16.222 is mapped to 11.23.14.15, right??
Why do we have to have a static route for 11.23.14.15...
The ASA is a firewall not a router, though it has some routing capabilities. what you want is policy based routing. if you want this feature you would need to purchase a router.
ASKER
Tried again this evening. Â Got everything working, EXCEPT we weren't able to get our SMTP server to send mail out of the 'outside' connection; it would keep sending it out the 'comcast' connection. Â Tried some thigs, and it would either work over comcast, or not work at all over 'outside'.
MAG03 - do you do any contract work? Â Perhaps it would be easierif you could assist us 1 on 1 instead of posting on this site?
MAG03 - do you do any contract work? Â Perhaps it would be easierif you could assist us 1 on 1 instead of posting on this site?
Sorry I do not do contract work as I am quite busy in my job. Â perhaps there is someone else here that would be able to help you, or a Cisco partner company in your area.
ASKER
OK well we're so close -
The only thing we couldn't get working was the SMTP server outbound. Â Right now it's got a PAT for port 25, (and tried adding the global and nat rules you gave) but sharing the outside IP with some other servers. Â
If we gave it a 1 to 1 NAT, on its own dedicated public IP on the 'outside' interface, you think that would work?
The only thing we couldn't get working was the SMTP server outbound. Â Right now it's got a PAT for port 25, (and tried adding the global and nat rules you gave) but sharing the outside IP with some other servers. Â
If we gave it a 1 to 1 NAT, on its own dedicated public IP on the 'outside' interface, you think that would work?
it should work the other way too, do you have another server using port 25 as well?
a 1 to 1 nat using its own public IP is actually best practice for mail servers, and this will work.
a 1 to 1 nat using its own public IP is actually best practice for mail servers, and this will work.
ASKER
We have this particular relay in front of our mail server - it handles outbound and inbound SMTP traffic, and passes it off to our mail server on the inside network. Â It does spam filtering, etc.
It didn't work for whatever reason - i'll try the 1 to 1 NAT. Â That should work i guess, right? Â If i have a 1 to 1 static NAT, will i need the global and NAT rules?
It didn't work for whatever reason - i'll try the 1 to 1 NAT. Â That should work i guess, right? Â If i have a 1 to 1 static NAT, will i need the global and NAT rules?
ASKER CERTIFIED SOLUTION
membership
Create a free account to see this answer
Signing up is free and takes 30 seconds. No credit card required.
I thought you were moving over to the other connection 100% and not having 2 set up? Â Anyway, good that you got it working.
ASKER
This worked
ASKER
It seems to just be the VPNs