08-13-2012 02:09 PM - edited 02-21-2020 06:16 PM
I am adding a second external connection to an existing system on an ASA 5510 with ASA V8.2 and ASDM 6.4
I added the new WAN using an other interface (newwan).
The intention is to route most internet traffic over the new route/interface (newwan) but keep our existing VPNs using the former interface (outside).
I used the ASDM GUI to make the changes and most of it works.
ie. The default route goes via (newwan)
Outgoing VPNs of a site to site nature use the previous route via (outside) as they now have static routes to achieve this.
The only problem is that incomming Remote Access Anyconnect VPNs are not working.
I set the default static route to use the new interface (newwan) and the default tunneled route to be via (outside) but this is the point is goes wrong....
I can no longer ping the outside IP address from an external location.
It seems the outside interface does not send traffic back to the - outside interface (or at least that's where I think the problem lies). How do I force replies to the incomming VPN remote traffic from unknown IPs to go back out on the outside interface?
The only change I need to make to get everything working on the outside interface again is to make the Default Static route use the outside interface. Which puts all the internet traffic back on the original (outside) connection
Any pointers appreciated.
William
Solved! Go to Solution.
08-14-2012 12:43 AM
William,
As it is right now you will need to use same interface you have default route over to terminate remote access, unless you know their IPs.
In one of the designs I saw we did something like this.
(ISP cloud) ---- edge router ---- ASA.
On edge router you can perform PAT to router's inside interface for traffic incoming on port udp/500 and UDP/4500 (you might need to add exceptions for your static L2L). It's dirty, I would not say it's recommended, but apparently it was working.
On routers this sort of situation is easily remedied by using VRF-lite with crypto.
M.
08-14-2012 12:43 AM
William,
As it is right now you will need to use same interface you have default route over to terminate remote access, unless you know their IPs.
In one of the designs I saw we did something like this.
(ISP cloud) ---- edge router ---- ASA.
On edge router you can perform PAT to router's inside interface for traffic incoming on port udp/500 and UDP/4500 (you might need to add exceptions for your static L2L). It's dirty, I would not say it's recommended, but apparently it was working.
On routers this sort of situation is easily remedied by using VRF-lite with crypto.
M.
08-16-2012 11:37 AM
OK I took a different approach as a result of your message and got most of it working on the second interface except outgoing static VPNs as I could route them specifically via the existing interface. That all worked fine.
I got incoming IPsec working using the PAT forwarding as you suggested. Actually I quite like the approach as it means I can test more bits locally inside the Edge router yet outside the ASA.
However I couldn't get incoming AnyConnect clients to connect, though I tried to PAT port 443 it seemed to complain about the lack of an ACL for port 443, but I don't want to pass port 443 on to an other internal server I want the ASA to respond.
Can you tell what I am missing?
I can't recall how we generated the inital certificate for the Outside interface. Do I need one for the newwan interface?
W
08-16-2012 02:30 PM
William,
Do you have the exact error warning message you recived? I understand that it popped during NAT config?
Also remember that Anyconnect is by default TCP and UDP port 443 (UDP being for DTLS).
M.
08-16-2012 03:16 PM
I had indeed forgotten about UDP 443, but unfortunately that wasn't the full solution.
The error was:
%ASA-3-710003: {TCP|UDP} access denied by ACL from source_IP/source_port to interface_name:dest_IP/service
with the description being: TCP access denied by ACL from
where 10.0.3.1 is the destination IP ie. the port on the ASA facing the edge router.
The error is from the ASA log viewer, so it must be getting through but as it says there is an ACL blocking something, though I can't see what.
William
08-16-2012 03:42 PM
Looks like the webvpn service is not running.
http://www.cisco.com/en/US/docs/security/asa/asa84/system/message/logmsgs.html#wp5849846
Indeed DTLS would not change anything, because it's only used once successful TCP sessions has been established.
If it's the problem is now with the webvpn service being running, open up a TAC case so they can have a look on the ASA what's missing.
08-16-2012 04:25 PM
No. You had already cracked it
I had put a static route in for the VPN allocated range to tie it to the original interface from my original concept
removing that route allowed the Remote Access VPN traffic to go on the default (newwan) route.
It (the error log) really was telling the truth.
Now I just need to replicate it when we go live.
THANK YOU VERY MUCH for your assistance.
Regards
William
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