Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I am having a difficult time properly configuring an ethernet bridge using OpenVPN 2.0.9 install on CentOS 5 ( VPN server ). The goal that I am trying to complete is to connect a VM ( instance running on the same CentOS machine ) acting as a Microsoft Business Contact Manager server. I would then like this "BCM server" to serve Windows XP clients on 192.168.1.0/24 network as well as clients connecting from VPN ( 10.8.0.0/24 ). The setup as it is now was based off a known working configuration. The problem with the working configuration was that it would allow to the client to connect and access everything running on the VPN server ( SVN, Samba, VM Server ) but not any computers on the 192.168.1.0/24 network.

I must disclose that the VPN server is behind a router/firewall. Ports are being forwarded correctly ( again, clients were able to connect to the VPN server with no problem. netcat confirms the udp port is open as well ).

current ifconfig output

br0       Link encap:Ethernet  HWaddr 00:21:5E:4D:3A:C2
          inet addr:192.168.1.169  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::221:5eff:fe4d:3ac2/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:846890 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3072351 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:42686842 (40.7 MiB)  TX bytes:4540654180 (4.2 GiB)

eth0      Link encap:Ethernet  HWaddr 00:21:5E:4D:3A:C2
          UP BROADCAST RUNNING SLAVE MULTICAST  MTU:1500  Metric:1
          RX packets:882641 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1781383 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:82342803 (78.5 MiB)  TX bytes:2614727660 (2.4 GiB)
          Interrupt:169

eth1      Link encap:Ethernet  HWaddr 00:21:5E:4D:3A:C3
          UP BROADCAST RUNNING SLAVE MULTICAST  MTU:1500  Metric:1
          RX packets:650 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1347223 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:67403 (65.8 KiB)  TX bytes:1959529142 (1.8 GiB)
          Interrupt:233

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:17452058 errors:0 dropped:0 overruns:0 frame:0
          TX packets:17452058 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:94020256229 (87.5 GiB)  TX bytes:94020256229 (87.5 GiB)

tap0      Link encap:Ethernet  HWaddr DE:18:C6:D7:01:63
          inet6 addr: fe80::dc18:c6ff:fed7:163/64 Scope:Link
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3086 errors:0 dropped:166 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:0 (0.0 b)  TX bytes:315099 (307.7 KiB)

vmnet1    Link encap:Ethernet  HWaddr 00:50:56:C0:00:01
          inet addr:192.168.177.1  Bcast:192.168.177.255  Mask:255.255.255.0
          inet6 addr: fe80::250:56ff:fec0:1/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4224 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

vmnet8    Link encap:Ethernet  HWaddr 00:50:56:C0:00:08
          inet addr:192.168.55.1  Bcast:192.168.55.255  Mask:255.255.255.0
          inet6 addr: fe80::250:56ff:fec0:8/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4226 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

current route table

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.55.0     *               255.255.255.0   U     0      0        0    vmnet8
192.168.177.0   *               255.255.255.0   U     0      0        0    vmnet1
192.168.1.0      *               255.255.255.0   U     0      0        0    br0

current iptables output

Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

server_known_working.conf

local banshee
port 1194
proto udp
dev tap0
ca ca.crt
cert banshee_server.crt
key banshee_server.key
dh dh1024.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route 192.168.1.0 255.255.255.0"
client-to-client
keepalive 10 120
tls-auth ta.key 0
user nobody
group nobody
persist-key
persist-tun
status openvpn-status.log
verb 4

The following is the current CentOS server config file.

server_ethernet_bridged.conf ( current )

local 192.168.1.169
port 1194
proto udp
dev tap0
ca ca.crt
cert server.crt
key server.key
dh dh1024.pem
ifconfig-pool-persist ipp.txt
server-bridge 192.168.1.169 255.255.255.0 192.168.1.200 192.168.1.210
push "route 192.168.1.0 255.255.255.0 192.168.1.1"
client-to-client
keepalive 10 120
tls-auth ta.key 0
user nobody
group nobody
persist-key
persist-tun
status openvpn-status.log
verb 6

The following is one of the client's config file that was used with the known working configuration.

client.opvn

client
dev tap
proto udp
remote XXX.XXX.XXX 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca client.crt
cert client.crt
key client.key
tls-auth client.key 1
verb 3

I have tried the HOWTO provided by OpenVPN as well as others

http://www.thebakershome.net/openvpn%5Ftutorial?page=1

with no success.

Any help or suggestions would be appreciated.

share|improve this question
    
What's with the bridging? I don't see any reason to be bridging anything here. –  womble Nov 23 '09 at 13:09
    
Thanks for the reply. My understanding was that the bridged interface was needed to allow clients connecting from the VPN to be on the same 192.168.1.0/24 network behind the VPN server. –  Hooplad Nov 23 '09 at 17:39
add comment

3 Answers

Unless you really need the vpn clients to appear to be on the same layer 2 subnet, I would avoid bridging.

if 192.168.1.0/24 is your current internal subnet, configure openvpn to assign 192.168.2.0/24 or so to VPN clients.

then you need to do one of two things:

  1. configure the openvpn server to NAT vpn addresses
  2. configure your router to add a static route for 192.168.2.0/24 through your openvpn server

1 can be as simple as

iptables -t nat -A POSTROUTING -s 192.168.2.0/24 -o eth0 -j MASQUERADE

This will work as long as you don't care that all vpn clients will show up as the same address on the server. this way also makes it impossible for a connection to be made TO a vpn client from the lan.

2 is not really that complicated, in IOS land it would be just

ip route 192.168.2.0 255.255.255.0 a.b.c.d

where a.b.c.d is the internal ip address of your openvpn server. A static route can even be added on a cheap linksys router.

share|improve this answer
add comment

I am have a similar setup where I have:

Internal LAN <--> OpenVPN Server (behind our enterprise firewall) <--> OpenVPN Client (which also acts as a FW/DHCP server) <--> Subnet behind it

Basically we have the OpenVPN server internally act as the server and the OpenVPN client connects to it using tun interfaces (we use routing). Through that tunnel, I then use ipforward rules and route rules to allow all traffic from the internal LAN to flow through the VPN tunnel to the external subnet that lies behind the OpenVPN client. It's normal setup of OpenVPN, plus just adding the correct routes and also adding the ccd and iroute commands as well in the server.conf to give you access to that subnet behind the OpenVPN client. Essentially with this setup you just extend your local LAN to an off site location with an encrypted tunnel using routed interfaces instead of bridging. Hope that helps some, I never have messed with the bridging aspect of it.

share|improve this answer
add comment

bridging can be made to work in this case, although strictly speaking it's not necessary. Try removing the lines

push "route 192.168.1.0 255.255.255.0 192.168.1.1"
client-to-client

from the server config , as they should not be required in bridging mode. After a client connects, try pinging the VPN server IP and the default LAN IP.

Also, post the output of

brctl show

HTH,

JJK

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.