Click on the top button to “open code in new window” to see it in a nice format

OPENVPN – 3 – BRIDGED VPN – STATIC KEY – CLIENT 2 SITE
#######################################################
#######################################################

SIMPLEST BRIDGED OPENVPN CONFIG - WITH STATIC KEY
###################################################
###################################################
 
CITATION: http://wiki.openwrt.org/doc/howto/vpn.server.openvpn.tap
 
First generate a key.
Then write the openvpn bridge script (start it, and might as well always have it start once per boot)
Then write the openvpn server config and start the openvpn server
Then copy the key to the client and repeat
Then start the server openvpn
Then start the client openvpn
Both should start no problem although we still cant access anything, you must now add an ip address to the client in the same subnet as the server - make sure its unused
 
NOTE @ THE FIREWALL IN THE NETWORK WHERE THE SERVER (THE ONE BEING THE OPENVPN SERVER) IS AT THERE IS A UDP PORT FORWARD OF PORT 50006 FROM FIREWALL FACING INTERNET TO PORT 50006 UDP ON SERVER (THE ONE BEING THE OPENVPN SERVER)
THE ONLY FIREWALL CONFIG I NEEDED AT THE CLIENT WAS A PORTFORWARD TO ACCESS SSH ON THE CLIENT, BUT THATS OPTIONAL THATS JUST SO I HAVE ACCESS TO THE LINUX SHELL FROM ANYWHERE, THE MAIN ONE FOR THIS IS ESSENTIALLY ALLOWING OUTBOUND TRAFFIC OUT AT THE CLIENT NETWORK - THATS TYPICAL FIREWALL DEFAULTS THOUGH ALL ALL OUTBOUND TRAFFIC
 
 
INSTALLATION
#################
 
ON SERVER:
apt-get install bridge-utils
apt-get install openvpn
apt-get install openssl
 
ON CLIENT:
apt-get install openvpn
apt-get install openssl
 
 
GENERATE KEY
################
 
openvpn --genkey --secret /etc/openvpn/openvpn.key
 
TX KEY TO CLIENT:
 
cat openvpn.key | ssh -p 50005 www.client.com "cat - > /etc/openvpn/openvpn.keykey"
 
 
SIMPLE OPENVPN BRIDGE
########################
 
touch /etc/openvpn/openvpnbridge.sh; chmod +x /etc/openvpn/openvpnbridge.sh
 
#!/bin/bash
# /etc/openvpn/openvpnbridge.sh
# Taken from http://openvpn.net/bridge.html
insmod tun
br="br0"
tap="tap0"
for t in $tap; do
    openvpn --mktun --dev $t
done
for t in $tap; do
    brctl addif $br $t
done
for t in $tap; do
    ifconfig $t 0.0.0.0 promisc up
done
 
 
OTHER BRIDGE START AND STOP FROM PREVIOUS EXAMPLE WORK, BUT ABOVE LOOKS MORE APPEALING
#########################################################################################
 
Why this one isnt as good?
 
This bridge start stop, enabled the bridge and tap and it switches the ip of eth0 to the bridge/tap where as on the above one it stays on eth... This can happen because they are the same leg, so it doesnt matter especially since they are all promiscous. And the above method doesnt need a stop.
 
 
OTHER START BRIDGE
======================
 
At the very bottom/end in OTHER/EXTRA notes section
 
 
OTHER STOP BRIDGE
====================
 
At the very bottom/end in OTHER/EXTRA notes section
 
 
SIMPLE SERVER /etc/openvpn/openvpn.conf
#########################################
 
port 50006
proto udp
dev tap0
keepalive 10 120
;comp-lzo
;persist-key
;persist-tun
status openvpn-status.log
verb 3
secret /etc/openvpn/openvpn.key
 
 
SIMPLE CLIENT /etc/openvpn/openvpn.conf
###########################################
 
dev tap0
proto udp
remote www.server.com 50006
resolv-retry infinite
nobind
;persist-key
;persist-tun
# Wireless networks often produce a lot
# of duplicate packets.  Set this flag
# to silence duplicate packet warnings.
mute-replay-warnings
secret /etc/openvpn/openvpn.key
;comp-lzo
verb 3
 
 
START ON SERVER
###################
 
service openvpn start
 
It start no problem if you followed above methods
 
START ON CLIENT
##################
 
service openvpn start
 
EXTRA NEEDED THINGS - GET AN IP TO THE CLIENT IN THE SUBNET
==============================================================
 
Both openvpns at the server and client should start no problem although we still cant access anything, you must now add an ip address to the client in the same subnet as the server - make sure its unused
 
ifconfig tap0 172.18.10.160 netmask 255.255.0.0 broadcast 172.18.255.255
 
 
OTHER EXTRA NOTES SECTION
##################################
 
 
IMPORTANT SIDE NOTE:
* NOTE IT WORKED FOR ME AND I USED THE BRIDGE FROM BELOW BECAUSE I WAS TOO LAZY TO SWITCH OVER TO THE BETTER/SIMPLER BRIDGE SCRIPT ABOVE. I DIDNT HAVE TO USE ANY FIREWALL IPTABLES (BECAUSE I ALREADY HAVE ALL OPEN NETWORK :-) )
 
WHAT FILES DID I HAVE IN THE END AT THE SERVER
================================================
 
If you followed the instructions with the bridge config from above you should have:
/etc/openvpn/openvpnbridge.sh <- even though I didnt test this yet, I know this works as the site is credible and users post great things on the comments (what site? the one in citation from above)
/etc/openvpn/openvpn.key
/etc/openvpn/openvpn.conf
&nbsp;
If you followed the same instructions but using the bridge below (in OTHER EXTRA NOTES section) instead, which is actually what I ended up doing during the writing of this article:
/etc/openvpn/openvpnbridge.sh
/etc/openvpn/openvpn.key
/etc/openvpn/openvpn.conf
&nbsp;
&nbsp;
WHAT FILES DID I HAVE IN THE END AT THE SERVER
================================================
&nbsp;
/etc/openvpn/openvpn.key <-- this is the same as the file @ the server
/etc/openvpn/openvpn.conf
&nbsp;
&nbsp;
HOW TO START SERVER WITH BOOT
=================================
&nbsp;
#!/bin/sh
#/etc/init.d/S46openvpn <-- make this file with this in it
/etc/openvpn/openvpnbridge.sh
openvpn /etc/openvpn/openvpn.conf &
&nbsp;
OR if S##openvpn already exists then find the append_param() function and add into it:
/etc/openvpn/openvpnbridge.sh
&nbsp;
&nbsp;
&nbsp;
ANOTHER WAY TO START CONFIGS
================================
&nbsp;
Name them other names and launch like this
openvpn [config filename here]
&nbsp;
&nbsp;
ANOTHER BRIDGE AND SOME OTHER THINGS TO CONSIDER
====================================================
&nbsp;
cd /etc/openvpn
touch start.sh; chmod +x start.sh;
touch stop.sh; chmod +x stop.sh;
&nbsp;
&nbsp;
MY /etc/openvpn/start.sh
---------------------------
&nbsp;
#!/bin/bash
br="br0" &nbsp; # Define Bridge Interface
tap="tap0" # Define list of TAP example tap="tap0 tap1 tap2"
eth="eth0"
# * CHANGE FROM HERE DOWN
eth_ip="172.18.10.21"
eth_netmask="255.255.0.0"
eth_broadcast="172.18.255.255"
eth_gw="172.18.10.2"
# * CHANGE FROM HERE UP AND NOTHING BELOW
for t in $tap; do
&nbsp; &nbsp; openvpn --mktun --dev $t
done
brctl addbr $br
brctl addif $br $eth
for t in $tap; do
&nbsp; &nbsp; brctl addif $br $t
done
for t in $tap; do
&nbsp; &nbsp; ifconfig $t 0.0.0.0 promisc up
done
ifconfig $eth 0.0.0.0 promisc up
ifconfig $br $eth_ip netmask $eth_netmask broadcast $eth_broadcast
route add default gw $eth_gw $br
echo "* Bridge STARTED `date`" >> /var/log/syslog
&nbsp;
&nbsp;
MY /etc/openvpn/stop.sh
-----------------------------
&nbsp;
#!/bin/bash
br="br0"
tap="tap0"
# * CHANGE FROM HERE DOWN
eth="eth0"
eth_ip="172.18.10.21"
eth_netmask="255.255.0.0"
eth_broadcast="172.18.255.255"
eth_gw="172.18.10.2"
# * CHANGE FROM HERE UP AND NOTHING BELOW
ifconfig $br down
brctl delbr $br
for t in $tap; do
&nbsp; &nbsp; openvpn --rmtun --dev $t
done
ifconfig eth0 -promisc
ifconfig $eth $eth_ip netmask $eth_netmask broadcast $eth_broadcast
route add default gw $eth_gw $eth
echo "* Bridge STOPPED `date`" >> /var/log/syslog
&nbsp;
&nbsp;
TEST THE BRIDGE
-----------------------
&nbsp;
The bridge should be able to get started and start a ping, you might get disconnected for a second
&nbsp;
./start.sh; ping 8.8.8.8
./stop.sh; ping 8.8.8.8
&nbsp;
You should be able to do the above all day long, note its okay if there is a delay after you start the bridge with start.sh and the pings comeing through, sometimes it took me 10 seconds, and sometimes its instant
&nbsp;
Note when you start the bridge on the server your ifconfig should look like this:
./start.sh
ifconfig
&nbsp;
And when you stop the bridge on the server your ifconfig should look like this:
./stop.sh
ifconfig
&nbsp;
OUTPUT:
&nbsp;
br0 &nbsp; &nbsp; &nbsp; Link encap:Ethernet &nbsp;HWaddr 00:50:56:aa:cc:44
&nbsp;&nbsp;inet addr:172.18.10.21 &nbsp;Bcast:172.18.10.255 &nbsp;Mask:255.255.255.0
&nbsp;&nbsp;inet6 addr: fe80::250:56ff:feaa:cc44/64 Scope:Link
&nbsp;&nbsp;UP BROADCAST RUNNING MULTICAST &nbsp;MTU:1500 &nbsp;Metric:1
&nbsp;&nbsp;RX packets:226268724 errors:0 dropped:40 overruns:0 frame:0
&nbsp;&nbsp;TX packets:72419607 errors:0 dropped:0 overruns:0 carrier:0
&nbsp;&nbsp;collisions:0 txqueuelen:0
&nbsp;&nbsp;RX bytes:128122219579 (119.3 GiB) &nbsp;TX bytes:38122071147 (35.5 GiB)
&nbsp;
eth0 &nbsp; &nbsp; &nbsp;Link encap:Ethernet &nbsp;HWaddr 00:50:56:aa:cc:44
&nbsp;&nbsp;inet6 addr: fe80::250:56ff:feaa:cc44/64 Scope:Link
&nbsp;&nbsp;UP BROADCAST RUNNING PROMISC MULTICAST &nbsp;MTU:1500 &nbsp;Metric:1
&nbsp;&nbsp;RX packets:4785785867 errors:0 dropped:624 overruns:0 frame:0
&nbsp;&nbsp;TX packets:911487819 errors:0 dropped:0 overruns:0 carrier:0
&nbsp;&nbsp;collisions:0 txqueuelen:1000
&nbsp;&nbsp;RX bytes:3251376854369 (2.9 TiB) &nbsp;TX bytes:967950374803 (901.4 GiB)
&nbsp;
lo &nbsp; &nbsp; &nbsp; &nbsp;Link encap:Local Loopback
&nbsp;&nbsp;inet addr:127.0.0.1 &nbsp;Mask:255.0.0.0
&nbsp;&nbsp;inet6 addr: ::1/128 Scope:Host
&nbsp;&nbsp;UP LOOPBACK RUNNING &nbsp;MTU:16436 &nbsp;Metric:1
&nbsp;&nbsp;RX packets:6 errors:0 dropped:0 overruns:0 frame:0
&nbsp;&nbsp;TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
&nbsp;&nbsp;collisions:0 txqueuelen:0
&nbsp;&nbsp;RX bytes:408 (408.0 B) &nbsp;TX bytes:408 (408.0 B)
&nbsp;
tap0 &nbsp; &nbsp; &nbsp;Link encap:Ethernet &nbsp;HWaddr a6:0a:c1:be:20:e5
&nbsp;&nbsp;inet6 addr: fe80::a40a:c1ff:febe:20e5/64 Scope:Link
&nbsp;&nbsp;UP BROADCAST RUNNING PROMISC MULTICAST &nbsp;MTU:1500 &nbsp;Metric:1
&nbsp;&nbsp;RX packets:14557 errors:0 dropped:0 overruns:0 frame:0
&nbsp;&nbsp;TX packets:69436125 errors:0 dropped:140650466 overruns:0 carrier:0
&nbsp;&nbsp;collisions:0 txqueuelen:100
&nbsp;&nbsp;RX bytes:1047354 (1022.8 KiB) &nbsp;TX bytes:32999262636 (30.7 GiB)
&nbsp;
Before continuing start the bridge
./start.sh
ifconfig
&nbsp;
OUTPUT:
&nbsp;
eth0 &nbsp; &nbsp; &nbsp;Link encap:Ethernet &nbsp;HWaddr 00:50:56:aa:cc:44
&nbsp;&nbsp;inet addr:172.18.10.21 &nbsp;Bcast:172.18.10.255 &nbsp;Mask:255.255.255.0
&nbsp;&nbsp;inet6 addr: fe80::250:56ff:feaa:cc44/64 Scope:Link
&nbsp;&nbsp;UP BROADCAST RUNNING MULTICAST &nbsp;MTU:1500 &nbsp;Metric:1
&nbsp;&nbsp;RX packets:4786738468 errors:0 dropped:624 overruns:0 frame:0
&nbsp;&nbsp;TX packets:911566372 errors:0 dropped:0 overruns:0 carrier:0
&nbsp;&nbsp;collisions:0 txqueuelen:1000
&nbsp;&nbsp;RX bytes:3251996200507 (2.9 TiB) &nbsp;TX bytes:967991077500 (901.5 GiB)
&nbsp;
lo &nbsp; &nbsp; &nbsp; &nbsp;Link encap:Local Loopback
&nbsp;&nbsp;inet addr:127.0.0.1 &nbsp;Mask:255.0.0.0
&nbsp;&nbsp;inet6 addr: ::1/128 Scope:Host
&nbsp;&nbsp;UP LOOPBACK RUNNING &nbsp;MTU:16436 &nbsp;Metric:1
&nbsp;&nbsp;RX packets:6 errors:0 dropped:0 overruns:0 frame:0
&nbsp;&nbsp;TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
&nbsp;&nbsp;collisions:0 txqueuelen:0
&nbsp;&nbsp;RX bytes:408 (408.0 B) &nbsp;TX bytes:408 (408.0 B)
&nbsp;
OTHER CONFIGS:
==============
&nbsp;
1. If your server is on an ESXi Server make sure to allow that NIC to have Promiscous mode enabled, for more on that look below
&nbsp;
If you are setting up the server as a virtual machine, in a ESXi server there is a nasty little gotcha on the network card settings that needs to be changed. The setting is in the VMWare ESX Management Client, then in Networking/Properties/Choose The VLAN your server is using/Edit/Security/Promiscous Mode/Check the box and choose Enable. Otherwise the bridge wont work because the ESX is preventing it from going into promiscous mode.
&nbsp;
vSphere 5.0 -> Home -> Inventory -> Hosts and Clusters -> select HOST 172.18.10.200 -> Configuration Tab -> Networking -> select Properties for vSwitch that has your machine VSWITCH2 PHYSICAL ADDRESS vmnic4 -> From List select vSwitch and hit edit (((notice there are 2 enteries a vSwitch - which has a summary in the tree of "120 Ports" and a Network "Core Lab Network", editing the vSwitch affects the Network called "Core Lab Network" - which has the summary in the tree of "Virtual Machine Port Group"))) -> Security Tab -> Promiscous Mode -> Change to Accept from Reject (((There shouldnt be a checkbox you have to check to change this, unless you selected the Network/"Virtual Machine Port Group" instead of the correct selection which is the vSwitch)))
&nbsp;
&nbsp;
2. If you have firewall rules setup with IPTABLES other then allow all then allow the correct packets to passthrough
Note with no iptables rules, or just the default Allow All, everything should work:
&nbsp;
&nbsp;
iptables -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
&nbsp;
iptables -L
Chain INPUT (policy ACCEPT)
target &nbsp; &nbsp; prot opt source &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; destination
&nbsp;
Chain FORWARD (policy ACCEPT)
target &nbsp; &nbsp; prot opt source &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; destination
&nbsp;
Chain OUTPUT (policy ACCEPT)
target &nbsp; &nbsp; prot opt source &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; destination
&nbsp;
&nbsp;
But if you have more vigourous security make sure you run these commands to allow br0 and tap0 to communicate:
&nbsp;
iptables -A INPUT -i tap0 -j ACCEPT
iptables -A INPUT -i br0 -j ACCEPT
iptables -A FORWARD -i br0 -j ACCEPT
&nbsp;
I dont think applies here but maybe this might help, so your troubleshooting you can put this in:
&nbsp;
echo 1 > /proc/sys/net/ipv4/ip_forward
&nbsp;
For me it worked with that on "echo 1" and off "echo 0"

 

Leave a Reply

Your email address will not be published. Required fields are marked *