|
|
Karthik S <talk2sk@xxxxxxxxxxx> said: > Hi, > > Firstly this is a great package to use quickly, I was able > to compile and install and get a tunnel working in 30 > mins (after wading through the options etc etc). In > order to test the package and prove to myself that I > can use this for the final target environment of allowing > VPN over the internet for our intranet access etc, I > started a small experiment.. > > > I have a network with 192.168.1.0/24 as the local > ethernet. The linux server is 192.168.1.1 and has eth0 > as the local ethernet interface. The linux server is > connected to an adsl router by the interface eth1, and > ip address 192.168.0.2, the router is 192.168.0.1. > > On linux, I have shorewall implementing a very restricted > firewall and masquerading eth0 over eth1. i.e. allowing > http access for the local net through the router. > > Firstly what I did was to try and implement a tunnel > between the linux server and my XP machine (gotta use > it for dev :-( ). This went off smoothly, I had the tunnel > between my xp machine and the linux server over the > ethernet as 192.168.2.2 (xp) <-> 192.168.2.1 (linux). I > was able to ping both end points and there were no > problems. > > The problems occur when I try to masq. tun0 over eth1. > Apparently all the configuration is okay (maybe), but the > connections never succeed (there is no response). > Falling back to getting the basics working, I have tried > ping to a static ip address (say 202.54.xxx.xxx) this > works over the ethernet and masq. But when I set the > route on the xp machine to use the tunnel interface the > packets seemed to go into a black hole. > > I then started tracing the packets using tcpdump. The > packets were coming through tun0 on the linux machine > fine. The packets (icmp) were being accepted by > shorewall fine (ACCEPT:info). They were being forwarded > onto the eth1 interface too. But at this point I found > some strange messages. > > arp who-has 192.168.2.2 tell 192.168.0.1 > > (I have verified that when browsing through the > ethernet this is a common occurrence followed by an > arp-reply) > > But in this case there was no arp reply. My guess is that > the icmp reply is coming back to the router but it doesnt > know where to send it ?? > > How can I solve this (I am sure its a very small trick). > > ADDITIONAL NOTE: > > I have reason to believe this has got more to do with MASQUERADING since > the outgoing address from the linux box is 192.168.2.2 instead of > masquerading as 192.168.0.1 as is being done on eth0 ?? If you are masquerading tun0 over eth1, you want something like this: # Keep state of connections from local machine and private subnets iptables -A OUTPUT -m state --state NEW -o eth0 -j ACCEPT iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A FORWARD -m state --state NEW -o eth0 -j ACCEPT iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT # Masquerade local subnets iptables -t nat -A POSTROUTING -s $PRIVATE1 -o eth0 -j MASQUERADE iptables -t nat -A POSTROUTING -s $PRIVATE2 -o eth0 -j MASQUERADE In your case substitute eth1 for eth0 and set $PRIVATE1 and/or $PRIVATE2 to the private addresses of clients on the other end of tun0. What you will essentially be doing is providing a first hop from client to server via OpenVPN for such things as web traffic, which will then be masqueraded out to the internet using the server's public IP address (i.e. eth1). This lets you lock down the client so that all traffic goes through the VPN, even internet-bound traffic such as web browsing. James ____________________________________________ Openvpn-users mailing list Openvpn-users@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/openvpn-users |