|
|
On Fri, 2004-04-02 at 09:49, Michael Kelly wrote: > Hello again John, > > Thank you for the detailed response to my further questions, your > descriptions of items really helped me gain a bit more understanding of > what I have to do to get openVPN setup. > > My hardware router, DLink DI-624 (rev C) has a firewall tab where I > believe I can set up the traffic routing, will take some investigation > on how to do it, but I think it can be done. > > The biggest challenge I see in my router setup is the fact that I am > forwarding UDP port 5000 to the openVPN system and all traffic between > the two VPN systems travels via that port. Now maybe it is my lack of > knowledge of firewalls, something I am going to have to work on, but I > do not understand how setting up rules to route all traffic from > 10.240.0.0/30 and 192.168.4.0/24 to the 192.168.0.93 machine will make > things any different. Does the forwarding of UDP port 5000 to > 192.168.0.93 not supercede any other rule or will the firewall look at > the traffic coming across that port and work with it according to the > rules. The route you need to set up is to route IP traffic from your LAN TO 10.240.0.0/30 and 192.168.4.0/24 back to the VPN gateway--not FROM those addresses. Yes, forwarding UDP port 5000 to your VPN gateway makes the tunnel work. The problem is getting responses from your LAN to go back through the tunnel to the other end. Other computers on the LAN don't know anything about the tunnel, all they see is a packet coming from 10.240.0.2 or 192.168.4.*. So they create a response to the packet. They don't have a rule in their routing table for those addresses, so they send the response to the default gateway (your firewall). If your firewall doesn't have a specific route for the address, it drops the packets (because these are by definition private addresses, and not routable). You need to trace the packets both ways... tcpdump or Ethereal can help you figure out what's going on, if you have trouble... There are at least two other ways of handling this, besides routing. I think routing is easiest/best for your situation. But the alternatives also work: 1. Use bridging instead of routing. (doesn't work well when you're connecting two networks, but works fine for making a remote computer appear as if it was on the LAN, so it can sometimes simplify some firewall rules). 2. Set up SNAT/DNAT on your VPN gateway to rewrite the packets to make them appear to come from the VPN gateway itself instead of the remote network. This can get very complicated, very fast... but if you really needed to use the same subnets in both LANs, might be the best way to get it to work. Of course, this would make both WINS and DNS much more complicated, too... Cheers, -- John Locke Open Source solutions for small business problems http://freelock.com ____________________________________________ Openvpn-users mailing list Openvpn-users@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/openvpn-users |