cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1157
Views
10
Helpful
10
Replies

VPN site-to-site LAN to multi LAN connection

christowilson
Level 1
Level 1

hello experts,

I have  a site-to-site connection, currently I have a stabale connection from my LAN 192.168.1.100 /24 to far end LAN 192.168.55.1 /24, and now I need to add another LAN connetion from my current LAN to anew LAN from the far-end (I want to have an interconnection to multi LAN in the far end). the LAN ip address of the new LAN in the far end is 172.16.1.1 /24

I applyed below policy from both ends  but it couldn't work

my end:

access-list 101 permit ip 192.168.1.0 0.0.0.255 192.168.55.0 0.0.0.255

access-list 101 permit ip 192.168.1.0 0.0.0.244 172,16.1.0 0.0.0.225

in the far end I applyed:

access-list 102 permit ip 192.168.55.0 0.0.0.255 192.168.1.0 0.0.0.255

access-list 102 permit ip 172.16.1.0 0.0.0.255 192.168.1.0 0.0.0.255

I need yor advice please.

thanks,

1 Accepted Solution

Accepted Solutions

The syntax of your change seems to be right (other than the typo in the original post) and I do not believe that the configuration itself is the problem (assuming that it was implemented correctly on both routers).

One potential issue might be a question of timing. When you make the configuration change the existing Security Associations are based on the old config. Did you flush the SAs and force them to renegotiate? Otherwise you need to wait until the SAs expire and are renegotiated. This is true on both ends. One way to check this would be to look into the output of show crypto ipsec sa and see if the new LAN addresses are in the SA.

The other possibility might be something like a routing issue on the other end. What can you tell us about the topology of the other side? Is the new LAN directly connected on the same router and the current LAN? Is it possible that there is some access list restrictions that are impacting traffic from the new LAN (might be possible on either side)? Is it possible that there is some special routing on the other side that is not sending traffic from the new LAN out the interface where the crypto map is connected? I am not clear what platform these are configured on and this might make a difference. It is not clear whether these devices are doing address translation and if so whether there needs to be a change in address translation to not translate traffic for the new LAN.

What can you tell us about these questions?

HTH

Rick

HTH

Rick

View solution in original post

10 Replies 10

Bor Marton
Level 1
Level 1

my end:

access-list 101 permit ip 192.168.1.0 0.0.0.255 192.168.55.0 0.0.0.255

access-list 101 permit ip 192.168.1.0 0.0.0.255 172,16.1.0 0.0.0.225

in the far end I applyed:

access-list 102 permit ip 192.168.55.0 0.0.0.255 192.168.1.0 0.0.0.255

access-list 102 permit ip 172.16.1.0 0.0.0.255 192.168.1.0 0.0.0.255

access-list 101 permit ip 192.168.1.0 0.0.0.244 172,16.1.0 0.0.0.225

is 244 -->255

Hello Bor Marton,

this is my mistake in typing. in the real it is 255 and not 244. and from my end when I apply to the new far end LAN I don't have any reply.

your advice please.

thanks,

The syntax of your change seems to be right (other than the typo in the original post) and I do not believe that the configuration itself is the problem (assuming that it was implemented correctly on both routers).

One potential issue might be a question of timing. When you make the configuration change the existing Security Associations are based on the old config. Did you flush the SAs and force them to renegotiate? Otherwise you need to wait until the SAs expire and are renegotiated. This is true on both ends. One way to check this would be to look into the output of show crypto ipsec sa and see if the new LAN addresses are in the SA.

The other possibility might be something like a routing issue on the other end. What can you tell us about the topology of the other side? Is the new LAN directly connected on the same router and the current LAN? Is it possible that there is some access list restrictions that are impacting traffic from the new LAN (might be possible on either side)? Is it possible that there is some special routing on the other side that is not sending traffic from the new LAN out the interface where the crypto map is connected? I am not clear what platform these are configured on and this might make a difference. It is not clear whether these devices are doing address translation and if so whether there needs to be a change in address translation to not translate traffic for the new LAN.

What can you tell us about these questions?

HTH

Rick

HTH

Rick

hello Richard,

thanks for your advice,

regarding the platforms; my end I used Cisco 2921 ISR router and at the far end (my customer end) they have a JUNI router, also I have applyed translation on my end but I missed to exclude the new LAN far end in the translation. maybe this is the reason.  once I changed the NAT access list I will let you know about the result.

for the SA I did flush the current SA for many times from my end as well as at the far end, but this did not make any sense.

regarding the topology I have an active tunnel to the BGP router, I am not sure about the topology. what happen if there was not a direct connection between the new LAN and the GW?

much appreciate your reply and support.

best regards,

If you are doing address translation and if you excluded the existing LAN addresses from translation then you probably need to also exclude the new LAN addresses. And if you did not do this then it could quite well prevent the new VPN from working. Please make that change, test again, and let us know the results.

It is good to know that you did flush the SAs. Do you still think that it makes no sense to flush the SAs?

In my experience when a second LAN (used for VPN) is connected to the same router as the first then it is highly likely that the second LAN will be routed in the correct way to send it over the VPN. When the second LAN is not directly connected then it increases the possibility that the second LAN is routed in a way that does not go over the VPN. So I was trying to establish how likely this was to be a factor.

Let's wait for the results of testing after changing address translation before we explore the other possibilities of the cause.

HTH

Rick

HTH

Rick

Hello Rick,

I have to exclude the new LAN IP address from the translation, I think I can apply this with in next week. once I changed the configueration I will let you know.

currently flushing the SAs does not make any sense, because as you know there is one required step is not done yet.

thanks alot for your reply and support.

regards,

Chris

Chris

If you know that one required step is not yet done, then I agree that it does not make much sense to flush the SAs. My point was that when you have made changes and are starting to test to see if they work then you do need to flush the SAs. I have had the experience that people do a show run, see the changes are in place and look right, but the problem behavior still is happening and are confused (because they do not realize that the configured change does not immediately change the active SAs).

HTH

Rick

HTH

Rick

Hi Rick,

you right, for many times I applyed sh run, but on last Thursday I was very busy next to this activity, so I forgot to check the NAT translation ACL. any way I do change all required points then  I will let you know about the result.

thanks,

Hi Rick,

I resolved the issue; first of all I missed to exclude the IP address from translation, secondly and from my customer ends they did a mistake in fonfiguring the ACL of VPN, I resolved by correcting both.

many thnkas,

Chris

I am glad that you got the problem solved and that our suggestions were helpful in finding the solution. Thank you for using the rating system to mark this question as answered. It makes the forum more useful when people can read about an issue and can know that a solution was found. It is especially helpful when the discussion is an interesting one like this has been. Your marking of the question has contributed to this process.

HTH

Rick

HTH

Rick
Review Cisco Networking products for a $25 gift card