Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

VPN Routing Access List

Hi,

I have a PIX 525 at my main site and a 1721 router at a remote location. I used the PDM and SDM to set up an IPSec site-to-site VPN connection. In my private network, I use 10.1.0.0/16 for the main site and 10.x.0.0/16 (where x=2 through 47) for the remote sites.

The remote site with the VPN connection uses 10.19.0.0/16. When I initially set up this VPN, I only configured traffic to flow from the remote site to 10.1.0.0/16. This means that this remote site can not talk to any other remote sites, just the main site.

I need to modify the access list to fix this problem. The relevant part of the remote site's access list is now:

access-list 103 permit ip 10.1.0.0 0.0.255.255 10.19.0.0 0.0.255.255

access-list 103 deny ip 10.19.0.0 0.0.255.255 any

Can I just change the subnet mask in the first line and put the second line first?

access-list 103 deny ip 10.19.0.0 0.0.255.255 any

access-list 103 permit ip 10.0.0.0 0.255.255.255 10.19.0.0 0.0.255.255

Or will I need to leave the deny statement at the end and add one line for each of the other remote sites:

access-list 103 permit ip 10.1.0.0 0.0.255.255 10.19.0.0 0.0.255.255

access-list 103 permit ip 10.2.0.0 0.0.255.255 10.19.0.0 0.0.255.255

access-list 103 permit ip 10.3.0.0 0.0.255.255 10.19.0.0 0.0.255.255

access-list 103 permit ip 10.4.0.0 0.0.255.255 10.19.0.0 0.0.255.255

...(others)

access-list 103 deny ip 10.19.0.0 0.0.255.255 any

Thanks.

John

1 ACCEPTED SOLUTION

Accepted Solutions
Hall of Fame Super Silver

Re: VPN Routing Access List

John

The additional config information that you posted does help. There are still a few things that I would hope could be clarified. It appears that you have 46 remote sites and only one is connected through a VPN. How do the other have connectivity? Is it all over links within your private network? Is there any NAT involved in these other connections?

In my previous response I assumed that there would be multiple VPN connections, which your additional information shows is not the case. So my comment about limitations in PIX for spoke to spoke is true but not applicable to your situation.

Will the other remote sites also be coming over the VPN? If so access list 100 which the 1721 uses to identify traffic for IPSec (and which was not included in your posted material) will likely need to be changed.

As far as access list 103 is concerned, I assume that the deny ip 10.19.0.0 0.0.255.255 any is an anti-spoofing measure? If so I would probably advocate putting it as the first entry in the access list. As for whether to use permit ip 10.0.0.0 0.255.255.255 10.19.0.0 0.0.255.255 or a series of individual permits I believe one point to consider is that permit 10.0.0.0 0.255.255.255 will permit the entire 10 address space. It appears that you are using 1 through 47. What if something came through from 10.122.x.x? I would suggest a compromise approach. You could use this:

permit ip 10.0.0.0 0.31.255.255 10.19.0.0 0.0.255.255

permit ip 10.32.0.0 0.15.255.255 10.19.0.0 0.0.255.255

This would permit 1 through 47 but not any others.

HTH

Rick

8 REPLIES
Hall of Fame Super Silver

Re: VPN Routing Access List

John

I do not understand how this access list is being used at the remote site. It might be an access list on the interface examinging incoming traffic or it might be an access list defining the traffic to be protected by IPSec. It seems to be structured more like an inbound interface access list than an IPSec traffic identifier. Perhaps you can clarify.

And depending on the version of code that you are running on the 525 you may have a bigger problem than how to change the access list. In traditional PIX code the PIX will not forward traffic out the same interface that it was received on. This means that in traditional hub and spoke networks each spoke can communicate with the hub but not with other spokes. What version of code is running on the PIX?

HTH

Rick

New Member

Re: VPN Routing Access List

Hi Rick,

Thanks for the reply.

The PIX is running 6.3(4) and the 1721 is running 12.4.

That is part of the inbound access list for the outside interface on the 1721.

I've attached some partial configs that should clarify things, please let me know if you need more.

I'm headed out to the remote site now to try some things since there is no school today. I'll post again when I get back in a few hours.

This is helpful because if I run into a brick wall here, I'll have a clue as to what might be happening.

John

Hall of Fame Super Silver

Re: VPN Routing Access List

John

The additional config information that you posted does help. There are still a few things that I would hope could be clarified. It appears that you have 46 remote sites and only one is connected through a VPN. How do the other have connectivity? Is it all over links within your private network? Is there any NAT involved in these other connections?

In my previous response I assumed that there would be multiple VPN connections, which your additional information shows is not the case. So my comment about limitations in PIX for spoke to spoke is true but not applicable to your situation.

Will the other remote sites also be coming over the VPN? If so access list 100 which the 1721 uses to identify traffic for IPSec (and which was not included in your posted material) will likely need to be changed.

As far as access list 103 is concerned, I assume that the deny ip 10.19.0.0 0.0.255.255 any is an anti-spoofing measure? If so I would probably advocate putting it as the first entry in the access list. As for whether to use permit ip 10.0.0.0 0.255.255.255 10.19.0.0 0.0.255.255 or a series of individual permits I believe one point to consider is that permit 10.0.0.0 0.255.255.255 will permit the entire 10 address space. It appears that you are using 1 through 47. What if something came through from 10.122.x.x? I would suggest a compromise approach. You could use this:

permit ip 10.0.0.0 0.31.255.255 10.19.0.0 0.0.255.255

permit ip 10.32.0.0 0.15.255.255 10.19.0.0 0.0.255.255

This would permit 1 through 47 but not any others.

HTH

Rick

New Member

Re: VPN Routing Access List

Rick,

Yes, all other sites are connected over leased lines within the private network. Everything is connected to the 10.1.0.0 main site through one or more routers that our service provider owns and maintains at their head end. The lines from all schools go to the service provider, and one much bigger line comes from the service provider to the main site.

This is currently the only VPN connection. I did manage to figure out that access list 100 is what I need to change, once I got down there and started working. I added another line to that access list to identify traffic going to 10.2.0.0 as a test.

At that point, I still could not ping from 10.19.0.1 to 10.2.0.1. I tried some traceroutes from 10.23.0.1 to 10.19.0.1 and it appears that traffic is never getting through the service providers router(s). I put the 1721 back the same way it was by reloading without saving, that full config is attached. I apologize for the partial config before, I thought I was helping by cutting down on the information posted.

I am not sure why the deny ip 10.19.0.0 0.0.255.255 in access list 103 is there. I attempted to set this VPN up initially over a year ago through the command line, and could not get it working.

When I used the SDM - with the same exact commands - it worked. It looks like there is a lot of extra stuff that is not needed in this config, placed there by SDM. I did restore it to factory defaults between my failed attempt and the SDM attempt that worked, so all of that was done by SDM. Frankly, I'm scared to mess with it much since I can't explain why I couldn't get it going without SDM in the first place.

I really like that 0.15.255.255 mask idea. We will be adding more schools in the next few years, but I should be able to modify that mask later on to let some more subnets through. If I use that mask, 10.19.0.0 traffic is included. I want anything headed from 10.19.0.0 to 10.19.0.0 to stay in the LAN attached to FastEthernet0 without going over the VPN. Is that an issue?

I am planning on adding that line to access list 100 again remotely that would send traffic headed to 10.2.0.0 through the VPN connection. If I'm understanding this, that should mean that once the service provider adds a route, we could ping from 10.2.0.1 to 10.19.0.1. At that point I would probably use that mask you suggested instead of adding more lines for each subnet.

John

Hall of Fame Super Silver

Re: VPN Routing Access List

John

I appreciate the intent to try to be efficient and send parts of the config. Unfortunately it hid several parts that do matter. Thanks for posting the more complete config.

My first observation is that in addition to changing access list 100 which identifies traffic to be protected by IPSec you will also need to change access list 101 which identifies traffic to have address translation. Traffic going through the IPSec should not be translated. I suspect that this was the major problem in your attempt to test with 10.2.x.x.

My second observation is that the deny ip 10.19.0.0 any in access list 103 is fairly typical anti-spoofing technique. If 10.19 is on the inside inteface it is invalid to have that as the source address on traffic coming in the outside interface. I would suggest that it might go at the top of the access list.

My next observation is that we perhaps need to clarify how you want the other remote locations to communicate with 10.19. I am assuming that you want the other locations to use the VPN. In that case you do not need to have the provider configure routes to 10.19 for the other locations. From the other locations their route to 10.19 should send traffic to the PIX. The PIX is the one who will put that traffic into the VPN.

Which leads to my next observation. If you want other locations to communicate with 10.19 via VPN then these two access lists on the PIX need to be changed:

access-list inside_outbound_nat0_acl permit ip 10.1.0.0 255.255.0.0 GWS 255.255.0.0

access-list outside_cryptomap_20 permit ip 10.1.0.0 255.255.0.0 GWS 255.255.0.0

HTH

Rick

New Member

Re: VPN Routing Access List

Rick,

I used the SDM to change access list 100. It warned me about needing to change access list 101 so that this new VPN traffic would not be NATed, and it changed it for me. I've attached the new config that shows that this seems to be okay.

I will take your advice about the deny statement in 103, that makes sense to me.

I do want the other locations to use the VPN. My problem is that traffic destined for 10.19 from other sites never seems to reach the PIX. My intent was to have the provider set up a route pointing traffic that is headed to 10.19 to the PIX, and let the PIX handle it from there. It's possible that the route already exists, and maybe the PIX is just not responding to the traceroute. If that was the case, I would hope to have the ping from 10.2 to 10.19 work, even if the traceroute didn't. That's what made me think that the provider should check/add that route.

However, I did not change anything on the PIX. Until I change those access lists there, that ping could not have worked. That could be my problem at this point. I will try this out.

I will need to wait until Monday to try that.

By the way, thanks for sticking with me for so long on this one. I have used the NetPro forums a few times before when I was really stuck, and I really appreciate the time that everyone gives to helping other people out. I just wish I would have asked for help earlier!

I will make sure to rate your posts when we are done here, thanks again.

John

Hall of Fame Super Silver

Re: VPN Routing Access List

John

I look forward to hearing on Monday how this works. I have looked at the new config that you posted and it looks to me like the 1721 is correctly set up to communicate with both 10.1 and 10.2 via VPN.

Based on what I think I understand about the topology of your network I would assume that the provider has routes in place for the other remotes (including 10.2) which would send traffic for any 10 (or perhaps anything in the range 10.2 to 10.47) to 10.1. If you try a traceroute from 10.2 attempting to get to 10.19 what output do you get and how far does it appear to get? Does it get to the HQ router? Is there possibly logic in the HQ router that does not pass traffic from remotes to other remotes?

I have sometimes used this technique in troubleshooting problems such as the one you are dealing with: from a device in 10.2 show ip route 10.19.0.1, find the next hop toward 10.19.0.1 and telnet to it. Then show ip route 10.19.0.1, find the next hop, telnet (repeat as many time as necessary). This should basically parallel the output of traceroute. As you telnet along look for things that might stop traffic headed toward 10.19.

Good luck.

HTH

Rick

New Member

Re: VPN Routing Access List

Rick,

This is working now that the two access lists on the PIX have been changed!

I am still testing with allowing traffic from 10.2 to go to 10.19, so my access lists on the PIX are now:

access-list inside_outbound_nat0_acl permit ip 10.1.0.0 255.255.0.0 GWS 255.255.0.0

access-list inside_outbound_nat0_acl permit ip 10.2.0.0 255.255.0.0 GWS 255.255.0.0

access-list outside_cryptomap_20 permit ip 10.1.0.0 255.255.0.0 GWS 255.255.0.0

access-list outside_cryptomap_20 permit ip 10.2.0.0 255.255.0.0 GWS 255.255.0.0

The access list on the 1721:

access-list 100 permit ip 10.19.0.0 0.0.255.255 10.1.0.0 0.0.255.255

access-list 100 permit ip 10.19.0.0 0.0.255.255 10.2.0.0 0.0.255.255

If I change these access lists to specify 10.0.0.0 255.224.0.0 and 10.32.0.0 255.240.0.0 on the PIX, with 10.0.0.0 0.31.255.255 and 10.32.0.0 0.15.255.255 on the 1721, this would include all traffic from 10.0.0.1 up to 10.31.255.255.

Since 10.19 is included in that range, will that cause problems? If so, would I just deny 10.19/16 as the first line of these access lists?

John

139
Views
5
Helpful
8
Replies
CreatePlease login to create content