Limit LAN Access in Bridged Setup
Posted: Wed Sep 07, 2011 12:26 pm
I have a problem in my current bridged setup with OpenVPN. Here’s some background.
I bridged my adapter with TAP on server and configured OpenVPN for bridging. Needed it for broadcast. Unfortunately, we need to run some software which is able to detect virtual adapters and apparently refuses to broadcast on them. This problem causes client not to receive needed packets. My overkill solution was to bridge client’s adapter with his TAP too. This made everything work instantly. But..., well, just look at this beautiful ASCII map below:
First side effect. As you can see, we are both behind routers with DHCP servers running on them. This causes our routers’ DHCP to lease IPs to “alien” PCs upon connect. My router leases IPs for PCs from his LAN and vice versa. My solution was to use iptables to block PCs from his LAN by their MACs. This worked, but it’s only a half-solution for our entire problem because of second side effect below.
Second, with our setup we are obviously able to see entire LANs of each other. We can ping routers of each other, see all Windows shares of every PC in LANs, etc. Even though this is probably what is usually desired when you are bridging, in our case it’s an undesirable side-effect: we want to choose which PCs would be visible on both sides of VPN. Let’s say, I want only my 100.100.100.100 to be visible (hide 100.100.100.101) and he wants only his 100.100.100.150 to be visible.
So, my goal: Using bridged setup on both sides, allow our two and only our two PCs to communicate over VPN.
Any ideas how to accomplish this?
P.s.
Server and client run Windows 7. Routers run DD-WRT.
Configs attached below:
server.ovpn:
client.ovpn:
I bridged my adapter with TAP on server and configured OpenVPN for bridging. Needed it for broadcast. Unfortunately, we need to run some software which is able to detect virtual adapters and apparently refuses to broadcast on them. This problem causes client not to receive needed packets. My overkill solution was to bridge client’s adapter with his TAP too. This made everything work instantly. But..., well, just look at this beautiful ASCII map below:
Code: Select all
+---------------+ +---------------+
| Other PC | (100.100.100.101) (100.100.100.151) | Other PC |
| in Server LAN | | in Clinet LAN |
+---------------+ +---------------+
| |
| |
+----------------+ +--------+ +--------+ +----------------+
| OpenVPN Server | <----> | Router | <========> | Router | <----> | OpenVPN Client |
+----------------+ +--------+ +--------+ +----------------+
(100.100.100.100) (100.100.100.1) (100.100.100.254) (100.100.100.150)
Bridge with TAP Assigns in range Assigns in range Bridge with TAP
100..109 (DHCP) 150..199 (DHCP)Second, with our setup we are obviously able to see entire LANs of each other. We can ping routers of each other, see all Windows shares of every PC in LANs, etc. Even though this is probably what is usually desired when you are bridging, in our case it’s an undesirable side-effect: we want to choose which PCs would be visible on both sides of VPN. Let’s say, I want only my 100.100.100.100 to be visible (hide 100.100.100.101) and he wants only his 100.100.100.150 to be visible.
So, my goal: Using bridged setup on both sides, allow our two and only our two PCs to communicate over VPN.
Any ideas how to accomplish this?
P.s.
Server and client run Windows 7. Routers run DD-WRT.
Configs attached below:
server.ovpn:
Code: Select all
local 100.100.100.100
port < port >
proto udp
dev tap0
dev-node OpenVPN
# Keys here
server-bridge
client-to-client
keepalive 10 120
cipher BF-CBC
comp-lzo
max-clients 3
persist-key
persist-tun
verb 1Code: Select all
client
dev tap0
dev-node OpenVPN
proto udp
remote < ip > < port >
remote-cert-tls server
resolv-retry infinite
nobind
persist-key
persist-tun
# Keys here
cipher BF-CBC
comp-lzo
verb 1