[SOLVED] TTL expired using bridging

[Paralon]

Discovered another problem with configuration. Having two lan networks behind the routers and bridged connection I can't see computers in server's local network even though in HOWTO it's said:

Including multiple machines on the server side when using a bridged VPN (dev tap)
One of the benefits of using ethernet bridging is that you get this for free without needing any additional configuration.

If my LAN and server's LAN are in the same subnetwork - all's well. If no - we can't see each other. On ping it says "Reply from 192.168.111.62: TTL expired in transit."

Also Im not sure that I understand these:

The addresses used for local and remote should not be part of the bridged subnet -- otherwise you will end up with a routing loop.

Solution: Don't use bridges on both client and server side - only on server.

[janjust]

without client and server config files it is impossible to tell what is happening; a 'TTL expired' might indicate a routing loop.

I'm not sure how you managed to connect a client and server where both are on the same subnet - that is definitely asking for routing problems.

[Paralon]

Forgot the configs. Here they are:
client

Code: Select all

client
dev tap
proto udp

remote <ip>
resolv-retry infinite
nobind

persist-key
persist-tun

ca ca.crt
cert client.crt
key client.key

comp-lzo

verb 3

server

Code: Select all

local 192.168.1.27
port 1194
proto udp
dev tap

ca ca.crt
cert server.crt
key server.key

dh dh1024.pem

ifconfig-pool-persist ipp.txt
server-bridge 10.8.0.4 255.255.255.0 10.8.0.50 10.8.0.100

keepalive 10 120
comp-lzo

persist-key
persist-tun

status openvpn-status.log
verb 3

I'm not sure how you managed to connect a client and server where both are on the same subnet - that is definitely asking for routing problems.

I mean there were 192.168.1.0 networks behind both of the routers. In this case everything seemed to work. But if I re-configure one of the routers to have - let's say - 192.168.3.0 network - I begin to get TTL expiration messages on ping. Maybe similar LAN configurations were the problem for timeouts I posted about here: topic8270.html
But I do not understand how to make bridging work with different networks then.

[maikcat]

hi there,

if you want to use bridging then you must bridge tap & eth interfaces to your
openvpn server.


some key points in bridging..

1)you need both interfaces in promiscues mode
2)if it is a linux ,the script is
#!/bin/bash

#################################
# Set up Ethernet bridge on Linux
# Requires: bridge-utils
#################################

# Define Bridge Interface
br="br0"

# Define list of TAP interfaces to be bridged,
# for example tap="tap0 tap1 tap2".
tap="tap0"

# Define physical ethernet interface to be bridged
# with TAP interface(s) above.
eth="eth0"
eth_ip="192.168.8.4"
eth_netmask="255.255.255.0"
eth_broadcast="192.168.8.255"

for t in $tap; do
openvpn --mktun --dev $t
done

brctl addbr $br
brctl addif $br $eth

for t in $tap; do
brctl addif $br $t
done

for t in $tap; do
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

to the server line you use ips from your lan (you are bridging...)

server-bridge 192.168.1.27 255.255.255.0 192.168.1.200 192.168.1.240

also to your config use

dev tap0 instead of dev tap

first you run the script which bridges the interfaces *then* you fire up openvpn..


i will to write a more detailed howto when i have time.

Michael.

[Paralon]

All machines are running Windows 7 and not sure about promiscuous mode, but what I did was Bridging two interfaces (real one and virtual TAP), setting ip, netmask, gateways and dns servers on new bridge interfaces (they got that all from router's DHCP servers).

[janjust]

your server config mentions

server-bridge 10.8.0.4 255.255.255.0

is this indeed the IP+netmask assigned to the bridge?
please don't tell me you also want to bridge the client adapters

[Paralon]

Ouch. Sorry for errors in confing - must have mis-typed that part. I was posting from my job and used exaple config as reference There should be 192.168.1.27.

Well... one more evening of endless attempts.
This time I bridged adapters on server side only. Ran VPN-server there with correct server-bridge config:
bridge interface had ip 192.168.3.2 and netmask 255.255.255.0 so I used this config

Code: Select all

local 192.168.3.6
port 1194
proto udp
dev tap
dev-node tap

server-bridge 192.168.3.2 255.255.255.0 192.168.3.128 192.168.3.254

Client was using old config (actually there's not much to change) and had ip 192.168.1.1 and 255.255.255.0 netmask in his local network. He could connect to server, he could ping my local network but no broadcasts could be seen (to say the truth we tested it in quake1 - he could connect via direct ip, but could not see the server in list. and afaik quake uses udp broadcasts when searching for servers...)

P.S. Finally! It worked! When game-server is run on vpn-client's machine - game-client (that's run on vpn-server's machine) can see game in list. Meaning that game-client's broadcast packet travelled from vpn-server to vpn-client successfully. But not vice-versa. I'm not very familiar with all these "networks stuff" so... I don't get why is that happening. Also, I wonder if that would work with two and more game-clients (that would run on other vpn-clients).

P.P.S. And when I was making bridges on both vpn-client and vpn-server sides it created a loop - am I right?

[janjust]

Excellent news - nice to hear it is finally working!

P.P.S. And when I was making bridges on both vpn-client and vpn-server sides it created a loop - am I right?

bridging both sides causes funny stuff to happen to the IPs of both bridges - the subnets needs to be identical on both sides, which can indeed cause all kinds of routing loops. It _IS_ possible to do this, but you had best avoid it.

[Paralon]

Yep. That's all was because of bridges on both sides. Thanks for your help a lot, guys.