cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2940
Views
5
Helpful
15
Replies

1811W Radius/AAA over VPN Tunnel

rbcastle
Level 1
Level 1

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.

2 Accepted Solutions

Accepted Solutions

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

HTH

Rick

View solution in original post

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.

View solution in original post

15 Replies 15

Richard Burts
Hall of Fame
Hall of Fame

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

HTH

Rick

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

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

HTH

Rick

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

This worked perfectly for me.

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

HTH

Rick

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.

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

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.

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!

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.

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

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

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.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: