Allow VPN clients to access multiple VLANs on server

ctrlaltdel

Here is my setup:

Corporate network---->(eth0) My CentOS 6.4 Server with OpenVPN (eth1)------> eth1.2 VLAN / eth1.3 VLAN

The subnet on eth1.2 is 10.7.0.0/24 and eth1.3 is 10.7.1.0/24. I would like for the clients connecting from the corporate network to be able to directly access all the machines on both VLANs. Is this possible without getting rid of the VLANs and just running eth1 as 10.7.0.0/16?

One caveat: I can't run more than one OpenVPN instance, because the only ports that are usable are TCP 22 and 443. Right now I have an OpenVPN server running on 443 and passing through https traffic to apache. I can set the server to bridge to one interface or the other, but not both. I have tried setting it up with routing but haven't had any success.

Thanks!

ctrlaltdel

Bump with my current config. This lets me get to the 1.2 VLAN only. I need to get to both.

port 443
port-share 172.18.150.25 4545
proto tcp
dev tap0
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/server.crt
key /etc/openvpn/keys/server.key  # This file should be kept private
dh /etc/openvpn/keys/dh2048.pem
ifconfig-pool-persist ipp.txt
server-bridge 10.7.0.25 255.255.255.0 10.7.0.200 10.7.0.250
keepalive 10 120
comp-lzo
user nobody
group nobody
persist-key
persist-tun
status openvpn-status.log
verb 3

janjust

if you want to access two different subnets then some form of routing is required. A bridged setup will give you access to one subnet only, and will not help you here.

Try a 'dev tun' based setup with masquerading on the server and the following push routes:

push "route 10.7.0.0 255.255.255.0"
push "route 10.7.1.0 255.255.255.0"

ctrlaltdel

Server config:

port 443
port-share $corporate_ip 4545
proto tcp
dev tun
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/server.crt
key /etc/openvpn/keys/server.key 
dh /etc/openvpn/keys/dh2048.pem
server 10.7.200.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route 10.7.0.0 255.255.255.0"
push "route 10.7.1.0 255.255.255.0"
keepalive 10 120
comp-lzo
user nobody
group nobody
persist-key
persist-tun
status openvpn-status.log
verb 3

Client config:

client
dev tun
proto tcp
remote $corporate_ip 443
resolv-retry infinite
nobind
persist-key
persist-tun

ca "C:\\Program Files (x86)\\OpenVPN\\keys\\ca.crt"
cert "C:\\Program Files (x86)\\OpenVPN\\keys\\client1.crt"
key "C:\\Program Files (x86)\\OpenVPN\\keys\\client1.key"
ns-cert-type server

comp-lzo
verb 3

Relevant Iptables entries on server:

-A POSTROUTING -s 10.7.1.0/24 -o eth0 -j MASQUERADE
-A POSTROUTING -s 10.7.0.0/24 -o eth0 -j MASQUERADE
-A POSTROUTING -o tun0 -j MASQUERADE

-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -s 10.7.1.0/24 -i eth1.3 -o tun0 -m conntrack --ctstate NEW -j ACCEPT
-A FORWARD -s 10.7.0.0/24 -i eth1.2 -o tun0 -m conntrack --ctstate NEW -j ACCEPT
-A FORWARD -s 10.7.200.0/24 -d 10.7.1.0/24 -i tun0 -o eth1.3 -m conntrack --ctstate NEW -j ACCEPT
-A FORWARD -s 10.7.200.0/24 -d 10.7.0.0/24 -i tun0 -o eth1.2 -m conntrack --ctstate NEW -j ACCEPT
-A FORWARD -s 10.7.200.0/24 -i tun0 -o eth0 -m conntrack --ctstate NEW -j ACCEPT

I still get "request timed out" when trying to ping 10.7.0.7 from the client. What's missing?

janjust

your masquerading rules are not masking all VPN traffic; try

iptables -t nat -O POSTROUTING -o eth0 -s 10.7.200.0/24 -j MASQUERADE

otherwise your LAN clients will receive traffic from a host 10.7.200.X and will now know where to send traffic back to.

ctrlaltdel

I have added that masquerading rule and still can't ping 10.7.0.7

I watched the iptables -L -v output while pinging and noticed that the packets passed through this FORWARD rule:

-A FORWARD -s 10.7.200.0/24 -d 10.7.0.0/24 -i tun0 -o eth1.2 -m conntrack --ctstate NEW -j ACCEPT

But the packet count did not increase in any other forward rule, or any masquerading rule. I get "request timed out" from the ping command. Somehow, the packets are being forwarded but aren't coming back through.

janjust

is ip forwarding enabled on the server?

cat /proc/sys/net/ipv4/ip_forward

ctrlaltdel

Yes it is set to 1

janjust

For debugging purposes, clear out the FORWARDing rules and install something simple like

iptables -I FORWARD -i tun+ -j ACCEPT
iptables -I FORWARD -o tun+ -j ACCEPT

does it work in that case? if so, then it's an iptables issue; if it does not work even with these forwarding rules then it's something else (and possibly openvpn related).