|
|
Hi, List.
I'm trying to build a bridging VPN between two Linux machines. Each box
has two NICs, one (eth0) on the public network and one (eth1) on a private
switch. I'd like machines on the private switches to be able to broadcast
to each other through the VPN so that I only have to maintain one DHCP
server for both segments, and it doesn't have to face the public net.
I've stepped through the bridging HOWTO, and I have things /mostly/
working. The "client" machine connects to the "server", and they
successfully negotiate a connection up to the point that the client gets
an IP address assigned.
When I try to ping across the connection from either VPN peer, some
traffic gets to the far end, but no replies come back. Which traffic
gets through depends on the direction of the flow. For example, while
running tcpdump in four different windows (watching br0 and tap0 on
each of the two machines), if I try to ping the "server" side
(10.1.1.2) from the "client" (10.1.1.50), I get:
- On the client's tap0:
00:35:53.336620 arp who-has 10.1.1.2 tell 10.1.1.50
00:35:53.338668 arp reply 10.1.1.2 is-at 00:0c:29:6f:f9:8e
- On the client's br0:
00:35:53.338668 arp reply 10.1.1.2 is-at 00:0c:29:6f:f9:8e
- On the server's br0:
00:35:53.329712 arp who-has 10.1.1.2 tell 10.1.1.50
00:35:53.329765 arp reply 10.1.1.2 is-at 00:0c:29:6f:f9:8e
- On the server's tap0:
00:35:53.329712 arp who-has 10.1.1.2 tell 10.1.1.50
00:35:53.329770 arp reply 10.1.1.2 is-at 00:0c:29:6f:f9:8e
(Note, no "who-has" ever appears on the client's br0, only the replies,
which struck me as odd.)
If I try to ping the client side from the server, still running tcpdump
on the same four interfaces, I get this on all of them:
00:45:56.203355 arp who-has 10.1.1.50 tell 10.1.1.2
No arp replies appear anywhere.
However, if I've recently tried to pass traffic from the client to the
server, that changes. Then, there will be a few seconds where tcpdump
shows the ICMP echo request going through, it makes it all the way to
tap0 on the client, but no replies are generated. After three or four
seconds with no client->server traffic, we go back to arp who-has
requests.
While trying to ping the client (.50) from the server (.2), the server's
arp table shows:
Address HWtype HWaddress Flags Mask Iface
10.1.1.50 (incomplete) br0
If the client tries to ping the server at the same time, it changes:
10.1.1.50 ether 16:31:B2:33:B7:D0 C br0
...and the echo requests start to appear on client:tap0, but it
generates no replies.
While the server tries to ping the client, the client's arp table shows
nothing for the server. If client tries to ping the server, the client
side arp table shows:
10.1.1.2 (incomplete) tap0
One thing I notice is that the "sever" shows br0 as the gateway
interface (whether the record is complete or not), while the client
always shows tap0. I don't know if that matters.
I've been over my firewalling. Both machines initialize their rules
from a copy of the same shell script, and both include the iptables
commands from the bridging HOWTO (ACCEPT for anything inbound on tap0
or br0, and for anything forwarding on br0) before any DROP or REJECT
rules.
Running "ebtables -t broute -L" just shows a default policy of "ACCEPT"
on both hosts, which is what I want, right?
Also on both hosts:
$ cat /proc/sys/net/bridge/bridge-nf-*
0
0
0
0
$ cat /proc/sys/net/ipv4/ip_forward
1
That pretty much sums up where I am so far; I don't know why it isn't
working and I'm not sure where to look for more information. The
remainder of this mail is just copies of config files from both
machines.
The server's openvpn.conf file looks like:
local 128.135.119.178
port 1194
proto udp
dev tap0
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/server.crt
dh /etc/openvpn/keys/dh1024.pem
ifconfig-pool-persist ipp.txt
server-bridge 10.1.1.2 255.255.255.0 10.1.1.50 10.1.1.100
client-to-client
keepalive 10 120
comp-lzo
user nobody
group nobody
persist-key
persist-tun
status openvpn-status.log
verb 5
...And here's the client's:
client
dev tap0
proto udp
remote bossy.uchicago.edu 1194
resolv-retry infinite
nobind
user nobody
group nobody
persist-key
persist-tun
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/client.crt
key /etc/openvpn/keys/client.key
ns-cert-type server
comp-lzo
verb 5
These are both Gentoo machines, their network config files are pretty
self-explanatory. Server's entire network config file:
depend_br0() {
need net.tap0 net.eth1
}
tuntap_tap0="tap"
config_eth1=( "null" )
config_tap0=( "0.0.0.0 promisc" )
bridge_br0=( "eth1 tap0" )
config_br0=( "10.1.1.2 netmask 255.255.255.0 broadcast 10.1.1.255" )
config_eth0=( "128.135.119.178 netmask 255.255.255.0 broadcast
128.135.119.255" )
routes_eth0=( "default via 128.135.119.1" )
And here's the client's network config:
depend_br0() {
need net.tap0 net.eth1
}
config_eth0=( "128.135.23.130 netmask 255.255.255.0 broadcast 128.135.23.255" )
routes_eth0=( "default via 128.135.23.1" )
config_eth1=( "null" )
tuntap_tap0="tap"
config_tap0=( "0.0.0.0 promisc" )
bridge_br0=( "eth1 tap0" )
config_br0=( "null" )
______________________
OpenVPN mailing lists
https://lists.sourceforge.net/lists/listinfo/openvpn-users
|