no way to compare when less than two revisions
Differences
This shows you the differences between two versions of the page.
— | blog:remapping_network_11_via_openvpn [2009/11/27 17:53] (current) – created - external edit 127.0.0.1 | ||
---|---|---|---|
Line 1: | Line 1: | ||
+ | ====== Remapping a network 1:1 via OpenVPN ====== | ||
+ | I had this situation where by myself and a friend wanted to share our network with each other via a VPN. However in this case we both had used the same IP address space for our internal LAN (192.168.1.0/ | ||
+ | |||
+ | To get around this problem when the VPN was created it was setup so that it would remap the entire address space of each of our networks into another range so we would not have an overlapping IP space. | ||
+ | |||
+ | In this case the network running the openvpn server will be remapped from 192.168.1.x to 192.168.10.x. | ||
+ | |||
+ | <box 80% green round> | ||
+ | If the client was running linux then we could make use of the **iroute**, **route** and **client-config-dir** openvpn commands to have the client expose their network via NAT too. With a windows client its just too hard. | ||
+ | </ | ||
+ | |||
+ | The server is going to perform the NAT so that we can also use a windows openvpn client without issue. | ||
+ | |||
+ | {{: | ||
+ | |||
+ | Inspired by http:// | ||
+ | |||
+ | Configuration file for OPENVPN Server. | ||
+ | < | ||
+ | Don't forget that you also need to configure a FIREWALL rule on your GATEWAY to forward (tcp/443) to your VPN server otherwise the client will not be able establish a tunnel. | ||
+ | </ | ||
+ | |||
+ | openvpn.conf | ||
+ | < | ||
+ | #Begin server.conf | ||
+ | #port 1194 | ||
+ | #proto udp | ||
+ | port 443 | ||
+ | proto tcp | ||
+ | dev tun | ||
+ | ca keys/ca.crt | ||
+ | cert keys/ | ||
+ | key keys/ | ||
+ | dh keys/dh.pem | ||
+ | #Make sure this is your tunnel address pool | ||
+ | server 10.0.1.0 255.255.255.0 | ||
+ | ifconfig-pool-persist ipp.txt | ||
+ | #This is the route to push to the client, add more if necessary | ||
+ | push "route 192.168.10.0 255.255.255.0" | ||
+ | keepalive 10 120 | ||
+ | cipher BF-CBC #Blowfish encryption | ||
+ | comp-lzo | ||
+ | user nobody | ||
+ | group nobody | ||
+ | persist-key | ||
+ | persist-tun | ||
+ | status openvpn-status.log | ||
+ | verb 6 | ||
+ | mute 20 | ||
+ | up ./ | ||
+ | </ | ||
+ | |||
+ | Now the magic where we NETMAP our network via the OPENVPN tunnel from 192.168.1.0/ | ||
+ | |||
+ | $1 will be the name of the virtual network interface passed by the openvpn server in our example this is passed as tun0. | ||
+ | |||
+ | openvpn.up | ||
+ | < | ||
+ | #!/bin/sh | ||
+ | echo 1 > / | ||
+ | WLAN=$1 | ||
+ | # Clear all chains | ||
+ | iptables -F | ||
+ | iptables -F -t nat | ||
+ | # Accept from the OPENVPN tunnel | ||
+ | iptables -I INPUT -i $WLAN -j ACCEPT | ||
+ | iptables -I OUTPUT -o $WLAN -j ACCEPT | ||
+ | # Remap our network 1:1 to a different IP space. Update openvpn.conf file too | ||
+ | # push "route 192.168.10.0 255.255.255.0" | ||
+ | iptables -t nat -A PREROUTING -i $WLAN -d 192.168.10.0/ | ||
+ | iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE | ||
+ | </ | ||
+ | |||
+ | If you have any other IPTABLE configuration on your box you might want to remove the two lines that CLEAR the iptables when openvpn starts up. | ||
+ | |||
+ | Or perhaps use "down ./ | ||
+ | |||
+ | ===== Server side ===== | ||
+ | |||
+ | On the openvpn server side you're routing table will look like this. The route via the tun0 interface were automatically added by OPENVPN. | ||
+ | < | ||
+ | [root@bingo openvpn]# route -n | ||
+ | Kernel IP routing table | ||
+ | Destination | ||
+ | 10.0.1.2 | ||
+ | 10.0.1.0 | ||
+ | 192.168.1.0 | ||
+ | 0.0.0.0 | ||
+ | [root@bingo openvpn]# | ||
+ | </ | ||
+ | |||
+ | A quick listing of the interfaces when the tunnel is up shows us what IP address has been used for the VPN tunnel. | ||
+ | < | ||
+ | [root@bingo openvpn]# ifconfig -a | ||
+ | eth0 Link encap: | ||
+ | inet addr: | ||
+ | inet6 addr: fe80:: | ||
+ | UP BROADCAST RUNNING MULTICAST | ||
+ | RX packets: | ||
+ | TX packets: | ||
+ | collisions: | ||
+ | RX bytes: | ||
+ | Interrupt: | ||
+ | |||
+ | lo Link encap:Local Loopback | ||
+ | inet addr: | ||
+ | inet6 addr: ::1/128 Scope:Host | ||
+ | UP LOOPBACK RUNNING | ||
+ | RX packets: | ||
+ | TX packets: | ||
+ | collisions: | ||
+ | RX bytes: | ||
+ | |||
+ | tun0 Link encap: | ||
+ | inet addr: | ||
+ | UP POINTOPOINT RUNNING NOARP MULTICAST | ||
+ | RX packets: | ||
+ | TX packets: | ||
+ | collisions: | ||
+ | RX bytes: | ||
+ | </ | ||
+ | |||
+ | ===== Client Side ===== | ||
+ | |||
+ | The client side configuration is simple enough. | ||
+ | |||
+ | * http:// | ||
+ | |||
+ | Combine client keys into a pkcs12 file | ||
+ | < | ||
+ | openssl pkcs12 -export -in client.crt -inkey client.key -certfile ca.crt -out dbzoo-cert.p12 | ||
+ | </ | ||
+ | |||
+ | openvpn.conf | ||
+ | < | ||
+ | ######################################## | ||
+ | # OpenVPN Client Configuration | ||
+ | client | ||
+ | dev tun | ||
+ | proto tcp | ||
+ | remote remote.site.com 443 | ||
+ | nobind | ||
+ | persist-tun | ||
+ | persist-key | ||
+ | keepalive 60 360 | ||
+ | pkcs12 dbzoo-cert.p12 | ||
+ | comp-lzo | ||
+ | verb 4 | ||
+ | mute 5 | ||
+ | </ | ||
+ | |||
+ | Once the tunnel has been established your client side routing table will look like this. | ||
+ | The 192.168.10.0 network route is a result of the **push** from the openvpn server. | ||
+ | < | ||
+ | [root@vpnout root]# route -n | ||
+ | Kernel IP routing table | ||
+ | Destination | ||
+ | 10.0.1.5 | ||
+ | 10.0.1.1 | ||
+ | 192.168.10.0 | ||
+ | 192.168.1.0 | ||
+ | 0.0.0.0 | ||
+ | </ | ||
+ | |||
+ | Client side network interface configuration | ||
+ | < | ||
+ | # ifconfig -a | ||
+ | eth0 Link encap: | ||
+ | inet addr: | ||
+ | UP BROADCAST RUNNING MULTICAST | ||
+ | RX packets: | ||
+ | TX packets: | ||
+ | collisions: | ||
+ | RX bytes: | ||
+ | Interrupt: | ||
+ | |||
+ | lo Link encap:Local Loopback | ||
+ | inet addr: | ||
+ | UP LOOPBACK RUNNING | ||
+ | RX packets:62 errors:0 dropped:0 overruns:0 frame:0 | ||
+ | TX packets:62 errors:0 dropped:0 overruns:0 carrier:0 | ||
+ | collisions: | ||
+ | RX bytes:4564 (4.4 Kb) TX bytes:4564 (4.4 Kb) | ||
+ | |||
+ | tun0 Link encap: | ||
+ | inet addr: | ||
+ | UP POINTOPOINT RUNNING NOARP MULTICAST | ||
+ | RX packets: | ||
+ | TX packets: | ||
+ | collisions: | ||
+ | RX bytes: | ||
+ | </ | ||
+ | |||
+ | ===== Traceroute ===== | ||
+ | |||
+ | Performing a traceroute from the CLIENT side out to a box on the SERVER side which has an IP of 192.168.1.20 but via the NAT/VPN tunnel will be 192.168.10.20. | ||
+ | |||
+ | < | ||
+ | [root@vpnout root]# traceroute 192.168.10.20 | ||
+ | traceroute to 192.168.10.20 (192.168.10.20), | ||
+ | | ||
+ | | ||
+ | [root@vpnout root]# | ||
+ | </ | ||
+ | |||
+ | We can see the 10.0.1.1 is the IP address of the Point-to-Point VPN server endpoint (tun0) when the VPN server route' | ||
+ | |||
+ | {{tag> |