Routing Issue through VPN Tunnel

[Jarin_Blackham]

I've installed a new RV160 at a remote site and successfully established a site-to-site tunnel to my main site.  Traffic is passing through the tunnel between the remote subnet an the main office's subnet.  The problem I'm having is trying to access a different subnet at the main office.  When I traceroute from the remote site to the main office subnet, it goes through the tunnel.  When I traceroute from the remote site to the main office subnet2, it hits the public interface and says it is unreachable.  I added a static route to the RV160 that would route packets destined for subnet2 to the proper gateway within the main office subnet, but the traceroute still shows the packets try to go out the public interface.  

I set up the VPN tunnel with the proper subnet of the remote site, and with IP Type of ANY at the main office.  I've verified the routing table at the main office - but this wouldn't affect the way the RV160 is treating packets, even with a static route for subnet2.  Could this be a bug in the firmware?  I'm on version 1.0.00.17.

[insideshell]

Can you post the relevant items of your configuration?
As well as the routing table on the remote site?

[Jarin_Blackham]

(Sensitive network information has been obfuscated)

Main Site
     Subnet1:  X.X.1.0/24 (data network)
     Subnet2:  X.X.2.0/24  (voip network)
     Public IP:  X.X.199.254

Remote Site
     Subnet:  X.X.100.0/24
     Public IP: X.X.122.91

VPN Tunnel (Site-to-site, established)
    Main Site
          Local identifier: X.X.199.254
          Local Type: Subnet - X.X.1.0/24    (also tried this as ANY)
          Remote identifier:  X.X.122.91
          Remote Type: Subnet - X.X.100.0/24

     Remote Site
          Local identifier: X.X.122.91
          Local Type: Subnet - X.X.100.0/24
          Remote identifier:  X.X.199.254
          Remote Type: Subnet - X.X.1.0/24    (also tried this as ANY)

Routing Table at Remote Site (RV160):

      Destination             Next Hop         Hop Count                     Interface                 Source
      0.0.0.0/0              X.X.122.89            4                                  WAN                    Static
      X.X.100.0/24         --                         0                                 VLAN1                 Direct
      X.X.122.88/29        --                        4                                 WAN                    Direct

Here is the interesting thing which I see.  I've added the following static route under Routing, but it doesn't show up in the routing table (above).  Almost like there is a disconnect between saving the static route, and actually posting it to the routing table.

Network        Mask                   Next Hop                                          Hop Count (Max 255)              Interface
X.X.2.0      255.255.255.0       X.X.1.254(gateway to subnet2)           0 (also tried 4,5 and 255)      VLAN1 (Also tried WAN here)

[insideshell]

Thanks for the configuration. And yes, sometimes posts and replies get marked as spam...

Unfortunately, I am no RV160 expert. But I have to say your configuration looks good. I would have tried the same thing actually: use ANY both at the Main Site → Local Type and Remote Site → Remote Type fields. Did you use ANY on both fields at the same time and then reset the IPSec tunnel? Also, when you're doing your ping/traceroute from the remote site, are you using an IP address of x.x.100.0/24 subnet as the source?

I don't think it is necessary to add a static route for the remote site to access x.x.2.0/24 on the main site. The default route should be enough, as it already works for accessing x.x.1.0/24 on the main site if I understood well.

[Richard Burts]

I agree that it is probably not necessary to configure the static route for x.x.2.0. (does not hurt to have it, but I believe it is not required). I would expect to see something in the vpn part of the configuration for x.x.2.0.

[Jarin_Blackham]

ANY on both sides isn't an option.  When you select ANY on either the local or the remote, ANY is removed as on option for the other side.  

I did the ping and traceroute both from a laptop connected in the x.x.100.0/24 subnet and directly from the router's diagnostic page.  Same result from both.  When I ping a server in x.x.1.0/24 i get a reply and the traceroute shows the path across the tunel.  When I ping a server in x.x.2.0/24, I get destination is unreachable and the traceroute shows the public IP on the router.

This is the reason I thought I'd need a static route.

[Richard Burts · Accepted solution]

Thanks for the clarification. If you think about it you really do want the routing for x.x.1.0 and x.x.2.0 to be the same - traffic to both subnets should go out the same outside interface to the same next hop address. What is different is not about routing but is about the fact that one destination is part of the vpn and its traffic is encrypted while the other destination is not part of the vpn and its traffic is not encrypted. The solution is to change the configuration of both routers to that they both consider x.x.2.0 to be part of the vpn.

[Jarin_Blackham · Accepted solution]

Thanks everyone for helping me to troubleshoot this issue.  I finally found the solution last night.  There is a Remote IP type of "IP Group" that I hadn't noticed.  I selected IP Group, then added the subnets that I needed to access from the remote site.  I then figured out how to add the same subnets (flipped) to the Main Office VPN.  From my testing, it seems that the VPN tunnel routing is separate from the actual routing table.  I do think there is still a problem with the firmware, since adding a static route doesn't show up in the routing table - but it is a separate issue that isn't relevant to my configuration or my original question.  

One thing to note -- on the IP Group type -- when you create and name an IP group, I couldn't find a way to modify or add new IP subnets to the named group.  To add another subnet, I had to add all the subnets again and give it a new name.  There isn't a way to just edit a group, and there isn't a way to delete an old group. They all show up in the drop-down menu.  Management of IP groups might be a good feature request for a future firmware update.

Thanks again for everyone's help!

[insideshell]

Glad you could find it yourself and thanks for detailing the solution! I think this is somewhat what @Richard Burts has advised, i.e., "The solution is to change the configuration of both routers to that they both consider x.x.2.0 to be part of the vpn."

[Jarin_Blackham]

Thanks for pointing that out @insideshell!  I've added his comment as a solution because @Richard Burts is correct, I just didn't see his post until afterward.

[Jarin_Blackham]

Thank you Richard!  I missed your post before I found my solution and it was exactly as you said - I needed to have both sides know of the routes.  If I had seen your post Friday afternoon, I may have solved it earlier.  One thing that baffled me is at one point I set the main office subnet up on both sides to be x.x.0.0/16, which should have taken care of the issue, but it didn't, which added to the confusion.  

Thanks again!

[Richard Burts]

You are welcome. I am glad that you were able to find your own solution to your issue. It is good when someone posts in the community about an issue and then finds their own solution. My suggestion did point you in the right direction and I appreciate that you acknowledge it. It is not a problem that you had missed it and not notice it till after you had found your own solution.  This community is an excellent place to ask questions and to learn about networking. I hope to see you continue to be active in the community.

[Richard Burts]

I have a few thoughts about the attempt to add the route and why it does not show up in the routing table. My first thought is about the next hop specified as x.x.1.254. If I am understanding the topology correctly this would be in the subnet at the main site. I would expect the next hop to be something local to the remote such as x.x.122.89. My other thought is about the hop count set to 0. That would indicate a locally connected subnet. But this subnet is remote and the hop count should indicate this.

[Georg Pauwen]

Hello,

in the 'Remote IP Type' select 'Subnet' instead of 'Any', does that make a difference ?

[Jarin_Blackham]

I originally set it up with Subnet, and when it wouldn't pass traffic to the main site subnet2, I changed it to ANY to see if that would allow it.  I just changed it back to subnet, and still experience the same issue.  I'll post the relevant data shortly (in response to the other question).