jordancollins
I have a bridge mode setup that is working well. The router has 5 internal vlan's that is routes traffic between. The current setup puts all VPN connections in the least privileged vlan. Before I start treating the server as production I would like to find a way to have different vlan assignments by clients. Here are my requirements in full:
1. Redirect all traffic in a bridge fashion as a security requirement. - Working
2. Assign IP addresses via existing DHCP infrastructure. - Working
3. Place Users in different existing subnets depending on who they are. - Not Working
4. Allow the vlan assignment to secure resources with existing firewall rules. - Working
5. If possible run all connections through on IP/Port. This is mainly to allow changes without redeploying client configs. If user1 is less privileged today then he will be tomorrow I don't want to have them connect on a new server instance.
Since I am confident that all my requirements currently are working or will work without adjustment if I can get the last #3 requirement figured out I am only really focusing on that.
Things I think might work but have not been able to experiment.
1. If possible have multiple tap interface on the same server instance. I don't think this is do able but I would like clarification. Group 1 (br500 tap500 eth0.500) Group 2 (br400 tap400 eth.400). Maybe ccd can help here?
2. Use CCD with the config option to have different server configurations? I am not sure if the config directive in a ccd is based on client config or server config? If server can you have the dev tap in more than one?
I know there are ways to simulate this type of control with client connect scripts to change firewall rules on in one subnet but I would be less desirable to resort to that solution. Any advice or direction would be greatly appreciated.
Current Config:
local x.x.x.x
port 1194
up "/etc/openvpn/up.sh br500"
down "/etc/openvpn/down.sh br500"
proto udp
dev tap0
ca /etc/openvpn/ca.crt
cert /etc/openvpn/openvpnserver.crt
key /etc/openvpn/openvpnserver.key # This file should be kept secret
dh /etc/openvpn/dh2048.pem
server-bridge
keepalive 10 120
comp-lzo
user nobody
group nobody
status openvpn-status.log
log openvpn.log
verb 3
jordancollins
up script:
#!/bin/sh
PATH=/sbin:/usr/sbin:/bin:/usr/bin
BR=$1
DEV=$2
MTU=$3
ip link set "$DEV" up promisc on mtu "$MTU"
if ! brctl show $BR | egrep -q "\W+$DEV$"; then
brctl addif $BR $DEV
fi
down script:
#!/bin/sh
PATH=/sbin:/usr/sbin:/bin:/usr/bin
BR=$1
DEV=$2
brctl delif $BR $DEV
ip link set "$DEV" down
jordancollins
I appreciate the replay but I am not sure I understand what you are pointing me at. I have read documentation and have the bridging deployment working. This includes the tap0 interface and a bridge interface containing the tap0 interface and one of the vlan interface from the router. This does place me correctly in the vlan that is bridged with the tap0 interface. In the documentation I do see the up script is different and does include information about multiple tap interfaces but for I am not sure multiple tap interfaces bridge with the same vlan interface will help accomplish my goal since you will still be placed on the same vlan that is contained in the bridge. Can the script have to groups of (br0,eth0,tap0) and (br1,eth1,tap1) and still work? If so how would it know where to place the user? I posted a modified script and server config that would resemble the dual nature I am trying to accomplish. I just don't think the server will understand this setup. If it did I would want some users to use tap0 and some to use tap1 possibly with a ccd config.
Modified Server:
local x.x.x.x
port 1194
up "/etc/openvpn/up.sh br0"
up "/etc/openvpn/up.sh br1"
down "/etc/openvpn/down.sh br0"
down "/etc/openvpn/down.sh br1"
proto udp
dev tap0
dev tap1
ca /etc/openvpn/ca.crt
cert /etc/openvpn/openvpnserver.crt
key /etc/openvpn/openvpnserver.key # This file should be kept secret
dh /etc/openvpn/dh2048.pem
server-bridge
keepalive 10 120
comp-lzo
user nobody
group nobody
status openvpn-status.log
log openvpn.log
verb 3
#!/bin/bash
# Define Bridge Interface
br0="br0"
br1="br1
# Define list of TAP interfaces to be bridged,
# for example tap="tap0 tap1 tap2".
tap0="tap0"
tap1="tap1"
# Define physical ethernet interface to be bridged
# with TAP interface(s) above.
eth0="eth0"
eth0_ip="192.168.8.4"
eth0_netmask="255.255.255.0"
eth0_broadcast="192.168.8.255"
eth1="eth0"
eth1_ip="192.168.9.4"
eth1_netmask="255.255.255.0"
eth1_broadcast="192.168.9.255"
for t in $tap0; do
openvpn --mktun --dev $t
done
brctl addbr $br0
brctl addif $br0 $eth0
brctl addbr $br1
brctl addif $br1 $eth1
for t in $tap0; do
brctl addif $br0 $t
done
for t in $tap1; do
brctl addif $br1 $t
done
for t in $tap0; do
ifconfig $t 0.0.0.0 promisc up
done
for t in $tap1; do
ifconfig $t 0.0.0.0 promisc up
done
ifconfig $eth0 0.0.0.0 promisc up
ifconfig $eth1 0.0.0.0 promisc up
ifconfig $br0 $eth0_ip netmask $eth0_netmask broadcast $eth0_broadcast
ifconfig $br1 $eth1_ip netmask $eth1_netmask broadcast $eth1_broadcast
jordancollins
I have had some time to test without success. If I try to define more then one dev tap interface in server.conf I only see one of them get added in the logs. Why does the up script mention multiple tap interface when the server.conf file only accepts one? Am I missing something? I feel like it is so close but I cannot think of anyway unless I get in an patch the code (if this even has potential) to allow different users to be connect to different server side taps with only running one server instance.
# Define list of TAP interfaces to be bridged,
# for example tap="tap0 tap1 tap2".
jordancollins
Ok so lets take the up and down scripts out of the question. I have created the tap adapters in advance. Connecting to a single tap pair (tap300 br300) works fine. I get an IP Address from the network that is bridge with the tap interface. My second pair does not seem to be associated with the server instance. The problem as I see it is that:
1. I cannot specify multiple dev interface in the server config and have both of them be mentioned in the startup of the server instance. Almost seems like to do this I need two server instances so that each one only has a single dev line. (I really want to try to keep it at a single entry point IP/Port.)
2. I am not sure how I tell different users which tap interface to be connected with unless it is just two different server instances on different listening ports. (Would like to avoid.)
Persistent Bridge Configuration:
br300 8000.52e1fd11ced5 no bond0.300
tap300
br500 8000.90e2ba2cfcc8 no bond0.500
tap500
Current Server Config (Excludes scripts and tries to have two devices defined)
local x.x.x.x
port 1194
#up "/etc/openvpn/up.sh"
#down "/etc/openvpn/down.sh"
client-config-dir /etc/openvpn/ccd
ccd-exclusive
proto udp
dev tap300
dev tap500
ca /etc/openvpn/ca.crt
cert /etc/openvpn/openvpnserver.crt
key /etc/openvpn/openvpnserver.key # This file should be kept secret
dh /etc/openvpn/dh2048.pem
server-bridge
keepalive 10 120
comp-lzo
user nobody
group nobody
status openvpn-status.log
log openvpn.log
verb 3
Server Startup Script (Only the last dev line is processed from what I see):
Mon Mar 17 08:06:45 2014 OpenVPN 2.3.2 x86_64-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [eurephia] [MH] [IPv6] built on Mar 10 2014
Mon Mar 17 08:06:45 2014 WARNING: you are using user/group/chroot/setcon without persist-tun -- this may cause restarts to fail
Mon Mar 17 08:06:45 2014 WARNING: you are using user/group/chroot/setcon without persist-key -- this may cause restarts to fail
Mon Mar 17 08:06:45 2014 NOTE: when bridging your LAN adapter with the TAP adapter, note that the new bridge adapter will often take on its own IP address that is different from what the LAN adapter was previously set to
Mon Mar 17 08:06:45 2014 Diffie-Hellman initialized with 2048 bit key
Mon Mar 17 08:06:45 2014 WARNING: file '/etc/openvpn/openvpnserver.key' is group or others accessible
Mon Mar 17 08:06:45 2014 Socket Buffers: R=[124928->131072] S=[124928->131072]
Mon Mar 17 08:06:45 2014 TUN/TAP device tap500 opened
Mon Mar 17 08:06:45 2014 TUN/TAP TX queue length set to 100
Mon Mar 17 08:06:45 2014 GID set to nobody
Mon Mar 17 08:06:45 2014 UID set to nobody
Mon Mar 17 08:06:45 2014 UDPv4 link local (bound): [AF_INET]x.x.x.x:1194
Mon Mar 17 08:06:45 2014 UDPv4 link remote: [undef]
Mon Mar 17 08:06:45 2014 MULTI: multi_init called, r=256 v=256
Mon Mar 17 08:06:45 2014 Initialization Sequence Completed
jordancollins
Thank you. I will take the second part of the answer as my answer.
I was not specifying multiples IP's in the config only multiple devices. I want to avoid multiple IP/Port which is why I don't want two instances running. I had the listening IP be an external interface called em1:1 which is not part of the bridge/tap configuration and I am not using NAT to connect to the bridge IP just a plain external interface with a routed address.
jordancollins
How do you maintain config for clients? I assume you do one of a few things. Send out new configs if things change for that client that requires them to use a different IP and or Port. Put all possible IP/Port combinations in configs that are already on the client so that have to know and choose the correct connection to make. Keep in mind that I will not have the feedom to push the config to users without them putting them in place correctly. They are also not always the most computer literate so I would have to make it as easy as reinstalling which might even be a bit much to expect. That is why I was hoping to have one golden config for the users that allowed me to make the changes without them having to know or do anything.
Ideal for me would be this:
Consultant (Guest Today) connects to x.x.x.x:1194 (em1:1) and gets placed on (br500, tap500,bond0.500) with a network range of 172.28.50.0/24 and they get treated as a guest by iptables for that subnet.
Consultant (Now Hired) connects to x.x.x.x:1194 (em1:1 same address and port) and gets place on (br300, tap300, bond0.300) with a network range of 172.26.50.0/24 and the get treated as an employee using iptables to allow them to additional resources that a consultant did not get.
All I have to do on my end is change something about their ccd config that makes this switch happen. I think it would be a great addition to the OpenVPN possiblities. I would even be willing to help write the code but the learning everything that the code is doing today would take a decent amount of time let alone any changes that would need to be made to add this fuctionality.