Route specific subnets over VPN tunnel?

[Anonymous]

Hi,  I've got a VPN tunnels set up between two NV3430 routers, and it works fine for all LAN devices on both sides to see each other.

One side has a LAN of 192.168.1.1/24 and a static WAN that's on the Internet.

The other side has a LAN of 192.168.0.0/24 and a static WAN on another LAN: 192.168.128.0/17 that's routed to the Internet (double-NAT).

I'd like the devices on the 192.168.1.0 LAN to be able to talk to the devices on the 192.168.200/0 LAN, but not the other way around.

I've tried:

Adding 192.168.128.0/17 to the VPN Peer "Destination Networks Allowed to Communicate Using <TunnelName>"

Adding 192.168.128.0/17 to the Route Table

Adding another traffic selector (permit any 192.168.1.0/24 192.168.128.0/17) to the "AllowReverse" policy for the Public Security Zone.

Nothing seems to work, though it looks like I'm on the right track somewhere, because 'ping 192.168.200.10' from the 192.168.1.0 LAN doesn't get a Destination Net Unreachable from my local ISP.

So how do I get traffic to go out the WAN interface of the remote router over the tunnel?  [Note that I don't want everything on the 192.168.128.0 LAN to be able to see into my 192.168.1.0 LAN]

While I can use the CLI, I'd prefer a solution using the GUI...

Thanks!

[jayh]

I'm not exactly sure of your addressing scheme. Is 192.168.200.0/24 a different network than 192.168.128.0/17? It's contained within 192.168.200.0/24 so you may have a routing issue of some kind if indeed you're trying to access it separately.

[Anonymous]

Sorry for the confusion, the "WAN" side of the far network is 192.168.128.0/17 though most things on it are in 192.168.200.*

I'd like the LAN devices on the near network (192.168.1.*) to be able to access anything on 192.168.128.0/17 through the VPN tunnel.

Thanks!

[jayh]

You say that the far side has a WAN of 192.168.128.0/17. Is the outside of the far side tunnel also anchored to an address within 192.168.128.0/17 ?

In other words are you trying to protect traffic with an inside subnet on the tunnel with an outside interface in the same subnet? This is going to be problematic. Where is NAT occurring for Internet access on the site with a WAN of 192.168.128.0/17 ? On another device? How are you routing from the local device to the far side box on 192.168.128.0/17?

[Anonymous]

I'm not sure I'm using the proper terminology my apologies.

I have a remote office, with a LAN of 192.168.0.0/24 and a WAN of 192.168.128.0/17, with an Internet gateway on that network of 192.168.200.3

When I'm in the remote office, I can talk to devices on that WAN like 192.168.200.10

I have a main office, with a LAN of 192.168.1.0/24 and a VPN tunnel between them.

From my main office, I'd like to be able to talk to devices like 192.168.200.10

I'm sure there's a way to do this, my main office NV3430 has to route traffic for 192.168.128.0/17 to the VPN tunnel, and the remote office NV3430 has to pass that traffic to it's WAN interface, yes?  My problem is finding the incantation to make this happen, there's no entry in the route table for "VPN Tunnel"...

Does that make more sense?

Thanks!

[jayh]

It kind of makes sense, I'm using some generic terms not Adtran-specific. An IPSEC VPN has a source and destination IP for the tunnel itself, these are typically the WAN interfaces of the routers facing the Internet. The connection between the two routers is made on these interfaces, and they are typically public IP addresses.

The protected encrypted traffic is then configured with symmetrical access-lists, showing what traffic is to pass through the VPN tunnel established between the two WAN endpoints.

In other words, the VPN tunnel itself is built between two specific IP addresses, usually over the public Internet. These are the interfaces to which the crypto map statement is applied. The actual traffic that traverses the VPN is defined by the ACLs in the traffic selectors, and is usually the LAN subnets on both routers.

It sounds like the side of the connection that has 192.168.128.0/17 containing both the outside WAN interface where the crypto map is applied and also the traffic that is to be encrypted within the tunnel. This isn't going to work, at least not with any kind of standard configuration. The interface to which the crypto map is applied should be in a different network than that of the subnet that is supposed to pass through the VPN.