05-15-2007 01:58 PM - edited 03-03-2019 04:59 PM
I have an 1811W router in China. There is a VPN tunnel to the US. This is working fine. Now I'd like to set up wireless to authenticate back to a radius server in the US (they don't have their own server.) I am using the same setup in the Netherlands except they have a radius server locally. The problem seems to be that the router can't forward the radius packets through the vpn tunnel. I also can't ping and traceroute to an address on the other side of the vpn tunnel goes out the internet connection instead of through the tunnel. I have searched these postings and contacted a local ccnp but haven't found resolution yet. Any thoughts? I'm going to go to local WPA but don't want to run that way long term.
Solved! Go to Solution.
05-15-2007 07:24 PM
Randy
It is not quite clear from your post but I am assuming that 192.168.11.0 is the subnet on the LAN of the remote router. Depending on how you have configured the router the source address used for Radius is probably not the LAN IP address. By default the source address used by the router will be the address of the outbound interface. This is also true for ping and traceroute, that by default the source address will be the address of the outbound interface. To get to the other router the outbound interface has some other address (probably a public address).
The solution for Radius is pretty simple.
There is a command ip radius source-interface. If you use this then the router will use whatever interface address that you specify (in this case the LAN interface). The solution for ping and traceroute is either to use extended ping and extended traceroute where you can specify the source address as the LAN interface or to add to the access list some lines which will identify traffic sourced from the local outbound interface and destined to the remote network.
HTH
Rick
05-15-2007 08:05 PM
One thing I've found to be tricky is what interface the radius traffic is originating on. ie: if its originating on the WAN interface, its traffic is definitely not going to be encrypted, yet if it originates on your ethernet interface (or loopback interface) it could do it with the ACL you have there...
Try using the "ip radius source-interface " to make sure the interface its originating the radius packet from is in the 192.168.11/24 network.
Something you might also want to look into is GRE tunnels. If you form a GRE tunnel from the source to the destination router and run all your traffic about that, your ACL for what goes through the IPSEC tunnel could simply specify the GRE tunnel and all traffic encapsulated in the tunnel would get encrypted as a result.
However, I'm betting if you specify the source interface for your radius packets that it will start working.
05-15-2007 02:05 PM
Randy
Assuming that the VPN terminates on the router my best guess is that the access list that identifies traffic to be protected by VPN probably does not identify the AAA Radius requests as traffic to be protected. I am guessing that ping and traceroute may be the same issue. Remember that the access lists of each end of the tunnel should pretty much mirror each other.
If you are not sure or if this does not help then I would suggest that you post the config from the router (changing public addresses and hiding passwords).
HTH
Rick
05-15-2007 02:18 PM
Rick,
I think you understand the basic issue. The wireless and the vpn tunnel are on the same device. The traffic directly from the router doesn't seem to be getting encrypted/protected.
Could you give me an example of what protecting for ping might look like.
China local address 192.168.11.1 (/24)
US local address 10.0.0.1 (/8)
Here's the ipsec rule that I think applies to the traffic:
access-list 104 remark SDM_ACL Category=4
access-list 104 remark IPSec Rule
access-list 104 permit ip 192.168.11.0 0.0.0.255 10.0.0.0 0.255.255.255
Pretty simple!
I can post more if you think it would be helpful. I'm currently setting up for local auth so they can function tonight but it would be best if I could go back to radius.
Thanks!
Randy
05-15-2007 07:24 PM
Randy
It is not quite clear from your post but I am assuming that 192.168.11.0 is the subnet on the LAN of the remote router. Depending on how you have configured the router the source address used for Radius is probably not the LAN IP address. By default the source address used by the router will be the address of the outbound interface. This is also true for ping and traceroute, that by default the source address will be the address of the outbound interface. To get to the other router the outbound interface has some other address (probably a public address).
The solution for Radius is pretty simple.
There is a command ip radius source-interface. If you use this then the router will use whatever interface address that you specify (in this case the LAN interface). The solution for ping and traceroute is either to use extended ping and extended traceroute where you can specify the source address as the LAN interface or to add to the access list some lines which will identify traffic sourced from the local outbound interface and destined to the remote network.
HTH
Rick
05-16-2007 06:37 AM
Rick,
I think that helps a lot. I tried the extended ping and traceroute and they worked perfectly. I'll configure up the radius later today (when China goes to sleep!) and let you know how that worked.
I learned something new today. Thanks!
Randy
05-16-2007 01:43 PM
This worked perfectly for me.
05-16-2007 05:03 PM
Randy
Thanks for letting us know that it worked. And thanks for using the rating system to indicate that your problem was solved. It helps to make the forum more useful when people can read about a problem and can know that they will also read a solution that was successful in resolving the problem.
I encourage you to continue your participation in the forum.
HTH
Rick
05-15-2007 08:05 PM
One thing I've found to be tricky is what interface the radius traffic is originating on. ie: if its originating on the WAN interface, its traffic is definitely not going to be encrypted, yet if it originates on your ethernet interface (or loopback interface) it could do it with the ACL you have there...
Try using the "ip radius source-interface " to make sure the interface its originating the radius packet from is in the 192.168.11/24 network.
Something you might also want to look into is GRE tunnels. If you form a GRE tunnel from the source to the destination router and run all your traffic about that, your ACL for what goes through the IPSEC tunnel could simply specify the GRE tunnel and all traffic encapsulated in the tunnel would get encrypted as a result.
However, I'm betting if you specify the source interface for your radius packets that it will start working.
05-16-2007 06:39 AM
Craig,
Looks like you came to the same conclusion Rick did. I think it's going to work and I'll let you both know later today.
Thanks!
Randy
05-16-2007 01:40 PM
I have a very similar problem but on my Cisco ASA. I can authenticate to a local RADIUS server fine, but if I try to authenticate to a remote RADIUS server over an IPSec tunnell, the message never makes it's way to the other side and I get timeouts when I test AAA. Do you know of an equivalent command I can run in the ASA that would do something like your 'ip radius source-interface' command?
Thanks.
05-18-2007 01:50 AM
Replying to my own message... with the help of this forum and some help from Cisco, I've resolved this problem. What I had to do is tell the ASA to use the private interface to connect to the server, AND enable the private interface for management access. Then, I just had to make sure the remote radius server had the ASA internal address as a client and then my AAA worked!
10-10-2007 02:18 AM
Do you know if this works with TACACS on the ASA, as I cant get it to work, the ASA does not see the ACS server.
10-10-2007 04:28 AM
Hmm... Once I had TACACs configured right on my ASA I didn't have to do anything that odd to get it working. It is a bit odd to configure. Here is an example (lucky I was just working on this yesterday!!). I think the only problem I had was realizing I needed to do a route to get to the TACACs server for the management interface, otherwise it only wants to get to its own subnet.
interface Management0/0
nameif ManagementIF
security-level 100
ip address 192.168.1.5 255.255.255.0
management-only
!
route ManagementIF 0.0.0.0 0.0.0.0 192.168.1.1 255
aaa-server myadmin protocol tacacs+
aaa-server myadmin (ManagementIF) host 192.168.2.50
key mytacacskey
aaa authentication telnet console myadmin LOCAL
management-access ManagementIF
10-12-2007 01:15 AM
Craig,
Our config is a bit different, we have a VPN between two ASA's, the remote site ASA has a outside and inside, + some DMZ's. I have configured the inside as the management-access interface and I know this works, as its used for SNMP, Telnet, and HTTP access.
The debug that I have done so far shows IPSec creating an SA to its peer if I use the AAA test command from the ASA CLI.
What software version are you using?
Thanks.
Gary
10-12-2007 04:24 AM
Ok, first question, by saying you've configured the "inside" interface as the management access, do you mean you did the "management-only" on the interface? If so, I believe that allows for incoming management traffic from the network behind it, I don't believe it allows traffic to pass through to the "outside" interfaces from it. I don't think you can have it configured as a "management-only" interface at the remote end and have the "AAA" server on the local end. I could be wrong in my interpretation though.
However, if you don't have it configured as "management-only" and you have the "AAA" configured the same on both ends, I would suspect two things. First routing, second firewall rules. You can probably simulate either by using the "packet tracer" in ASDM to figure out which it is and where it is.
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