VPN

I am a BIG BIG fan of M0n0wall, and have recently decided to start using it at work for site-to-site VPNs.  We currently have 16 remote sites using Netscreen boxes that our service provider controls.  In an effort to save money, I'm going open source!

I created my first VPN and see traffic flowing FINE in one direction.  (please see attached image of network diagram)   I have defined a static route on my desktop PC directing (traffic destined for the remote VPN's subnet) to the VPN server.  I can get to the remote VPN fine, but the machines in the remote VPN (in this case, the machine called workbench) can NOT see anything in the 192.168.0.0 subnet.  Well, not NOTHING, it can see 192.168.0.16 (the internal interface of the VPN server).  The only thing I can think of is the fact that the 192.168.0.0 subnet has a firewal/router gateway that runs parallel to the VPN server (again, please see the diagram).  Anybody have any ideas how I can get traffic flowing to the main network?

Any input would be greatly appreciated!

Thanks,
Brian

What are the subnet masks on both networks? My first guess is one is /16 and hence the subnets are overlapping.

Good thought.  I should have mentioned that previously.  The subnet mask on both subnets is 255.255.255.0 or /24.

I created my first VPN and see traffic flowing FINE in one direction.  (please see attached image of network diagram)   I have defined a static route on my desktop PC directing (traffic destined for the remote VPN's subnet) to the VPN server.  I can get to the remote VPN fine, but the machines in the remote VPN (in this case, the machine called workbench) can NOT see anything in the 192.168.0.0 subnet.  Well, not NOTHING, it can see 192.168.0.16 (the internal interface of the VPN server).  The only thing I can think of is the fact that the 192.168.0.0 subnet has a firewal/router gateway that runs parallel to the VPN server (again, please see the diagram).  Anybody have any ideas how I can get traffic flowing to the main network?

I ran into the same problem during one of my troubleshootings of a totally different problem, and mine was due to a gateway/routing problem.

Check to make sure that there is a static route in the network's gateway telling trafic that needs to go to the remote VPN site to go through the monowall to get to the other side.

Other than that, I've had the problem where one site was setup as a /25 instead of a /24 accidentally.  It was found out and fixed, but the VPN had been created using the "Local Subnet" option as one of the IP range descriptors.  Everywhere that said what it was trying to use said the right things, but it just wasn't working.  I changed that option to something else, applied it, then changed it back to "Local Subnet" (now that the local subnet on the system was indeed set correctly) and everything then worked.

Thank you for the tip.  Not sure what the problem is, but I now at least know WHERE the problem lies.  It's on the static route on the firewall.  I creates the route and see it in the route list, but for some reason can't get traffic through that VPN.  No worries, I now know that it's not a M0n0wall/VPN tunnel issue, it's a firewall/static route issue and will pursue that.

Thanks again for all the help!

Forgive me if this is slightly off-topic, but I'm not sure where to turn....
One segment of my VPN terminates in a LAN that has a different default gateway than the VPN (please see diagram in my original post).  I have added a static route in the firewall to redirect VPN traffic to the LAN IP of the VPN server.  I can get traffic to flow from my desktop to the VPN (workbench) but traffic from the workbench into the LAN (desktop) fails.  I'm guessing it's defaulting out to the Firewall - which SHOULD be forwarding to the VPN.  Why is this failing?

Assuming testvpn is the default gateway for workbench, it shouldn't be a routing issue. Actually, in this particular diagram you provided, if traffic flows one way and you successfully get replies, routing is fine (it's not always that simple, but should be here).

Only thing I can think of off the top of my head is a host-based firewall that doesn't allow off-subnet traffic. That's pretty common.

CMB:  Thank you for the input, but I’m afraid you may have misunderstood my dilemma.  My desktop computer can ping the workbench computer because it has a static route pointing to the testvpn subnet.  If any other machine on the .0.0 subnet (left side of the diagram) tries to hit the VPN, the traffic never makes it there.  I have a static route on the Firewall telling it to send all traffic for the .30.1 subnet over to vpn-server but that static route is apparently not working.  This is odd because I have 16 other VPNS currently running on a Netscreen box (in parallel to the firewall, just like the vpn-server).   All of those VPNs work fine.  I tried disconnecting the LAN interface of VPN-server from the network and attaching my desktop directly to it (via a crossover cable) and it worked fine.  So it’s not a m0n0wall issue, it’s somehow related to the firewall, but I can’t figure out how…

Any input that anybody can offer would be greatly appreciated.

No, if traffic works one way and the replies get back it's not a routing issue. It can't be. If there's a routing problem the traffic may work one way, but you'll never get replies because the return traffic will fall victim to whatever routing problem you have. If you can, for example, ping from one side to the other side and get replies, the routing on both sides is fine. If there was a routing issue on the other side, your pings may get to that network and get replied to, but the replies will be routed to the wrong place so your originating host won't show a reply because it'll never get to it.

I don't know what the issue is, but it's not routing (at least not completely, it's possible some individual may have routing issues if they have local static routes). If you're not convinced it's a not routing issue you can enter a static route into an individual machine and see if it then works.

I have tried a static route in "Desktop" and it can route data to the workbench.  With that static route in place, Desktop can ping workbench, and workbench replies normally.  However, when I ping Desktop from Workbench, the reply gets lost in routing.  It has something to do with that firewall that's running in parallel to "VPN-server"   Even though the same static route is on that firewall it can't see the test-vpn.  There's something flaky about the routing at that firewall.

Thanks for trying.

   we need a beating head into wall emoticon. 

If "Desktop" has that static route in place, the return traffic won't even touch "Firewall" on the left side of the diagram. 

It's time to break out a sniffer with several NIC's, I'd have one NIC on a port monitoring Firewall's inside interface, one NIC monitoring the inside of "vpn-server", and one NIC monitoring the port of "Desktop". At the other site, a box with two NIC's, one monitoring the port of "testvpn" and the other monitoring the port of "workbench". Then, try that ping that doesn't work again. See where you see it and where you don't. From there, if you have all the points of reference I suggested, you'll know exactly what's going wrong.

Just out of curiosity, if I plug Desktop directly into the VPN-server and it works.  Then put both back on the network, and it doesn't...  What else would you expect to find on the network that would be blocking traffic?

Hard to say - that's why I would break out the sniffer at this point because otherwise you'll spend a lot more time chasing all kinds of possibilities. I keep a FreeBSD box with a bunch of NIC's handy specifically for situations like this.

Thought of one other thing you can try - if you set Desktop's default gateway to vpn-server's LAN IP, it should be 100% identical to plugging Desktop directly into vpn-server (assuming you change the default gateway when you do that), and again takes Firewall out of the picture (though that's already the case if you have a proper static route on Desktop).

Someone just pointed out something to me via email that may be pertinent. You stated earlier in this thread something about a 31.1 static route. If you're adding a route as x.x.31.1/24 rather than x.x.31.0/24, it shouldn't matter since those are both the same subnets, but depending on where you entered it some devices might not be happy with not using a correct subnet address in routes. The correct subnet address is .0, assuming /24 networks.

Thanks for the tip CMB.  I'll set desktop to talk directly to VPN-server and try again.  I have a feeling that will work, since it won't be talking to the firewall.  I'm convinced there's SOMETHING going wrong in there.   I'll also try a sniffer later in the week when I get more time.  Thanks again for the input!  I appreciate any help I can get.